Re: Sendmail white paper

wayne wrote:

> I read your recent white paper on email authentication.  In general, I
> liked it and I think it will be a useful guide to many.  I do,
> however, have a number of questions about the paper.  Would you be
> able to answer the questions, or pass them on to whoever authored the
> paper?
Sure.  I was the primary author along with input from the rest of our 
technical staff.
> * Could you proved some more detailed results of the "extensive
>   testing under real-world deployment scenarios"?  That would be
>   extremely useful to many people, even if it is in a very rough
>   format. 
Analysis of testing data/requirements as gathered by some of our large 
ISP customers, Enterprises, and a number of key technical partner sites. 
 Comparing the authentication/filtering results between SPF/SID/DK 
protected mail.  Discussions with infrastructure folks about their needs 
and likely deployment paths.  Mostly this information was used to 
develop likely course of evolution for authentication on the net, which 
this document reflects.
> * SPF validates the Return-Path: header, which *is* usually available
>   to the end-user, although not usually visible.  The Resent-* headers 
>   that Sender ID validates are *not* any more user-visible than the
>   Return-Path: header.
>
>   Why does the paper claim that the Return-Path: header is not visible
>   while the Resent-* headers are?
Return-Path: is a reflection of the RFC2821 MAIL FROM address, and is 
entirely at the discretion of the MDA as to whether or not to insert it. 
 Resent-* are RFC2822 headers which always get stored for every 
message.  For example, looking at my two primary mailboxes (one 
personal, one work, both running very common standards-based software), 
one records/exposes Return-Path: and another doesn't (ironically in 
reverse order from what I expected).
> * What incompatibliites to end-to-end cryptographic authentication
>   systems does SRS cause?  I know of none.
The reference is specifically with regards to BATV compatibility.  While 
it may be possible to make the two formats compatible/encapsulatable 
within each other, the conversations on this list lately have shown that 
not even this group can agree on how to make SES and SRS compatible, or 
even what is the canonical SRS spec at this time.  Without more solid 
specs and without knowing possible incompatibilities between these 
as-yet-unsolidified specs I can't make a recommendation that people 
deploy such schemes at this time.
> * Why is only mention DK, but not IIM or SES?
There is currently very little deployment of IIM or SES, and little 
indication that will grow soon.  There are already a number of large 
sites signing/checking DK, so there is real sender benefit to implement. 
 I still have hopes that IIM and DK will centralize on a standard spec, 
so I didn't want to confuse the issue with two (comparably expensive) 
crypto approaches yet without major benefits to doing so.
> * Why do you recommend mailing lists modify the MAIL FROM addresses to
>   make sure they are properly authrorized, but you do not recommend
>   that mail forwarders do the same?  Any modification to the MAIL FROM
>   address by mailing lists cause the same problems as for forwarders,
>   so the recommendations should be the same.
Mailing lists should be taking responsibility for the messages that they 
send out, and this shift in accountability should be recorded in the 
MAIL FROM and Sender: headers.  Forwarders are simple redirectors, and 
should do as little to messages passing through them as possible.
Cheers - Rand