Email Server and DNS
rwebb at ropeguru.com
rwebb at ropeguru.com
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.
Robert
On Fri, 8 Nov 2013 07:37:40 -0500
Rich Kulawiec <rsk at gsp.org> 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
>Arizona
> is unlikely to require mail from Poland, Peru or Pakistan. So
>there's
> 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 ipdeny.com. 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
>previous
> traffic) is one good option. Utilizing this in concert with
>geoblocking
> (above) works beautifully, e.g., "I'm in Arizona and something in
>Portugal
> 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
>FP
> rate that's ridiculously low. (In other words, if that same system
> has rDNS that looks like 123-45-67-8.example.com then it either
>really
> 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
>>matches.
>> So, the HELO can use any hostname --- as long as the hostname
>>forward
>> resolves to something; it should resolve to the IP address of one
>>of your
>> mail servers. Some mail servers provide service for many domains,
>>and
>> have many DNS names that could be placed in a HELO.
>
> All true. But none of this argues against using the canonical
>hostname
> 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.,
>>postfix
>> >
>>
>> I do not believe that is the consensus of the community -- or the
>>working
>> 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
>self-promoting
> announcement ("Spam as a technical problem is solved by SPF"). Clue
>#2
> 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
>a
> sufficiently large and diverse set of spamtraps for several years
>and
> analyzes the data that arrives: SPF presence/absence or contents
>have
> 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,
>gather
> data for 3-5 years, see for yourself.
>
> So yes, it's standardized; so what? So is (sort of) DNS forgery,
>see
> http://tools.ietf.org/html/draft-livingood-dns-redirect-03 for
>example.
> 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
>shows
> 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
>>false
>> 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,
>briefly:
>
> - One of the fundamental principles of mail system defense is that
>you
> should make your mistakes early, consistently, and loudly. (And you
> WILL make mistakes. Everyone does.) The point of doing this is
>that
> it enables all concerned, including you, to have a decent chance of
> noticing them, figuring out that they're mistakes, and correcting
>them.
> Quarantines hide, defer, and silence your mistakes, making it much
>more
> difficult to run your system properly. They're a lazy admin's
>coverup,
> 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
>up
> in B's quarantine. The end result is that human time (which is a
>scarce
> and expensive commodity) is needlessly wasted figuring out the
>problem
> and then trying to evade it, usually by trying to tapdance a way
>past
> the filters on both sides. Contrast with a hard, immediate
>rejection,
> which -- coupled with an appropriate resolution mechanism --
>facilitates
> 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
>a
> quarantine on an underlying problem like a high FP rate solves
>nothing.
> 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
>is.
>
> - Users have spent the past two decades or so conclusively proving,
>beyond
> any possible argument, that they are utterly incapable of
>distinguishing
> spam from non-spam, phish from non-phish. (Consider carefully: if
>they
> could, en masse and accurately, would we have the scope and scale of
>the
> 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
> http://www.ranum.com/security/computer_security/editorials/dumb/
>
> Even personnel who *work in security* can't solve this
>classification
> 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
>is
> reckless and irresponsible. With precious few and rare exceptions,
>they
> WILL fail. Freuqently. And sometimes (again: see RSA) the
>consequences
> of even a single failure can be catastrophic.
>
> More bluntly, allowing users anywhere near the machinery of
>security,
> when they've proven for decades that they're absolutely unqualified
>to
> handle even its simplest aspects, is clearly unprofessional and
>highly
> negligent. Yes, this is somewhat a fascist, uncompromising,
>condescending,
> 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
>1983.
> You can be nice and flexible and accomodating or you can be
>(modestly)
> secure. Pick one.
>
> - Disposition of quarantined mail is problematic -- unless of course
> the intention is to let it accumulate indefinitely, which is a
>dubious
> idea at best. Eventually, *something* has to be done. Delivering
>it
> to the user is probably unwise, which you should already know,
>otherwise
> you would have delivered it in the first place. Simply deleting it
>means
> that you lied to the delivering MTA back when you first accepted it
>--
> and that's very poor operational practice. Not to mention quite
>rude.
> So what, *exactly*, do you plan to do with it? When? How?
>
> - Informing users of quarantined mail is another problem. Anyone
>with
> any familiarity with user behavior knows that they'll click on
>anything
> and everything in a heartbeat without performing any kind of due
>diligence.
> So that well-crafted spear phish that you should have rejected
>outright
> but quarantined because it scored well enough on your
>content-screening
> system? Your user is going to pull that right back and open it as
>soon
> as they glance over the "Subject" line quickly in Monday morning's
> quarantine report, and you will be 0wned by lunchtime. Game over,
>man.
>
> - On top of all of this, there's an even more fundamental strategic
>problem.
> Spam is (among many other things) an attack on the time and
>attention
> 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
>goals
> of a mail defense system is to reduce that time and attention to
>zero.
> Of course, under real-world conditions, that's never possible --
>still,
> one should always strive to asymptotically approach it. But
>quarantines
> 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
>>the
>> 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
>doing
> this) demonstrates, allowing others to cause your operation to
>generate
> outbound SMTP traffic to third parties of *their* choosing is a
>serious
> tactical error. It furnishes a free, scalable DDoS support service
>--
> which, unfortunately, is not a hypothetical issue. It also
>facilitates
> third-party bypass of others' security mechanisms, which, depending
>on
> your legal jurisdiction, may be an issue: I would recommend
>consulting
> your attorneys before deploying it, and asking them what exposure
>you
> incur by doing so. And on top of all that, it has no anti-spam
>value
> whatsoever. (Note: self-directed callouts, to one's own internal
>mail
> infrastructure, are not abusive. They're inefficient, and much
>better
> methods nearly always exist for providing the same functionality,
>but
> they're not abusive.)
>
>> Using the name abuse@ 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
>should
> have no problem dealing with that. IMHO, anyone who cannot manage
>the
> rudimentary task of managing their "abuse" mailbox is wholly
>unqualified
> to run a mail system. (Or a web server, or a network, or anything
>else
> exposed to the public Internet.)
>
> ---rsk
>
>
More information about the NANOG
mailing list