Re: consensus call on pra/mailfrom deployment and versioning/scope

[Douglas Otis <dotis@xxxxxxxxxxxxxx>]

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