There is a tremendous amount of myth propogated in this document.
The notion that email authentication has helped reduce spam is completely
unsubstantiated by actual practice. We have just recently observed the
failure of SPF, largely due to the fact it didn't work. Email
authentication, even if possible by some other method, doesn't solve the
problem, since it is the equivalent of dialup problem:
Every user is authorized to send email until they aren't.
Only their service provider can remove that authorization
And of course, it isn't just users who send email. Devices send email,
too.
Service providers aren't complaining that they can't identify they users.
Rather, the people frustrated by email authentication are the end user
recipients of spam. Email authentication isn't going to lessen that. Even
if it were do-able (and done), end-users and other carriers wouldn't have
access to the subscriber identity information. And if they are your
subscriber, you usually don't have any lack of identity information given
a spam and its headers.
Service providers implementing protocols like SMTP-AUTH have not reported
that SMTP-AUTH results in less spam. Just the opposite is usually the
case: No change.
Email authentication isn't a weakness that is exploited by spammers.
commercial bulk emailers are by and large compliant with the CAN-SPAM act.
The CAN-SPAM Act has demonstrated a distinction between commercial bulk
emailers and abusers with no direct commercial purpose. (see
http://www.av8.net/SpamTypes.txt). Abusers have been using viruses and
rooted computers to send abuse email. It is not the economics of
commercial bulk email, nor the lack of email authentication that is the
problem. It is the economics of anti-spam blacklists that shows that
"economic value" of virus/abuse "spam". Blacklists such as SORBS are now
charging (extorting) money from both users and victims.
And lastly, it seems inappropriate that such a draft would be proposed
with language about open relays without seeking the input of open relay
operators such as Av8 Internet. Av8 Internet is one of the very few open
relay operators that is willing to publicly discuss these operations.
Av8 has operated open relays since 1996 and has considerable experience
with abusers and the methods of protecting open relays from abuse. While
groups like Nanog have worked to suppress certain viewpoints
(http://www.iadl.org/nanog/nanog-story.html -- this page is not yet
finished, but I've made an early version available) it is still well-known
that I am willing to discuss the issues and have a lot of research to
support my views.
Had anyone bothered to ask, I would have reported that open relay abuse
has dropped off to nearly nothing since the open relay blacklists shutdown
in 2003. Previous testing of open relay blacklists had revealed that they
were involved in directly or indirectly supporting abuse, promoting abuse,
and even soliciting the abuse of open relays. Logs revealed that these
blacklists were the only groups systematically searching for open relays
to abuse, and that open relays were only abused after discovery by the
open relay blacklists.
I do note that open relay abuse has resumed slightly since SORBS.NET
started scanning for open relays in March 2005, but there are presently
only about 5 IP addressses abusing our relays, despite the well-known fact
that we operate open relays. In the past, we would sometimes see as many
as 2400 IP addresses trying to abuse our relays. Nearly all of this abuse
is fairly trivially detected and blocked. Open relays do not present any
"problem" to be addressed.
I think the IETF should make more efforts to make sure that its
recommended best common practices are based on facts rather than myths.
Dean Anderson
Av8 Internet, Inc
=====================================================================
Best practices are:
o Operators of MSAs MUST perform authentication during mail
submission, based on an existing relationship with the submitting
entity. This requirement applies to all mail submission
mechanisms.
o For email being received from outside their local operational
environment, email service operators MUST distinguish between mail
that will be delivered inside that environment, from mail that is
to be relayed back out to the Internet. This allows the MTA to
restrict this operation, preventing the problem embodied by "open"
relays.
o Mail coming from outside an email operator's local environment,
and having a RCPT-TO address that resolves to a destination that
is also outside the local environment, MUST be treated as mail
submission, rather than mail relaying. Hence it must be subjected
to mail submission authorization and validation checks.
o MDAs SHALL NOT accept mail to recipients for which that MDA has no
arrangement to perform delivery.
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf