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

[rbr]

> 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
> >
> > -------------------------------------------------------
> >
> > _______________________________________________
> > Greylist-users mailing list
> > Greylist-users at lists.puremagic.com
> > http://lists.puremagic.com/cgi-bin/mailman/listinfo/greylist-users

-------------------------------------------------------