----- Original Message -----
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
To: "Jon Kyme" <jrk(_at_)merseymail(_dot_)com>
Cc: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Tuesday, March 09, 2004 3:27 PM
Subject: Re: [spf-discuss] Latest proposal re HELO checking: make HELO tests
optional
JK> Your problem is that if systems which use MAIL FROM as sender
JK> identification become widely deployed, the "real world" has changed
out
JK> from under you. And you can't point at the RFCs to support your
position.
My "problem" is the observation that proposals which require wide-scale
change to an existing semantic find themselves trying to overcome a
particularly massive barrier to adoption, and rarely overcome it.
You know the old saying... "A day late...."
In my opinion, what is currently available is based on SMTP compatibility
which a focus on enhancing, addressing, touching base, what have you, with
the current "holes" in the functional specifications.
None of the (LMAP based) specs change this except for adding enforcement in
areas that were lacking.
The SMTP specs says the HELO domain name "should" match the client IP.
New methods adds some level of enforcement.
The SMTP specs says the MAIL FROM "should" be valid.
New methods adds some level of enforcement.
The key difference from what I see out in the IETF mailing list and here as
well, is the two different schools of thought from an operational
standpoint.
o Dynamic SMTP validation methods, or
o Post SMTP validation methods.
It is amazing to see people argue or debate points based on their
perspective. In general, they agree with the basic ideas but not how they go
about it.
My approach is 100% based on SMTP validation methods. However, we are
vendors of email software too and we still have many "old school" customers
with gates and/or simply don't turn on the "Local Recipient Validation"
options which means that the mail is accepted and bounces are now part of
the process. With SMTP level validation, no bounces occur. In my view,
such enhanced systems do not contribute to the secondary tier distribution
process (bounces) that the SMTP based SORBIG generation viruses depend on.
Anyway, the IETF has had its chance to clear up the matter long ago. Now
you guys risk Microsoft/YAHOO defining the direction. "day late, dollar
short" For commercial vendors, support for Microsoft CID (regardless on how
crappy it is) and YDK is a no-brainer. It is not even a question.
In my opinion, the IETF needs to start looking at the inevitable, which is:
These POST DATA validation new technologies will force a change in SMTP due
to overhead and redundancy issues. When you couple methods such as CID and
YDK requiring the transmission of the data, and the market of people who do
post validation anyway, there will be a tremendous amount of extra
bandwidth. In the short term, it most probably be worth it. But in the
long run when it is all said and done and spammer management is reality, the
overhead issue now becomes a redundancy issue.
So someone needs to begin looking an new ESMTP specification that at minimum
begins to offer the following the support the new legal and technical
"mandates:"
o Support for CAN-SPAM or similar legal mandates
- TOPIC identification command (i.e., new SUBJ command (keeping with 4
letter stds)
- Support for Sender Machine and/or Return Path validation
LMAP based solutions offer partial solution. CBV (call back verifiers) help
as well. Needs better ESMTP based solution.
o Support for addressing POST validation (high payload) streaming data
transfer
- DATA split into turn commands
In my view, the best solution is to simply split the DATA command to two
commands:
HEAD
DATA (or BODY)
I don't think we can get around from eliminating the current envelope
entities, maybe HELO if automatic PTR lookups are done for tracing. But
the main reason is the originating servers who might not received a RFC x822
ready header. However, compliant ESMTP clients who do use the HEAD might
be required to include the envelope in the HEAD block.
The future CIDS/YDK or POST validations systems will required a more advance
SMTP transaction protocol otherwise we are simply creating a huge network
bandwidth problem which at first will be justified because people will say
"Hey, no more spam," but eventually, when spam is "forgotten", it is now a
high payload redundancy problem.
That's might take on it.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com