Re: [EAI] Re: SPF and DKIM

[John C Klensin <klensin at jck.com>]

--On Thursday, 08 March, 2007 16:26 +0800 abel
<abelyang at twnic.net.tw> wrote:

> Thanks for Kari comments,
> These remind us to pay attention to more details in SPF and
> DKIM

Sorry, but let me suggest a different view, one that I think is
important if anyone actually wants to finish this stage of the
work.  Please remember that we are many, many months behind our
original schedule which was to have Experimental documents
approved and in the publication queue before the end of last
calendar year.

The charter calls for us to worry about compatibility issues
with the base email infrastructure.   We originally thought
about that in terms of what is covered by 2821 and 2822.  It has
been expanded to include DSNs, POP, IMAP, and consideration of
mailing lists (the latter are covered in 2821 although very
superficially).  

It does not specify compatibility with SPF, or DKIM, or any of
several dozen activities and proposals for dealing with email or
using it in unusual ways.

The WG signed off on "framework".  It discusses "systems or
mechanisms that are dependent on digital signatures or similar
integrity protection for mail headers" and mentions the need for
DKIM and this work to _eventually_ consider each other" but
explicitly indicates that this work will not "address or solve
the issues" in Section 9 on Security Considerations.  There is
also a discussion of signed body parts and downgrading in
Section 6.4 on "Encoded words, signed messages and downgrading"
that concludes 
"...downgrading must be performed with extreme care if at all."

I believe that, if we make smooth working of DKIM, SPF, etc.,
especially in systems that have not been upgraded to work with
UTF8SMTP mail, a requirement for an acceptable downgrading
solution that we will never find an acceptable downgrading
solution.   

We actually know how to make systems like that work today
(assuming they are upgraded to recognize our addresses) and that
is to reject or bounce any message that contains their headers
and would otherwise need to be downgraded.  My instinct is that
we are better off ignoring them, downgrading, and letting the
final delivery system sort things out.   Perhaps it would be
wise to remove the SPF or DKIM headers entirely on downgrade
instead, but advice on that option should come from those WGs
--we should not be guessing here about what would cause the
least damage in their various scenarios.

But the bottom line, IMO, is that, if we are sincerely
interested in getting this work done we ignore anything that is
not in the Charter or critical to completing chartered work, at
least until we get the Experimental documents finished.  I
believe that anyone considering bringing these issues up again
on the mailing list should first ask him or herself whether the
probable outcome of delaying, or even killing, this work is
worth it... and whether he or she wants to take responsibility
for that.

     john


_______________________________________________
IMA mailing list
IMA at ietf.org
https://www1.ietf.org/mailman/listinfo/ima