Hi,
Thanks so much to all who have replied on this topic!
I've attempted to digest all points made, and I've come up with a (hopefully)
non-controverisal and accurate list of Do's and Dont's in accepting
connections.
Clearly, this is extremely complex and there just doesn't seem to be a
definitive (and correct) list of what to do to safely block spammer
connections anywhere on the net (I've been looking!).
Even the "standards" people have little or nothing to say on this topic.
Amongst those who replied to this topic, there are differences of opinion, and
maybe some inaccurate or incorrect methods.
My version 1 of the list is below.
Please respond with additions or changes, and maybe this can become some sort
of accepted or definitive list.
A corresponding set of ACL's would be a good addition.
Notes about Safely Blocking Email with Exim
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Version 1 17-May-2010
~~~~~~~~~~~~~~~~~~~~~
From the "verify_sender" subject posted to exim-users.org.
Do Not...
~~~~~~~~~
1. perform sender verification callouts. This means don't attempt to verify
the email address of the sender. These queries can cause backlisting. The
response from such a query is also unreliable.
2. use auto-responders/out-of-office replies. This of course implies
don't use Challenge-Response systems after receiving the email from
Exim.
3. check that the IP connecting has a PTR record that is trackable to
an MX record. It's perfectly legit for sending servers to be
completely different to MX servers. However, see DO#5 below.
Do...
~~~~~
1. perform sender domain verification.
2. reject email at connection where possible (acl_smtp_connect).
3. check that the connecting server is legit
4. as much rejection in acl's, none in router/transport sets.
5. check that the IP connecting has a PTR record that is trackable to
an A record for the FQDN they claimed. You have to do sub-domain
matching (e.g. *.amazon.com) for this to make sense.
6. reject a connection whose IP doesn't have a PTR record. Even
though this is valid according to the RFCs, in practice almost all
legitimate SMTP connections can be assumed to have PTR records in the
DNS. A whitelist might be required for some exceptions.
An exception might be one's own user community, connect from ISP's.
(These can be accepted by explicit authentication or some other
method.)
7. assume commercial spammers (those who aren't trying to hide) will
have valid DNS entries and they must be rejected using other means
(e.g. RBL, LBL).
--
Russell Robinson (russellr@???)
