I expressed concerns of the overhead for either SPF or Sender-ID and how
this may affect mail use. Marshall asked if there was possibly a better
solution this group should consider. Although this is a sensitive time,
as Sender-ID nears submission for Last Call, I decided to submit this
draft despite a potential for this being viewed as an attempt to derail
progress. I offer this only to allow a technical comparison and as a
response to Marshall's question. Although digital signatures are the
proper approach, this draft accommodates a Mail Channel/Mailbox Domain
relationship, being the basic mechanism used for both SPF and Sender-ID,
but treats this as an exceptional case.
The Mail Policy draft has been submitted as an I-D. The intent of this
draft is to illustrate a method that ensures a single DNS lookup is
required to discover mail policy. A lookup of the Mail Channel is also
possible with a single DNS lookup. This scheme leverages information
gained from the CSV authentication and allows applying policies for both
MAIL FROM and From, (a feature needed in the current draft.)
The use of the new APL RR is not essential, but offered as it uses a
binary RR as a means for a smaller and more concise record for
white-listing without requiring a TXT script and parser. The
white-listing feature of SPF was seen as one of its greatest assets.
Although this draft does not follow the path of least resistance with
respect to transforming SMTP, it does establish a foundation to allow
enforcement of policies with a goal directly aimed at abating abuse.
Sender-ID does not offer an identity safely accredited. The EHLO domain
forms the bedrock for identifying mail. By both authenticating this
EHLO domain and ensuring this is visible to the user, the ability to
spoof becomes greatly diminished. This draft extends this to include
identifying the mail channel for exceptional cases, where restrictions
on either the MAIL FROM or From is desired. This however only minimally
impacts normal mail use.
This scheme does not require parsing the RFC2822 headers and thus avoids
the IPR being claimed by Microsoft. It also better protects the From
and does not allow diversion of the check to a Resent-From header for
institutions wishing to protect their From field. It also expects the
further development of the BATV proposal that prevents common spammer
techniques not addressed by Sender-ID. This draft also allows this
technique to be addressed by way of MAIL FROM/Mail Channel restrictions
as well. The return-path is area overlooked by Sender-ID.
-Doug
draft-otis-marid-mpr-00.txt
Description: Text document