North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
fixing insecure email infrastructure (was: Re: [eweek article] Window of "anonymity" when domain exists, whois not updated yet)
on Wed, Jan 12, 2005 at 01:52:43PM +0000, Michael.Dillon@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. <snip> > 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 configurations. 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., "126.96.36.199.dynamic.example.net" or "188.8.131.52.dhcp.resnet.foo.edu") 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 possible.) 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 network). 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 images.) 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!