[Greylist-users] Fwd: Re: idea: mis use temporary errors

[Hector Santos]

RBR,

This is not a good idea.   By sending a 41x which by way should be 45x,
you are imposing penalties on legitimate senders by telling them they
will never make into the system even after a correction is made.

Plus you are making erroneous presumptions about how systems have their 
RETRY frequencies configured.

Commercial Systems are "adjusting" to GREYLISTED transactions by 
changing their 2nd and 3rd attempts.  In other words, while the basic 
rule of thumb (RFC 2821 suggestions) is 1 per hour for 4-5 days,  some 
systems are now making the 2nd and 3rd attempt with in 1 to 5 minutes in 
order to address initial GreyList rejections.  These are the kinds of 
ideas that is making "GreyListing" more adoptable in commercial 
environments.

Anyway, you should not alter SMTP current practices with ideas like 
this.  As long as it is isolated to small systems, who cares?  but it 
wouldn't apply in the general case.

My opinion on this.


--
HLS

rbr wrote:
>> The side effect of that is when somebody  sends a legit email message
>> but mistypes the recipient address. That message will not bounce to the
>> sender right away and the sender mail server will keep trying to send
>> the message for few days.
>>
>> Yaser
> 
> This is, indeed correct. However
> - the whole concept of greylisting does have its negative impact on legit
> email messages.
> 
> The legit sender that has made a typing error, does experience a delay before
> being informed. With a 5xx error the legit sender was informed right away.
> With a 4xx error the legit sender will be informed after 4 hours or something
> like that, with a message send by his own mailserver, stating "could not send
> your message for the past 4 hours".
> If the postmaster, or the company, or the ISP of the legit sender thinks that
> 4 hours is a good period for informing the legit sender of some problems in
> some circumstances, I think it is acceptable that "one" circumstance is moved
> from "being directly informed" to "begin informed after a while". It is just
> a small price to pay in the war against spammers.
> 
> I think it is acceptable to have this negative impact because the ratio
> between legit email message with mistyped recipient address compared to non
> legit email message with mistyped recipient address, is not in balance. In
> our case it does only happen a few times in a year that a customer makes a
> mistake with mistyping an email address while non legit email message with
> mistyped recipient address do happen a few times in an hour.
> 
> I think it is acceptable to have this negative impact because there are
> already circumstances where the legit sender is informed after a while and
> this is all handled gracefully.
> 
> RbR-IPConsult BV
> 
>> rbr wrote:
>>> Following an idea. We have tried it for a while, and it works, but it is
>>> a 'solution' that is open for debate.
>>>
>>> As you all know:
>>> [1] smtp knows temporary 4xx errors and permanent 5xx errors.
>>> [2] spammers worst enemy is time or delay, because with increasing time
>>> the chance of being blacklisted on Spamcop, Sorbs, etc is also increased.
>>>
>>> The second fact is one of the reasons why greylisting does work against
>>> spammers.
>>>
>>> The idea I would like to drop is a combination of [1] and [2].
>>>
>>> Quite often we get mail like this:
>>>
>>>  In:  EHLO vsmtp105.tin.it
>>>  Out: 250-ipconsult.nl
>>>  In:  RCPT TO:<Karen532 at ipconsult.nl>
>>>  Out: 550 <Karen532 at ipconsult.nl>: Recipient address rejected: User
>>> unknown in local recipient table
>>>
>>> For reasons unknown to us, all kind of email addresses are 'tried'.
>>> Luckely they have not found any working email address yet.
>>> The trace as copied-and-paste above, is not coming from the usual
>>> dsl/cable/ppp-hacked-windows-PC, but from decent mailservers. Every
>>> detail like hostname, mx-record, etc, is correct.
>>> So, apparently there are a lot of decent mailservers that are available
>>> for spammers, for testing the existence of email addresses at our
>>> domains.
>>>
>>> A small extra piece of info: we do run a perl-script that checks the
>>> mail-logfile. Based on the mail-logfile, this perl-script does add
>>> IP-addresses to the blacklist of the firewall. Handling abuse at a
>>> firewall level is less expensive in terms of cpu then handling the abuse
>>> at mail-level. And it gives us the oppertunity to do a 'drop' at iptable
>>> level, which does result in timeouts for the offending mailhost.
>>> Something that result in timeouts for a offending mailhost is always good
>>> [2].
>>>
>>> The idea is as follows: we have changed permanent 5xx error to a
>>> self-defined 4xx temporary error. This is, off course, a violation of the
>>> RFCs. But the result is kind of funny. Those temporary errors codes are
>>> pickup up by the perl script, and the offending mailhost is placed in the
>>> blacklist at TCP/IP level, with a drop rule. Because the offending
>>> mailhost did receive a 4xx error, he keeps on trying for a couple of
>>> hours up to 2 days. Those retries do not bother us, because it is handled
>>> quite effeciently by ip-tables.
>>>
>>> The result is:
>>>
>>>  In:  EHLO vsmtp105.tin.it
>>>  Out: 250-ipconsult.nl
>>>  In:  RCPT TO:<Karen532 at ipconsult.nl>
>>>  Out: 412 <Karen532 at ipconsult.nl>: Recipient address rejected: User
>>> unknown in local recipient table
>>> .....
>>>  shorewall drop vsmtp105.tin.it
>>>
>>>
>>> Any comments on this?
>>> Mis-use of temporary 4xx errors in combination with a drop-rule in the
>>> firewall, with the objective that the offending mailhost is waisting
>>> time.
>>>
>>> RbR-IPConsult BV
>>>


-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com