Russell Robinson wrote:
> 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!).
Actually there are. Believe it or not Wikipedia even has a quite decent recap:
http://en.wikipedia.org/wiki/Anti-spam_techniques
>
> Even the "standards" people have little or nothing to say on this topic.
>
Rather 'too much' to say actually. The Devil is in the *implementation*
> 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.
>
Beyond the Exim spec and the defaults - that can be a bit harder.
acl's do not live in a vacuum, router/transports set even less so, ergo a
well-intentioned code-snippet will not always do the desired thing if stuffed
into an environment - or a place within that environment - that differs from
whence it last functioned well.
The good news is that AS you build your own solution, you will quickly grasp how
to assess and adapt ever more prior art or roll in your own.
THEN you can safely maintain and admin it.
> 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.
.. to servers with whom you have not made prior arrangements. (See below)
> 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.
Sender verification callouts are a fine tool for use between and among a group
of cooperative servers. For example - multiple filtering or load-balancing or
relaying servers can use this instead of trying to keep a fully up to date DB of
valid users in sync on all of potentially 'many' boxen.
CAVEAT: Mirroring such a DB - or providing access to a centrally shared one -
may be yet a better way, but sender verification may be easier to implelemtn if
the MTA involved are of different 'race' and 'players' enter and leave the society.
>
> 2. Insert <try to NOT permit> use <of> auto-responders/out-of-office
> replies.
> This of course implies don't use Challenge-Response systems after receiving
> the email from Exim.
>
Agree both points. Belive they deserves separate mention.
CAVEAT: Neither are fully controllable from the MTA. Many MUA can be programmed
do either/both, and folks WILL do both, so you may have to work hard to educate,
intercept the outbound, even disable a user.
> 3. inserting <DO> check that the IP connecting has a PTR record that is
> trackable to an MX record. <or at least an A record> It's perfectly legit for
> sending servers to be completely different to MX servers. However, see DO#5
> below.
>
COMMENT: Separate, yes. Totally unrelated, rarely. VERY rarely.
IOW - one has to break it a-purpose. NetSol was doing that at one time -
mis-matching <tld> as well as <domain>.
Exim's manner of doing the tests are quite sane. It will generally find a trail
if one CAN be found, IOW has little or no problem with the common ISP pools of
separate inbound and outbound and intermediate queuing servers, use of prefixes
that may or may not match DNS RR - so long as at least the basics have been
observed w/r DNS, Exim will apply logic that a manual search and human analysis
would find little fault with.
> Do... ~~~~~
>
> 1. perform sender domain verification.
The rDNS check is a bit more flexible, actually.
>
> 2. reject email at connection where possible (acl_smtp_connect).
>
Amen. 'Where possible' can be 'always' if you work at it.
> 3. check that the connecting server is legit
>
Cumulative effect of checks on rDNS, HELO, protocol violations, and more.
point-scoring (within Exim, not SA or such) can help.
> 4. as much rejection in acl's, none in router/transport sets.
>
See point 2.
> 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.
See above. Exim does it sanely with the rDNS check - doesn't require a perfect
match - just a usable route. Browse the code in hosts.c - it is clean and well
commented.
A HELO to FQDN match OTOH, *should* give predictable results, but unfortunately
cannot be counted on to do so.
Too many clever sysadmins sub-ID'ing their boxen or using Gothic HELO strings
without regard to DNS entries. Give a mismatch a few demerits, but don't
hard-reject on it.
>
> 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.
Unless you love zombots, pragmatically you pretty well must reject on PTR RR
fail. AND expect others to treat you the same way.
A PTR RR is one of those 'don't leave home without it' things.. . 'coz without
one very often you can't (leave home..}
>
> An exception might be one's own user community, connect from ISP's. (These
> can be accepted by explicit authentication or some other method.)
>
SA. Very rarely only a 'might be'.
Anyone 'AUTH'ing remotely - hopefully on port 587, but regardless - will *nearly
always* need a pass.
Main exceptions I can think of are:
- on-box shell account holders ssh'ed in and invoking a binary (a non_smtp
session anyway from Exim's point of view)
- SOME (not all) webmail daemon users - which could be either invoking a binary
OR jumping off to a local or remote full smtp session. In that case it will be
the credentials of the host on which they sit - not your borrowed laptop - that
counts.
CAVEAT: Some Mailing List Managers do full smtp sessions and may need special
handling, *especially* if they HELO as 'yourself'.
> 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).
>
>
One man's spam is another's Lonely Hearts Club here.
Some of these are clearly abusers - claiming to be legitimate 'double-opt-in'
list runners to civil authorities when they are mostly NOT. Often the case is
that they take on contract broadcasts w/o checking what is going to be sent.
Many don't care as long as the money is good.
Others are quasi-legit. Many examples abound in the travel industry or vehicle
warranty expiration adverts that you didn't agree to receive - yet cannot seem
to stop any other way. That may have been in the fine print when you checked an
online used-car advert or researched a vehicle history.
HTH,
Bill
