worth reading djf announcing email-security.net

[David Farber <dave () farber net>]

Begin forwarded message:

From: Steven Champeon <schampeo () hesketh com>
Date: October 2, 2005 10:03:00 AM EDT
To: David Farber <dave () farber net>
Cc: Ed Gerck <egerck () nma com>
Subject: Re: [IP] announcing email-security.net


on Fri, Sep 30, 2005 at 05:37:16PM -0400, David Farber wrote:

> From: Ed Gerck <egerck () nma com>
> Date: September 30, 2005 4:49:45 PM EDT
> To: David Farber <dave () farber net>
> Subject: announcing email-security.net
>
>
> Dave,
>
> I'd like to get IPers feedback on the opening discussion paper
> at email-security.net, which is a technical development forum
> dedicated to a fresh exploration of the Internet email security
> issues of today. Comments and paper contributions on the theme
> of email security are welcome. Papers will be peer-reviewed
> before publication. Product and service listings are also
> welcome, search-engine style (short pitch + link).

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.

--
hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http:// 
hesketh.com
antispam news, solutions for sendmail, exim, postfix: http:// 
enemieslist.com/


-------------------------------------
You are subscribed as lists-ip () insecure org
To manage your subscription, go to
 http://v2.listbox.com/member/?listname=ip

Archives at: http://www.interesting-people.org/archives/interesting-people/