[linux-elitists] Current client-side anti-spam best practices

Jeff Waugh jdub@perkypants.org
Tue Sep 26 15:44:40 PDT 2006

<quote who="Ben Finney">

> If one wants to reject an incoming message because it appears to be spam
> (or other malicious mail), the correct time to do it is while one is
> engaged in the SMTP conversation with the party sending it.
> The problem with a remote alias is that the host who sent the message has
> their SMTP conversation with the remote machine; if one doesn't reject it
> at that point, but *does* reject it at the end-point MTA, the remote alias
> MTA will have to send a bounce message. That message will go to the
> almost-certainly-forged sender address, instead of directly to the host
> that tried to send the message in the first place.
> So the only other option is dropping it on the floor, which is a poor
> substitute.

Actually, the main reason it matters to me is that everything from standards
compliance checks to RBL checks won't kick in when the mail is correctly
relayed to me through the machine that owns my alias. I don't do detailed
content checking during the SMTP conversation, as I tend to find it wasteful
(because it doesn't catch much anyway) and unreliable (cf. Wietse).

I'm really tempted to do the usual set of SMTP policy checks on secondary
Received headers that I get through aliases. You lose the direct knowledge
of the client and so on, but hopefully one can trust Received headers from a
machine you get mail from (even if you can't trust them to nuke the spam).

- Jeff

linux.conf.au 2007: Sydney, Australia           http://lca2007.linux.org.au/
   "Stupidity is used to run 98% of the world's corporations, which tops
              UNIX server usage by quite a bit." - George Lebl

More information about the linux-elitists mailing list