[IP] worth reading djf announcing email-security.net
Begin forwarded message:
From: Steven Champeon <schampeo@xxxxxxxxxxx>
Date: October 2, 2005 10:03:00 AM EDT
To: David Farber <dave@xxxxxxxxxx>
Cc: Ed Gerck <egerck@xxxxxxx>
Subject: Re: [IP] announcing email-security.net
on Fri, Sep 30, 2005 at 05:37:16PM -0400, David Farber wrote:
From: Ed Gerck <egerck@xxxxxxx>
Date: September 30, 2005 4:49:45 PM EDT
To: David Farber <dave@xxxxxxxxxx>
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 roessler@xxxxxxxxxxxxxxxxxx
To manage your subscription, go to
http://v2.listbox.com/member/?listname=ip
Archives at: http://www.interesting-people.org/archives/interesting-people/