DragonFly commits List (threaded) for 2009-05
DragonFly BSD
DragonFly commits List (threaded) for 2009-05
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Your order

From: Bill Hacker <wbh@xxxxxxxxxxxxx>
Date: Sat, 02 May 2009 03:49:04 +0800

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.

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...



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]