[H-GEN] Stopping spam
David Jericho
david.jericho at aarnet.edu.au
Thu Mar 31 00:54:34 EST 2005
Russell Stuart wrote:
Hi Russell, I'm not flaming or shooting you down, I'm just adding some
cynical thoughts (hopefully) for the benefit of a wider audience, based
on my own experiences, including the development of an MTA.[1]
> Messages
> Bounced Reason given to remote server.
> ======= ==================================================
> 2440 According to domain.com's SPF records 24.203.35.8
> is not allowed to send mail on its behalf.
>
> 1897 Emails from Yahoo accounts must be sent by Yahoo's
> servers.
I personally don't believe in SPF, or assuming mail for a domain must
come from a domain's MX records. I've found that assumption causes more
embarrassing problems for the higher ups than it solves for everyone.
> 1623 SMTP protocol violation. [Eg: not waiting for 2xx
> response before sending next request.]
For those who don't know, this isn't always a violation. See RFC 2920.
Pipelining of SMTP commands is commonly used in legitmate large scale
environments.
> 684 No such user.
Only 684 over a month? In all my monitoring of domains I've controlled,
this one appears to make up the vast majority of SMTP connections given
a 550, and usually by at least one order of magnitude.
> 60 Unrouteable return address.
Not claiming this is how your MTA is setup, but too many MTAs reject
email because they can't honour A records in DNS. Another thing to note
is that <> is a perfectly valid MAIL FROM: value.
> c. Yahoo doesn't implement SPF. It was worth my while to put in a
> manual check that emulated SPF for Yahoo. Between them, SPF
> and this manual check catch over 1/2 the spam.
My chief gripe with SPF is that are too many networks that block
outbound SMTP to be useful. For example, even though I'm posting from
aarnet.edu.au, I'm actually on QUT's network at the moment, meaning I
must use their network.
Yes, I could use a VPN, but QUT's network also blocks IPSEC. That isn't
an uncommon situation in a hotel either. I could also use the message
submission port (587), but I stubbornly refuse to use something that
does not really solve any problems, and only creates more hassles. Not
to mention not properly supported by MUAs.
But alas, the rant of submission verses transmission (RFC2476) is one
that's deserving some stand up comedy and a jug of beer.
> c. The only check here that causes me grief (as in complaints
> about email not getting through) is insisting on a Message-ID.
> Yes - I know the rule violates the 2822, but it does catch
> a fair number of messages. qmail and Outlook seem to be the
> principal culprits here.
2822 3.6.4 does only say "SHOULD", where SHOULD is defined by "mean that
there may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course." Not so much a
violation, as opposed to a "please explain".
RFC 2119 for the curious.
In anycase, ignoring messages from Outlook appears fairly reckless to me.
> d. It appears that about 15% of the message that get through these
> filters are spam.
A bayesian filter, with a universal drop box for users is easy enough to
implement, and my detection rates are around 1 every 400 or so. False
positives are so infrequent that I only check for false positives maybe
once a week and even rarely see them.
[1] I will never again threaten to rewrite something I think sucks.
--
David Jericho
Systems Administrator, AARNet
Phone: +61 7 3864 8379
Mobile: +61 4 2302 7185
More information about the General
mailing list