Greylisting - interesting article

[Andy Blanchard <an...@zocalo.uk.com>]

While the technique described in this article is intended for
implementation at the MTA level, it still makes for interesting reading
that's worth a look.  There seem to be a few ideas in here that might be
useful in enhancing the reliability of SpamAssassin's Auto-Whitelisting
feature as well, especially the concept of the "triplet".

Anyway, here's the link for your perusal:

   http://projects.puremagic.com/greylisting/

Andy

Re: Greylisting - interesting article

[Mike Zanker <mi...@zanker.org>]

On 05 March 2004 10:12 -0600 Bob Apthorpe <ap...@cynistar.net> 
wrote:

> IIRC, they're working on that; check the Greylist ML archives (at
> http://lists.puremagic.com/pipermail/greylist-users/2004-March/thread
> .html) for the thread "Bagley: version 0.01 available"; you should
> find a link to
>
> http://workingcomputers.eris17.co.uk/bagley/bagley-0.01.tar.gz
>
> which apparently works with Exim 4 using either an ACL hook or
> local_scan. I know zero about Exim but apparently calling it from an
> ACL hook allows RCPT-time rejection.

Thanks - something to play with this weekend :) I see the original 
author of the Exim greylisting code is implementing it as an ACL, too.

Mike.

Re: Greylisting - interesting article

[Bob Apthorpe <ap...@cynistar.net>]

On Fri, 05 Mar 2004 15:44:19 +0000 Mike Zanker <mi...@zanker.org> wrote:

> On 05 March 2004 08:02 -0600 Bob Apthorpe <ap...@cynistar.net>
> wrote:
> 
> > Counterintuitively, greylisting also saves bandwidth because the SMTP
> > connection and tempfail traffic is substantially smaller than spam
> > message bodies (you tempfail before reaching the SMTP DATA phase.)
> 
> Except in the Exim implementation which does the checking after the
> DATA phase. I find it still works very well, though.

IIRC, they're working on that; check the Greylist ML archives (at
http://lists.puremagic.com/pipermail/greylist-users/2004-March/thread.html)
for the thread "Bagley: version 0.01 available"; you should find a link to

http://workingcomputers.eris17.co.uk/bagley/bagley-0.01.tar.gz

which apparently works with Exim 4 using either an ACL hook or
local_scan. I know zero about Exim but apparently calling it from an ACL
hook allows RCPT-time rejection.

Postfix users will have to wait until Postfix 2.1 for SMTP policy
delegation (see
http://www.porcupine.org/postfix-mirror/newdoc/SMTPD_POLICY_README.html).
A greylisting client ships as example code; apparently RC1 is waiting on
documentation cleanup. One nice thing about this hook is that it sends
envelope and other data to an external process, though I believe that
happens before the DATA phase so you may need to persistently store that
data and somehow associate it with the message in order for SA to make
use of it.

hth,

-- Bob

Re: Greylisting - interesting article

[Mike Zanker <mi...@zanker.org>]

On 05 March 2004 08:02 -0600 Bob Apthorpe <ap...@cynistar.net>
wrote:

> Counterintuitively, greylisting also saves bandwidth because the SMTP
> connection and tempfail traffic is substantially smaller than spam
> message bodies (you tempfail before reaching the SMTP DATA phase.)

Except in the Exim implementation which does the checking after the
DATA phase. I find it still works very well, though.

Mike.

Re: Greylisting - interesting article

[Bob Apthorpe <ap...@cynistar.net>]

Hi,

On Fri, 5 Mar 2004 10:23:42 -0000 (GMT) "Andy Blanchard" <an...@zocalo.uk.com> wrote:

> While the technique described in this article is intended for
> implementation at the MTA level, it still makes for interesting reading
> that's worth a look.  There seem to be a few ideas in here that might be
> useful in enhancing the reliability of SpamAssassin's Auto-Whitelisting
> feature as well, especially the concept of the "triplet".
> 
> Anyway, here's the link for your perusal:
> 
>    http://projects.puremagic.com/greylisting/

The hard part is reliably getting the mail envelope information & IP
address (or /24) into SA, though I expect those elements would make very
good Bayes tokens. What might work even better is scanning your sent
mail folder for recipients and adding those to AWL on the assumption
that you don't correspond directly with spammers.

Greylisting kills proxy spam dead with only a minor delay to some mail
with a little manual whitelisting of broken MTAs (ancient Groupwise) and
large email farms that retry from different IP addresses.
Counterintuitively, greylisting also saves bandwidth because the SMTP
connection and tempfail traffic is substantially smaller than spam
message bodies (you tempfail before reaching the SMTP DATA phase.)
Still, if you can't accept a one time 5-60min delay in mail from new
people, the technique is probably not for you.

-- Bob

Re: Greylisting - interesting article

[codger <li...@pmbx.net>]

I've not seen the difference in the result of greylisting and requiring 
rDNS records except that with rDNS someone has to be accountable for 
their mail server and greylisting doesn't require this. Reverse DNS 
checking at the smpt level would be more effective at bandwidth 
reduction now and later I would think. There are negative opinions 
about rDNS though also.

Basically though rDNS and SPF really require larger scale 
implementation to be effective while greylisting would not.

On Mar 6, 2004, at 9:26 PM, LuKreme wrote:

> On 05 Mar 2004, at 03:23, Andy Blanchard wrote:
>> While the technique described in this article is intended for
>> implementation at the MTA level,
>
> My prediction is that this is going to be bad.
>
>>>  During the initial testing of Greylisting in mid-2003, it was 
>>> observed that the vast majority of spam appears to be sent from 
>>> applications designed specifically for spamming. These applications 
>>> appear to adopt the "fire-and-forget" methodology. That is, they 
>>> attempt to send the spam to one or several MX hosts for a domain, 
>>> but then never attempt a true retry as a real MTA would.
>
> Great, so the next wave of spammers will be firing off multiples of 
> every single spam, probably by processing their list twice (to give 
> some time between the two attempts).
>
> Just what we need, a doubling of traffic.
>
> As a temporary stop-gap I'm sure it will be astonishingly effective.  
> long-term it's really gonna suck.
>
> -- 
> Because you can't cotton to evil.  No Sir.  You have to smack evil on 
> the nose with the rolled-up newspaper of justice and say,'Bad evil. 
> bad BAD evil'"
>
>

Kindest regards,

Ron

"What shall we do? What shall we do?" he cried, "Escaping goblins to be 
caught by wolves!" - Bilbo Baggins

The Hobbit by J. R. R. Tolkein
http://www.apple.com/trailers/newline/returnoftheking/trailer_large.html

Re: Greylisting - interesting article

[LuKreme <kr...@kreme.com>]

On 05 Mar 2004, at 03:23, Andy Blanchard wrote:
> While the technique described in this article is intended for
> implementation at the MTA level,

My prediction is that this is going to be bad.

>>  During the initial testing of Greylisting in mid-2003, it was 
>> observed that the vast majority of spam appears to be sent from 
>> applications designed specifically for spamming. These applications 
>> appear to adopt the "fire-and-forget" methodology. That is, they 
>> attempt to send the spam to one or several MX hosts for a domain, but 
>> then never attempt a true retry as a real MTA would.

Great, so the next wave of spammers will be firing off multiples of 
every single spam, probably by processing their list twice (to give 
some time between the two attempts).

Just what we need, a doubling of traffic.

As a temporary stop-gap I'm sure it will be astonishingly effective.  
long-term it's really gonna suck.

-- 
Because you can't cotton to evil.  No Sir.  You have to smack evil on 
the nose with the rolled-up newspaper of justice and say,'Bad evil. bad 
BAD evil'"