----- Original Message -----
From: "Andrew Newton" <andy(_at_)hxr(_dot_)us>
To: "Sam Hartman" <hartmans-ietf(_at_)mit(_dot_)edu>
Cc: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>; "MASS WG"
<ietf-mailsig(_at_)imc(_dot_)org>
Sent: Wednesday, March 30, 2005 9:41 AM
Subject: Re: draft-delany-domainkeys-base-02.txt
I'm again struck by the significant disparity in ideas of how email
works between participants of this list and in what level of breakage
can be tolerated.
Had there been better convergence on what "breaking email" means from
the start, we'd likely be done by now.
Unfair Andrew. It is well understood what the issues are. What "breaking
email" means.
I am 100% in full agreement with Sam on his assessment on the disparity of
how email works.
It is clear SMTP is the problem. The loopholes are in SMTP.
The question is how to "kludge" in a solution while maximizing backward
compatibility. If compatibility was not the issue, the solutions would be
found. Obviously.
But when a system still needs a working SMTP "operational plan" for
non-compliancy of "new proposals," for the most part, it makes the new
proposals somewhat worthless. There is no trust value in it. No
assurances, simply because there is no requirements.
We can put as many pad locks we want, but we still need to leave a key under
the potted plant to satisfy legacy software. That's the problem.
I don't have an answer without an open-minded serious discussion on the
client/server nature of SMTP. All I can conclude that the end result might
be to have a serious discussion on how non-compliancy may change localize
policies. As Sam says, "what level of breakage can be tolerated."
For example, we have a big company effort behind DK and IIM. So therefore,
as a business man, I can safely conclude a strong promotion on their part
will sell the idea to large enterprises. Same with Microsoft. Once SenderID
is part of the Exchange Upgrade, everything will change fellas. The
pressures will be on across the board to comply if only to satisfy
customers.
The question is, will the large enterprises now begin to have different
policies based on the type of mail received (DK/IIM or sender-id ready or
not)?
If so, will this new direction promoted first by the larger enterprises
begin to propagate cross the board to smaller entities?
In any case, at some point, someone will need to address the legacy SMTP
software issue which is clearly the basis for the exploitation that is going
on. If the SMTP loopholes did not exist, we wouldn't have much a spoofing
problem. We would not be here.
A good starting point would be for example, DK or IIM (for ALL new
proposals) is to introduce new ESMTP keywords that enforce new policies.
IIM can have ESMTP keywords such as:
IIM IIM optional by sender
IIM-R IIM required by sender
IIM-RP IIM required by sender policy (IP, domain based?)
etc.
If we are going to make sense of any new authorization proposal, I think we
need these new types CLIENT/SERVER policies as it will state upfront the
intent of the server both from a technical and more importantly legal
standpoint.
I think the migration can begin using ESMTP based stated policies.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office
http://www.winserver.com/wcsap (Wildcat! Sender Authentication Protocol)
http://www.winserver.com/spamstats (WcSAP Anti-Spam Stats)