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)

  • From: Steven Champeon
  • Date: Wed Jan 12 11:06:16 2005

on Wed, Jan 12, 2005 at 01:52:43PM +0000, [email protected] 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., "1.2.3.4.dynamic.example.net"
   or "4.3.2.1.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!