fixing insecure email infrastructure (was: Re: [eweek article] Window of "anonymity" when domain exists, whois not updated yet)
schampeo at hesketh.com
Wed Jan 12 15:59:43 UTC 2005
on Wed, Jan 12, 2005 at 01:52:43PM +0000, Michael.Dillon at radianz.com wrote:
> I think that a secure email infrastructure is a good thing to have, in
> and of itself. By secure, I mean one in which messages get to their
> destination reliably, i.e. not lost in some spam filter, and one in
> which a recipient can reliably know where the message came from if
> they feel the need to track down the sender by other means.
> In a sense, I am suggesting a similar reallocation of resources.
> Rather than put those resources into filtering spam, I'd suggest that
> we will get a better result by shifting the resources into mail
> relaying and managing mail peering agreements. The spam will continue
> but users will move to using the secure mail architecture and won't
> see most of it. When the spammers also shift, there will be more tools
> to track them down or shut them down or simply to rate limit them.
OK, sounds great. Let's start by making a few SHOULDs and MAYs into
MUSTs. Some of the following could be accomplished in a few hours, some
are probably not fixable unless we can reallocate some of the trillions
of hours we waste fighting spam to the problem AND get some political
support for accomplishing them (such as fixing whois once and for all).
Bear in mind that "fixing email" largely means "fixing all the other
brokenness that allows people to take advantage of email's trust model".
So, then, it means fixing DNS conventions, abuse reporting support
infrastructure (starting with whois), and broken mail server/client
0) for the love of God, Montresor, just block port 25 outbound already.
1) any legitimate mail source MUST have valid, functioning, non-generic
rDNS indicating that it is a mail server or source. (Most do, many do
not. There is NO reason why not.) Corollary: any NONlegitimate mail
source SHOULD be labeled as such (e.g., "18.104.22.168.dynamic.example.net"
2) any legitimate mail source MUST HELO/EHLO with its own valid Internet
hostname, not "foo.local" or "SHIZNITSONY26354" or "exchng1". Or,
with their own bracketed IP. (Most do, many do not. There are very
few valid reasons why not. Broken software should be fixed.)
3) any legitimate mail source MUST be in a domain with functioning abuse
and postmaster mailboxes, which MUST also be listed in the whois db
entry for both that domain and IP space corresponding to the mail
source. (Not difficult to do at all.)
4) all domains with invalid whois data MUST be deactivated (not
confiscated, just temporarily removed from the root dbs) immediately
and their owners contacted. (NOTE: this will require fixing .org,
among others whose public whois output is stale and not easily
fixable via certain registrars). (Would probably take the most
effort, but given a properly broad window of notification should be
5) whois data MUST be normalized and available in machine-readable form
(such as a standard XML schema) - the "I hate spam so I use a bogus
contact addy" excuse will be obsolete, as email infrastructure will
be secured, right? (Honestly, how hard would this be? Gather up all
the now-extremely varied formats, compromise on a superset, and map.
Then put it all on a Web site or a reliable, distributed
infrastructure. I'm REALLY TIRED of getting "whois.$foo:111
connection refused" when I'm trying to track down a spammer's support
6) all mail clients MUST support SMTP AUTH and the MSA port. (Many do.)
All mail servers MUST support SMTP AUTH and the MSA port. (Some do.)
7) all ISPs MUST act on ANY single abuse report (including being
informed of infected customer machines, which MUST be removed from
the Internet ASAP. No excuses) (Halve unemployment today. Retrain
textile and manufacturing workers. Outsource the entire job. I don't
care. Go read "broken windows theory".)
8) all mail server, antivirus, and antispam software MUST NOT accept and
then bounce (to the usually forged sender) bogus "warnings" or DSNs.
(A chicken/egg problem, really, but some systems have NO excuse -
such as A/V systems that helpfully inform me that some virus that
ALWAYS forges the sender did so in a message sent from a system I
have no control over.)
9) all mail servers and webmail systems, etc. MUST properly include
tracking information in their Received: headers. (You might be
surprised how many webmail systems and large ISPs fail this one.
It's largely how 419/AFF scams are propogated.)
10) all HTML display engines MUST fix the bugs that allow for a
link to say, 'phish.randomisp.net.br' appear as 'wamu.com'
(Social engineering, but important in this day of hostile JPG
That should do it. I'd also ask that HTML email simply vanish, since I'm
clearly already rubbing this lamp down to its bitter metal core... ;)
hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com
join us! http://hesketh.com/about/careers/account_manager.html join us!
More information about the NANOG