On Tue, 2004-08-17 at 13:01 +0100, warren, anthony wrote:
> Hi all,
>
> After some testing with SMTP sender verify callouts and getting mixed
> results from that method, I am keen to explore other Spam reduction
> techniques.
>
> My organisation is concerned with the risk of false positives. For those
> that use spam reduction techniques - how do you cope with the risk of FP's ?
I throw out all messages without a Message-Id: header. RFC2822 says you
SHOULD have one, and a lot of crap lacks it, especially virus messages.
There are some false positives, but only from broken software. It's
always fixable.
Likewise, enabling obviously bogus HELO greetings is helpful. See
http://www.infradead.org/~dwmw2/eximconf/include/acl-helo for example.
(The hotmail/aol bits of that were taken from a posting on this list
which you can probably find in the archives).
Obviously, do sender verification callouts. I do these with the
'postmaster' option. It causes a few false positives but again only for
broken sites, and they are perfectly capable of fixing it. You might
want to use 'defer_ok' but I prefer not to.
There are tests you can do on the data payload too -- s/helo/content/ on
the above URL for mine. 'require verify=header_syntax' is a good one.
Again, the occasional false positive but only then the sender _is_
actually broken.
> Do you bounce SPAM or simply tag it and let the user delete the messages?
You should ideally reject at SMTP time. Certainly don't accept and then
bounce anything -- you should strive to ensure that your system never
actually generates bounces in normal operation.
I reject spam with more than 10 SpamAssassin points, tag it if it gets
fewer points than that -- the users can then do what they like with that
information.
The other thing I do is sign my outgoing reverse-paths. No mail is ever
sent with SMTP 'MAIL FROM:<dwmw2@???>' and hence no bounces
are ever accepted to that address. I've been doing this for a few opt-in
users for the last few months, with a lot of success. It means we get no
bounces to mail we didn't send, and third parties who bother to do
sender verification callouts also get the benefit of rejecting crap
which is faked to be from us. I'll be rolling that out for all users in
the near future. There are one or two minor issues with it, like ezmlm
using the SMTP reverse-path for subscription addresses and filtering of
non-member posts. See
http://www.infradead.org/rpr.html for more
details.
You should play with some of the options, to see if they would actually
reject mail you want. As you can probably tell, I'm quite happy with the
odd 'false positive' if the sending site is actually at fault. Your
priorities may differ -- you may wish to do the world a disservice by
accepting broken crap :)
Oh, and don't do SPF. It's a fundamentally broken concept.
--
dwmw2
