On Wed, 2004-09-08 at 06:37, Andrew Newton wrote:
It is the opinion of the co-chairs at this time (before the end of last
call) that the MARID working group has no consensus regarding the
deployment of Sender ID. This lack of consensus centers around the IPR
associated with the PRA algorithm. Since predicting deployment is a
subjective matter and not strictly a technical concern, we would like
to offer the working group a proposal for modifying Sender ID that
would take the issue of deployment out of the hands of the IETF and
place it in the hands of the ultimate decision-makers, the systems and
network administrators of the Internet. We feel that this is where
decisions of deployment should really be made.
It is also the opinion of the co-chairs that many in the working group
are willing to deploy MAIL FROM checking as specified in
draft-mengwong-spf. Therefore, we ask for consideration of the
following proposal:
The ABNF in -protocol 3.4.1 is (mostly from a post by Wayne)
version = "spf2." ver-minor "/" ver-scope *( "," ver-scope )
ver-minor = 1*DIGIT
ver-scope = "pra" / "mailfrom" / name
name = alpha *( alpha / digit / "-" / "_" / "." )
And the following stipulations:
1) "mailfrom" checking will be defined in a new draft
2) multiple records are allowed
3) a scope (e.g. "pra") can only appear in one record of one type for
validity purposes
The question before the working group: assuming no technical errors
with the above, is there anybody who vehemently objects with this
proposal?
Checking RFC2821 MAIL FROM offers more value than did checking the PRA.
The PRA allows spoofing the RFC2822 From anyway. The network overhead
of this script is still a concern, especially as this draft allows
extensions outside the standards process. Merging two mechanism will
increase this overhead.
There is also an issue when the list of the MTA addresses is marked as
not comprehensive, which could cause this record to be exploited. This
is related to the forwarding issue, also not properly addressed either.
This is also where Jim Lyon expressed his opinion that anyone that
employs this non-comprehensive option, perhaps in an effort to allow
forwarding, will find themselves blacklisted.
Both of these fundamental and serious shortcomings can be addressed by
making a structural change.
The mailbox domain obtained from either MAIL FROM or the PRA assumes the
unverifiable integrity of the mail channel and thus are not suitable as
a basis for a reputation assessment. The number of DNS lookups required
to resolve the MTA to mailbox domain relationship can be confined to a
single DNS lookup, if a name for the MTA is first authenticated. This
resolves the network overhead issue and the problem of a
non-comprehensive MTA to mailbox domain relationship, as the
relationship and the MTA authentication become independent functions.
An authenticated MTA name is suitable for reputation assessment, and
removes the danger expressed by Jim Lyon.
Those that wish to employ a restrictive relationship with their MTA and
mailbox domains can easily do so without the need for the PRA
algorithm. For some situations, such as for financial transactions,
there may not be a desire to have messages forwarded or sent through a
list server, when the message is restricted by either or both the MAIL
FROM or From fields. There are also alternatives to SRS as well.
Beyond the IPR, there are pressing technical issues that can be
adequately rectified using this different two-step structural approach.
The MTA and mailbox domain should normally be treated as a nominal
relationship useful for coloring mail, where most of the compatibility
issues then vanish. By declaring the MTA name as the only identity
suitable for reputation assessment, this allows a lightweight scheme
that can help combat Trojan proxies, and protect users from being
falsely blacklisted. It also forms the basis for a simplistic means of
expressing an MTA to mailbox domain relationship.
-Doug