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 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
