Re: [exim] selective greylisting

Nathan Huesken wrote:
> On Sat, Jan 24, 2009 at 02:40:17PM +0000, Jeremy Harris wrote:
>> Nathan Huesken wrote:
>>> 1. $local_part and $domain do not seem to be set. Is this normal for acl_smtp_data lists? How can I get them?
>> By the time you're at data phase there could have been multiple
>> recipients. Which one would you find relevant?
>
> I see the probelem ...
> When I look at my spam mail, 99% of the time it has only 1 recipient.
> So how can I change the rule, that it only greylists if the mail has only 1 recipient and how do I get the recipient?
>
>>> 2. some senders (like googlemail) always change there $sender_host_address and by that do not get through.
>> That is one of the problems with greylisting.
>>
>> - Jeremy
>
> Well, than I can no use the $sender_host_address. What is about $sender_helo_name? Does that change to?
> Thanks!
> Nathan
>

Of course. Look at enough HELO and you will find more dynamism than
daytime television...

OTOH... solutions are cheap and easy...

For a very lage percentage of arriving spam - which is often sent by
infected WinBoxen - the IP will not forward/reverse match to a FQDN.

It will either have no PTR RR at all, or will have a 'generic' one, such
as a dash-separated-IP-number.adsl.some.connectivity.provider.tld.

Further, one can check an RBL for the use of a 'dynamic' IP, another
'sin' for smtp service use.

Likewise, the HELO will not resolve to a FQDN that matches a DNS entry
associated with the connecting IP.

Rather than reject at once, however, you can carry along until you have
more than just an IP to check against a whitelist - allowing in
somebody's grandson running an MTA on a Linux laptop out of his loft.

- Take note of the first rDNS fail by setting a flag or integer in an
acl_c variable during acl_smtp_connect. We call ours a 'rude score'.

- Do the same for dynamic-IP RBL hit, by adding another integer to the
same variable or flagging in another variable.

- Same again in acl_smtp_helo if/as/when the HELO is mismatched, forged,
or garbage-generated. Plenty of acl snippet examples here in archives.

No later than acl_smtp_recpt check against a local whitelist of
'permitted fools' - which can be recipient-specific by this point if you
care to pull up per-user preferences.

Of course you should also check to insure that the recipient is valid
for your user pool - (require verify = recipient).

Reject the rest of those with too many black marks / too high a
cumulative total, but after a delay of, for example 30 seconds.

Most zombies will disconnect of their own accord within 12 to 15 seconds
and hurry away to find a more willing victim.

You won't even need to generate an error message, nor tip your hand as
to why you found them offensive.

That combination needs very little in the way of server resources,
seldom needs to call on a virus scanner or content scanner, let alone
have to do the 'tracking' work of greyisting.

Most important - it generates no 'truly false' positives, because any
competant sender's mail admin WILL have a PTR RR and WILL take the
modest administrative effort to configure their HELO to match the FQDN
they have published for the IP, even if it is one of a large pool.

As a side effect, it keeps even the most detailed of logs from eating up
disk space ...

CAVEAT: If you have no other life, and your goal is to 'play' with
spam, accumulate massive statistics, get all clever with greylisting and
SpamAssassin customization, a server that stops 98% of zombots up-front
will be boring.

OTOH, it won't interfere with meals. Or your sex life.

YMMV,

Bill Hacker