----- Original Message -----
From: "John C Klensin" <john(_at_)jck(_dot_)com>
To: "Keith Moore" <moore(_at_)cs(_dot_)utk(_dot_)edu>
Cc: "Vince Sabio" <vince(_at_)vjs(_dot_)org>; "ietf-smtp"
<ietf-smtp(_at_)imc(_dot_)org>
Sent: Tuesday, March 08, 2005 8:40 AM
Subject: Re: Site policy vs. HELO
Yep. I should have said
"those weak methods increase the volume of spam, cause more
false positives when they fail to work precisely, and generally
reduce the transparency and reliability of the email network"
Hi John,
Do you have any emperical statistics, documentation, proof or otherwise or
specific "methods" which matches or comes close to these assertions?
I mean, we am not not seeing any of this at all. Complete opposite. There
is a major DNS issue with the DNS based email authentication proposals, but
there are ways around it.
Does that sound like I'm not impressed with them as a partial
solution? :-(
What I do see is an unfortunate trend to focus on a payload "fuzzy" analysis
solution. These are the ones I suspect will have severe impact on the
network, a increase of mail oblivion and decrease of proper system
notifications.
We need to remove all fuzzy analysis of mail from the SMTP client/server
transaction.
Over the pass year and a half, we have proved that by increasing the level
of SMTP compliancy required by senders, you can address an extremely high
rejection rate with a very low to non-existence false positives. 100%
based on SMTP compliancy.
That should not be a surprise to no one: By industry measurements, over
60-80% of all transactions are spoofed, bad user or NXDOMAIN.
The questions we need to face are:
How much longer do we accept malicious transactions to use non-compliant
SMTP transactions?
The argument of legacy issues as a reason not to even consider stronger SMTP
compliant is not only a red herring but old thinking.
Most modern SMTP systems are compliant and legitimate senders are indeed
compliant.
It is the exact segment of the population of malicious transaction who are
not SMTP compliant thus exploiting the weak provisions by not applying
pressure to comply.
The argument that spammers will adjust to become SMTP compliant, to which I
said "GREAT!" it is exactly what we should want. Make the spammer change
in our direction.
Once the spammer is SMTP compliant, they become more "traceable", given
strength to the US Federal law called CANSPAM and new ideas and new sender
authentication inventions will work even better.
But I always felt we were jumping the gun by trying to kludge ideas or
wrappers around an exploitable SMTP system, when in fact we need to get the
SMTP compliancy issue resolved first. We did for our system and I consider
it a major success for our customers.
What are we going to do to strengthen SMTP transaction?
I propose we begin with complete review of the RFC-2821 document to remove
all ambiguity and to give developers the power to strengthen the
transaction.
We can't continue under the basis that we need not handle or skip the
validation process just because it is possible to be non-compliant. We need
to get over this hurdle and in my opinion, until we do, we will continue to
have these "get-no-where" "I'm right, you are wrong" discussions.
So I propose that we take a step back and look at RFC 2821 and discuss what
areas need to change to provide SMTP compliancy enforcement at the first
step towards addressing the spam problem.
I hope I am not off based, but I find much of I read here ridiculous,
spending more time bashing each other than getting any real significant work
done when in fact, its is all right there in front of us.
Someone needs to get a hold of the ball and begin making changes to RFC
2821.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office