Email Server and DNS

rwebb at rwebb at
Fri Nov 8 12:48:08 UTC 2013

Thanks to everyone for all the tips and info. I think I have compiled 
plenty of info to get this done. I will probably start with some of 
the basics and see how things go. THen as needed start putting in some 
additional features as I see how things progress.


On Fri, 8 Nov 2013 07:37:40 -0500
  Rich Kulawiec <rsk at> wrote:
> I suggest moving this to mailop, where it arguably belongs.  But I'm
> going to follow up on a few points, anyway.
>First, I forgot to mention two other highly effective mail system
> defense methods: geoblocking and passive OS fingerprinting.
> Geoblocking: A mail server for a local construction business in 
> is unlikely to require mail from Poland, Peru or Pakistan.  So 
> no reason to go with a default-permit model: use default-deny and
> only allow mail from places where legitimate mail might originate.
> (In this case, perhaps: the US, Mexico, and Canada.)  Use the ranges
> from  This will stop an astonishing amount of spam (and
> other SMTP-borne abuse) cold.  And it can be done at the MTA or in
> the firewall: which is better depends on circumstances.
> Obviously this doesn't work for everyone.  Obviously this (like
> everything else) runs the risk of false positives -- but it's easy
> to mitigate that.  Obviously it does require understanding the
> patterns in your mail traffic, but any competent mail system admin
> has long since performed detailed statistical analysis and has a
> pretty good idea what the characteristics of their incoming mail
> stream look like.
> Passive OS fingerprinting: regard anything originating from an OS
> that fingerprints as Windows as dubious, at best.  Possible actions
> vary: graylisting (more precisely, graylisting regardless of 
> traffic) is one good option.  Utilizing this in concert with 
> (above) works beautifully, e.g., "I'm in Arizona and something in 
> that fingerprints as Windows is trying to send me SMTP traffic: the
> probability approaches unity that this is spam".  When combined with
> rDNS information, this becomes a highly efficient mechanism with a 
> rate that's ridiculously low.  (In other words, if that same system
> has rDNS that looks like then it either 
> is a bot or it's a mail system run by someone with no clue.)
> A few short points and one long one in response:
> On Sun, Nov 03, 2013 at 12:00:23PM -0600, Jimmy Hess wrote:
>> The RFC contains a MUST NOT  in regards to verifying the  HELO name 
>> So, the HELO can use any hostname ---  as long as the hostname 
>> resolves to something;  it should resolve to the IP address of one 
>>of your
>> mail servers.    Some mail servers provide service for many domains, 
>> have many DNS names that could be placed in a HELO.
> All true.  But none of this argues against using the canonical 
> in the HELO.  It's the simplest, easiest option (and quite often the
> one that software will pick by default).
>> > SPF is worthless crap: don't bother.  Use a real MTA, e.g., 
>> >
>> I do not believe that is the consensus of the community -- or the 
>> groups behind the SPF-related RFCs.
> I'm well aware it's not the consensus.  It's my opinion.
> Clue #1 that SPF is crap should have been its grandiose 
> announcement ("Spam as a technical problem is solved by SPF").  Clue 
> should have been the observation that -- by far -- the most prolific
> early adopters were spammers.  When your enemy latches on to your
> new weapon much faster than you do, that should be a tipoff that 
>maybe it's
> not what you hope it is.  Clue #3 is available to anyone who deploys 
> sufficiently large and diverse set of spamtraps for several years 
> analyzes the data that arrives: SPF presence/absence or contents 
> no statistically useful anti-spam value in a properly-designed mail
> defense architecture.  
> Don't believe me?  Okay.  Fine.  Set up a few thousand spamtraps, 
> data for 3-5 years, see for yourself.
> So yes, it's standardized; so what?  So is (sort of) DNS forgery, 
> for 
> That's also crap, it just happens to be well-documented crap.
> So: if you feel you must use something, use DKIM, which I think 
> vastly more promise.  Just don't expect it to be a panacea, because
> the current miserable state of security at *all* levels undercuts it
> badly.  Not DKIM's fault, really, but it does impact its usefulness
> in the real world.
>> Message quarantines are great;  they are helpful  for mitigating the 
>> positives of overly-agressive filters.
> This one I'll spend more time on.  Quarantines are a worst practice 
> in mail systems engineering.  Here are some assorted reasons why, 
> - One of the fundamental principles of mail system defense is that 
> should make your mistakes early, consistently, and loudly.  (And you
> WILL make mistakes.   Everyone does.)  The point of doing this is 
> it enables all concerned, including you, to have a decent chance of
> noticing them, figuring out that they're mistakes, and correcting 
> Quarantines hide, defer, and silence your mistakes, making it much 
> difficult to run your system properly.  They're a lazy admin's 
> not a fix.
> - Quarantines present deadlock problems.  Mail from user A to user B
> which is quarantined and causes B to eventually send a message to 
>user A
> enquiring about the missing missive stands a decent chance of ending 
> in B's quarantine.  The end result is that human time (which is a 
> and expensive commodity) is needlessly wasted figuring out the 
> and then trying to evade it, usually by trying to tapdance a way 
> the filters on both sides.  Contrast with a hard, immediate 
> which -- coupled with an appropriate resolution mechanism -- 
> quick, easy diagnosis and repair.
> - Some people use quarantines because they're unduly concerned about
> their false positive rate.  But slapping the ill-advised band-aid of 
> quarantine on an underlying problem like a high FP rate solves 
> It merely obscures the mistake.  The correct solution is to figure 
>out why
> the FP rate is high, and fix that, because that's where the problem 
> - Users have spent the past two decades or so conclusively proving, 
> any possible argument, that they are utterly incapable of 
> spam from non-spam, phish from non-phish.  (Consider carefully: if 
> could, en masse and accurately, would we have the scope and scale of 
> problem set we currently face?  No.  We would not.)  "Educating 
>users" is
> a complete failure as a strategy; see point #5 here:
> 	The Six Dumbest Ideas in Computer Security
> Even personnel who *work in security* can't solve this 
> problem correctly (which is why I said "ask RSA how that's working
> out for them").  Your users are no better.  They're probably worse.
> So punting the task of correctly classifying incoming mail to them 
> reckless and irresponsible.  With precious few and rare exceptions, 
> WILL fail.  Freuqently.  And sometimes (again: see RSA) the 
> of even a single failure can be catastrophic.
> More bluntly, allowing users anywhere near the machinery of 
> when they've proven for decades that they're absolutely unqualified 
> handle even its simplest aspects, is clearly unprofessional and 
> negligent.  Yes, this is somewhat a fascist, uncompromising, 
> etc. attitude.  It's also the only one that's been demonstrated to 
>work in
> the real world.  It's a shame, really, but this is not the 'net of 
> You can be nice and flexible and accomodating or you can be 
> secure.  Pick one.
> - Disposition of quarantined mail is problematic -- unless of course
> the intention is to let it accumulate indefinitely, which is a 
> idea at best.  Eventually, *something* has to be done.  Delivering 
> to the user is probably unwise, which you should already know, 
> you would have delivered it in the first place.  Simply deleting it 
> that you lied to the delivering MTA back when you first accepted it 
> and that's very poor operational practice.  Not to mention quite 
> So what, *exactly*, do you plan to do with it?  When?  How?
> - Informing users of quarantined mail is another problem.  Anyone 
> any familiarity with user behavior knows that they'll click on 
> and everything in a heartbeat without performing any kind of due 
> So that well-crafted spear phish that you should have rejected 
> but quarantined because it scored well enough on your 
> system?  Your user is going to pull that right back and open it as 
> as they glance over the "Subject" line quickly in Monday morning's
> quarantine report, and you will be 0wned by lunchtime.  Game over, 
> - On top of all of this, there's an even more fundamental strategic 
> Spam is (among many other things) an attack on the time and 
> of recipients.  Mail system operators who deploy quarantines are
> aiding and abetting that attack, because they're chewing up the same
> scarce and expensive resources: time and attention.  One of the 
> of a mail defense system is to reduce that time and attention to 
> Of course, under real-world conditions, that's never possible -- 
> one should always strive to asymptotically approach it.  But 
> are clearly a massive step in the wrong direction, for what I trust
> are abundantly obvious reasons.
>> Implemented appropriately;  an SMTP callout (or "SMTP connect"
>> verification) to the connecting IP is a great way to help resolve 
>> suspiciousness level of the sending mail server.
> No, it's always abusive.  As analysis carried out by the late Bruce
> Gingery, myself, and others on spam-l years ago (when Verizon was 
> this) demonstrates, allowing others to cause your operation to 
> outbound SMTP traffic to third parties of *their* choosing is a 
> tactical error.  It furnishes a free, scalable DDoS support service 
> which, unfortunately, is not a hypothetical issue.  It also 
> third-party bypass of others' security mechanisms, which, depending 
> your legal jurisdiction, may be an issue: I would recommend 
> your attorneys before deploying it, and asking them what exposure 
> incur by doing so.  And on top of all that, it has no anti-spam 
> whatsoever.  (Note: self-directed callouts, to one's own internal 
> infrastructure, are not abusive.  They're inefficient, and much 
> methods nearly always exist for providing the same functionality, 
> they're not abusive.)
>> Using the name [email protected]  for the abuse contact  is not required,  and 
>>it is
>> likely to be targetted by spammers.
> Of course it will be.  So will "postmaster".   So will every other
> role and non-role address.  Any reasonably competent operation 
> have no problem dealing with that.  IMHO, anyone who cannot manage 
> rudimentary task of managing their "abuse" mailbox is wholly 
> to run a mail system.  (Or a web server, or a network, or anything 
> exposed to the public Internet.)
> ---rsk

More information about the NANOG mailing list