----- Original Message -----
From: "Alan DeKok" <aland(_at_)ox(_dot_)org>
To: <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Thursday, September 16, 2004 4:32 PM
Subject: Re: SPF abused by spammers
I do not believe that there is enough consensus as to what "EHLO"
checking means, or "MAIL FROM" checking means. Without that
consensus, we have no quantitative way of comparing proposals, or for
deciding if a proposal meets our requirements.
Alan,
One of the key reasons I stayed away for the most part from this discussion
is because I don't think much progress will be made until RFC 2821
functional specification are modified to allow for enforcement and for
proper operations in a reduced and managed "spam world."
What is being proposed has many legal and operational ramifications and
until the RFC 2821 is modified, compliant legacy systems will continue to be
problematic, both technically and legally.
There are three (3) problems as I see it based on product operations:
1) The forwarding issue as we all know it,
2) US EPCA related issues regarding privacy, and
3) Malpractice and Bandwidth issues with Dynamic vs. Post SMTP analysis.
The industry has had two decades of standard email operational precedence
that 100% addressed #2 and #3. Systems were designed and engineered with the
corresponding ECPA laws in the books in mind.
It is my strong belief based on 20+ years of exclusive telecommunications
and electronic mail design and production, that Microsoft SenderID proposal
hits smack against the tradition with a major risk of creating many new
legal issues.
To summary the concerns:
The SUBMITTER concept will enforce SUBMITTER compliant ISP to operate in a
mode were users are no longer allowed to use alias email addresses. This
has already been proved to be the case when the SPF compliant ISP has users
using alias email addresses and it failed at the SPF compliant MDA.
Microsoft's SUBMITTER will raise privacy concerns because the ISP must send
the user's main account with the mail transaction, an action the user many
not want.
The PRA concept will break optimized operations using dynamic SMTP
operations. It will enforce payload transmissions which has three critical
issues with it:
1) Risk operating in a mode where failure to delivery mail runs against the
US EPCA user rights for delivery expectations.
2) Introduces higher network bandwidth across all PRA compliant points.
3) Introduces higher and unnecessary bounce mail operations which is a major
factor in the distribution of malicious electronic mail.
It is for these key reasons, Santronics can not support the Microsoft
proposals based on its technical merits. This does not take away the fact
that we made be forced to do so based on customer and market pressures, but
it is not something we wish to spend resources on. I firmly believe there
are better solutions and in my opinion, it begins with getting all the
issues with SMTP specifications squared away.
Once the industry, the world, has a new basis for SMTP operations, then all
the authentication and validations ideas make more sense and work more
reliably. All future SMTP products will have "new rules" to work and more
importantly remains legal with the current laws in the books.
In my view, the following effort should be done:
1) SMTP specification refinement to clear all the ambiguities and specify
the new enforcement issues.
2) At a minimum, introduce 2 new ESMTP commands:
TOPIC (or SUBJ to keep with the 4 letter standard)
HEAD
Both items solves the following:
1) It address optimized support for CANSPAM at the transport level
2) It address optimized support for Header Analysis at the transport level.
3) It helps the Microsoft PRA proposal.
4) It eliminates the payload problem.
5) It keeps the operation legal with no conflicts with the current EPCA
related laws in the books.
Note, none of this takes away from SPF or MARID, but currently what is
being proposed does not help the process for all parties. Since change is
required at some level for the SMTP server and receiver, we might as get it
right with the minimum requirements to address spam/spoofing.
Thanks
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office