At 09:21 AM 3/3/2005 +0000, you wrote:
The point of this mail is to suggest that maybe the SPF community's
attempts to
get an RFC right now are premature.
The problem being that the SPF 'solution' includes some implicit changes
to SMTP
to make the solution viable, so the single would-be-RFC is trying to re-define
aspects of SMTP practice at the same time as it is proposing a solution.
Suggestion: We should first seek an RFC in which the weaknesses in / problems
with SMTP are fixed, then propose SPF as a solution which fits that amended
SMTP. If the Internet community does not first agree the changes, then it's
logically pointless proceding with the cure to the wrong disease.
I think it would be a mistake to spend another year trying to fix SMTP, and
still not have a standard that will work for all authentication
methods. There are only a few things that need to be standardized so that
MTAs using different authentication methods can talk to each
other. Defining exactly what we mean by "sender" is not one of those things.
Each MTA can decide for itself which domain name to authenticate, using
whatever protocol it wants, and pass that name along in a standard
authentication header. Everything else, Return-Path, etc. should be left
as is. It doesn't affect *communication* from the authenticating MTA to
the final receiver. The protocols for each method can be as complicated as
they want, but the standard for how they communicate should be so simple,
that anyone trying to derail the process will look foolish.
Take a look at Scenario D at
http://www.ece.arizona.edu/~edatools/etc/Spam%20Scenarios.htm Here I took
some typical spam headers and inserted authentication headers in
blue. Authentication headers are added only when an email crosses an
administrative boundary. We really don't care about all the intermediate
systems within email forwarders like all the lines for pobox.com. The
authentication header appears immediately above the Received line for the
incoming MTA in each administrative domain. It includes *only* the
authenticated information from that Received line ( IP address and domain
name ), and keywords indicating the authentication method and result.
Unlike Received headers, an authentication header is an affirmative
statement "I authenticated this domain, using this protocol, and got this
result". False information here is evidence of lying or gross negligence,
not just forgivable errors in processing a complex pile of headers. This
will greatly reduce the administrative burden in deciding whether to
downgrade a domain.
A simple standard format for authentication headers makes it easy to skip
past trusted forwarders and get straight to the domain name that needs to
be used in spam filtering.
Comments are welcome.
-- Dave
************************************************************* *
* David MacQuigg, PhD * email: dmq'at'gci-net.com * *
* IC Design Engineer * phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* * 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. * Tucson, Arizona 85710 *
************************************************************* *