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

[Ken Raeburn]

On May 28, 2007, at 03:05, 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.

Your mail described blocking the sending server at the firewall  
level.  So to expand on Yaser's case a little, someone who sends  
legitimate mail to you but mistypes the recipient address gets a  
timeout bounce after some number of days (configured at their site or  
their ISP), unless you remove the firewall block before that timeout  
is up.  If they almost immediately recognize the mistake and resend  
the email with the correct address, it will also be delayed by  
however long you keep the block in place, and may be bounced with a  
timeout.  That seems like a pretty stiff penalty, no matter how  
infrequent.

So I guess a key issue is how long you keep the firewall block in  
place, and whether that's longer or shorter than the sending site's  
mail queue retry timeout.  That's similar to getting the block  
timeouts right in your greylisting configuration; it should be short  
enough that you don't lose legitimate mail.

Also, I hope this applies only to sites you haven't already approved  
mail from, so I couldn't temporarily block all mail from bigisp.com  
from reaching you simply by getting an account or mailing list there  
and sending mail to a bogus address at your domain.  (Or forge a  
sending address at your site in a joe job; then you'd get backscatter  
from all over, and start blocking lots of sites.)

It could be an ongoing problem if, say, you remove the block after a  
day, but then the next message attempt is to the bogus address,  
whether because of retrying the earlier delivery or a new message in  
the queue.  Either way, it sounds like it could continue to block  
legitimate mail until it bounces.

Ken

> 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