On Oct 3, 2007, at 2:59 PM, Hallam-Baker, Phillip wrote:
There is more we can do here but no more that we should feel
obliged to do - except for the fact that we are a standards
organization and should eat the dog food.
In particular, sign the messages with dkim and deploy spf.
Few problems should be caused by DKIM, although it might be difficult
to claim DKIM solves a particular problem affecting IETF mailing lists.
The same is not true for SPF. SPF is experimental, can be
problematic, and is very likely unsafe for use with DNS. SPF carries
suitable warnings indicating it may cause problems. SPF may
interfere with the delivery of forwarded messages. SPF might be used
in conjunction with Sender-ID. Suggested solutions for dealing with
Sender-ID requires yet another version of SPF be published. Use of
which might fall under:
http://www.microsoft.com/downloads/results.aspx?
pocId=&freetext=SenderID_License-Agreement.pdf&DisplayLang=en
Possible application of Sender-ID will cause IETF lists to break once
SPF is published. The purported use of SPF for curtailing forged
DSNs requires policy settings which then create new problems. When
desired, names rather than address lists should be used to register
an email path. A name path approach avoids the dangerous DNS
transactional issues. Rather than relying upon unscalable SPF
address lists, instead an extension might be applied to DKIM. The
DKIM extension could offer a means to prevent DSNs from being dropped
when Mail From domains differ.
http://www1.tools.ietf.org/wg/dkim/draft-otis-dkim-tpa-ssp-01.txt
-Doug
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf