RE: [IP] announcing email-security.net

It seems to me that encryption is the least of our problems, as complex, confusing, costly (tried to download a free PGP plugin for Outlook lately?) and as generally unnecessary as it is (for the vast majority of messages, anyway).

This is especially true and unsurprising when you realize that many mail servers out there:

- don't identify themselves (using HELO or EHLO) using strings that remotely resemble valid Internet host/domain names, as required in RFC 2821, section 4.1 ff. I've seen unbracketed IPs, RFC 1918 IPs, "localhost", "localhost.localdomain", ".", and my all-time fave:

schampeo@habanero:1029 $ host 209.0.51.16 16.51.0.209.in-addr.arpa domain name pointer Alameda.net.has.not.owned.this.ip.for.more.then.four.years.

- as such, don't reject much mail based on forged/bogus HELO, because hey! nobody does it properly, so it's not a valid grounds for refusing spam and viruses. This even though late 2003 saw massive attacks from worms and viruses that HELO'd with the NetBIOS name of the infected computer! Later versions learned that some folks blocked HELOs with no "." and so started appending a random ".com", ".net" or ".org" to the NetBIOS name of the infected computer. :/ I believe now that some append a legitimate domain name (so you get "oemcomputer.erols.com" instead of just "oemcomputer"). No matter that the names don't exist.

- don't refuse mail, even when the sending "client" claims to be the IP or any of the hostnames known to the server (in other words, they walk up and say "Hi, I'm Dave Farber! Want some cheap meds?")

- accept unwanted messages, and then, after missing the chance to refuse inline, trust the almost always forged or bogus sender when generating NDN messages (known as "outscatter", a clarification of the older term, "backscatter", which was misleading), resulting in a flood of third party abuse and still more vectors for infection or promulgation of the spam.

- don't have matching forward and reverse DNS (or don't have rDNS at all, despite AOL's refusal to accept mail from such hosts)

- don't have reverse DNS that indicates that the server handles mail (or have rDNS that suggests that it's just part of a pool of dynamic addresses, or about which even less is known) so hapless mail admins can tell the difference between, say,

ip-65-38-111-161.hou.vericenter.com

and the tens of thousands of other infected hosts that start with

ip-1-2-3-4

in over a hundred domains (I know about at least 124 domains using that naming convention) that are actively spamming us. The example given is an edge case, as it has two PTRs, one given above, the other is mail.schipul.net. Unfortunately, it HELOs as something else entirely. :/

-don't support SMTP AUTH or port 587 for submissions, because it's ridiculously complex to try to provide tech support for people using Outlook or other mail clients that don't support SMTP AUTH in a useful manner, or make enabling it such a battle that you may as well write a new client to save time.

- don't support TLS because they have to pay exorbitant fees to monopolists in order to use encryption

- don't block viruses inline, even though it's fairly obvious from simple header inspection which files are likely to be infected (or, more importantly, which files are likely to be able to exploit bugs in mail clients, due to the 3-character extension mapping) and instead accept likely infected mail, scan it, and sometimes even send a copy back to the (forged) "sender", spreading the virus further. Road Runner recently started /cleansing/ such messages and then sending an annoybot message to the (forged) "sender", even though nearly all modern mass mailing viruses are known to forge senders.

- don't include adequate audit trail for injected messages, such that they can be traced to the IP of origin (hotmail often inserts an IP in hotmail.com network space, due to a faulty NAT setup; gmail uses RFC 1918 10/8 addresses; cnchost/concentric, erasmas.com, clara.net, powweb.com, btconnect.com, cp.net, web.de, inet.it, infovia.com.ar, atlas.cz, spray.net, arcor-online.net, tiscali.fr, centrum.cz, bluewin.ch, optusnet.com.au, excite.it, tiscali.com, go.com, et al. all have lousy audit trails).

- don't wait for the remote server to issue a 220 greeting (gmail again, ctmail.com, quris.net, vianw.net, macromedia.com, evite.com, sourceforge.net, uu.net, netflix.com, clara.net, go2.pl, yahoo.com, etc.) before trying to send their messages - never mind that if the greeting isn't present it's not clear the remote server is even able to accept the message. It's the modern equivalent of picking up the phone to hear the telemarketer already deep into their spiel.

I know this because we receive a constant stream of outscatter from other hosts, to forged senders in domains we host mail for, which shows that the original messages these other hosts accepted failed all these tests and more. In short, more than a tenth of all email we handle here is the result of other people's failures to live up to basic best practices or the RFCs that define SMTP, period.

There are a lot of things that need to be more widely fixed before we should focus on how to protect the payload; we're lucky any of the messages we're trying to send are delivered at all, in the midst of all this pointless noise and the wretched poverty of basic RFC observance.

Steven Champeon