Re: Your order

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

Matthew Dillon wrote:
>     Ok, what I did was modify my milter filter to reject mail from
>     non-local sources sent to crater but containing a From: header
>     containing crater's domain name.
>
>     That should put a stop to the spam.  Basically the spammer is sending
>     mail to crater's bestserv list using a From: address of
>     <user>@crater.dragonflybsd.org.  I looked through the logs and there
>     are thousands of such spams, the random user generator the spammers
>     use just randomly found one that is actually subscribed to our
>     commits list.
>
>     Sendmail does not have any sort of map file or filter that is
>     conditional on the connection coming from OUTSIDE the machine
>     that I can use to filter out From: headers that specify
>     crater.dragonflybsd.org.  It just has an overall filter that
>     catches both local and remote sent email.
>
> 					-Matt
> 					Matthew Dillon 
> 					<dillon@backplane.com>

'From: *headers* you can ignore.

What you want is the smtp 'mail from' handshake, or 'envelope-from'.

But in general, up-front in-session filtering tools are strengths of 
Courier-MTA and Exim and very few others.

- They branch *during* the smtp session, can disconnect in a New York 
minute if the IP  - or anything else w/r the *server* characteristics - 
prove dodgy. No need to analyze or even take on-board message content.

Lower server & b/w load.

No bogus bounces - whomever or *whatever* is on the teat gets told what 
for, (optionally...) but any third-party that was forged is not hassled, 
'coz there is no need to generate a post-session DSN.

The other in-session test is 'require verify = recipient', a step 
probably left until 'too late' in a milter or MLM. Garbage is already in 
RAm or on disk with most of 'em.

Exim throws forged recipients off the teat at the smtp RECPT phase - 
once again - no risk of backscatter, no junk in the queue, and lower 
overall load.

But if you could have exactly ONE filter rule and only one, rejecting on 
forward/reverse rDNS match fail is the single most accurate and 
'powerful' one.

Try a send to my address directly from any DHCP-connected box and see 
how fast the rejection takes place. I'll have a log entry - but nothing 
else...

;-)

Bill