Approval announcement
Draft of message to be sent after approval:
Announcement
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>
Subject: Document Action: 'SMTP Service Extension for Indicating
the Responsible Submitter of an E-mail Message' to Experimental
RFC
The IESG has approved the following documents:
- 'SMTP Service Extension for Indicating the Responsible Submitter of an
E-mail Message '
<draft-katz-submitter-02.txt> as an Experimental RFC
- 'Sender ID: Authenticating E-Mail '
<draft-lyon-senderid-core-02.txt> as an Experimental RFC
- 'Purported Responsible Address in E-Mail Messages '
<draft-lyon-senderid-pra-02.txt> as an Experimental RFC
These documents have been reviewed in the IETF but are not the products of
an IETF Working Group.
The IESG contact person is Ted Hardie.
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-katz-submitter-02.txt
Ballot Text
Technical Summary
Please see the IESG note.
Working Group Summary
This was originally part of the work of MARID, which was unable to come
to consensus on the appropriate set of scopes and facilities for DNS-based
email authentication. Because of that lack of consensus, this work is
targeted at Experimental, rather than standards track status. It is hoped
that additional deployment will help demonstrate which among the proposed
scopes and facilities is useful, and that those can later proceed to standards
track status.
Protocol Quality
This document was reviewed for the IESG by Ted Hardie and by the
DEA Directorate for the Applications Area Directors.
RFC Editor Note
Please subsitute RFC numbers for the draft document names in the IESG
Note.
IESG Note
"The following documents (draft-schlitt-spf-classic, draft-katz-submitter,
draft-lyon-senderid-core, draft-lyon-senderid-pra) are published simultaneously
as Experimental RFCs, although there is no general technical
consensus and efforts to reconcile the two approaches
have failed. As such these documents have not received full IETF review
and are published "AS-IS" to document the different approaches as
they were considered in the MARID working group.
The IESG takes no position about which approach is to be preferred and
cautions the reader that there are serious open issues for each approach
and concerns about using them in tandem. The IESG
believes that documenting the different approaches does less harm
than not documenting them.
Note that the Sender ID experiment may use DNS records which may have been
created for the current SPF experiment or earlier versions in this set of
experiments. Depending on the content of the record, this may mean that
Sender-ID heuristics would be applied incorrectly to a message. Depending on
the actions associated by the recipient with those heuristics, the message
may not be delivered or may be discarded on receipt.
Participants relying on Sender ID experiment DNS records are warned that
they may lose valid messages in this set of circumstances. Participants
publishing SPF experiment DNS records should consider the advice given in
section 3.4 of RFC XXXX (draft-lyon-senderid-core) and may wish to publish
both v=spf1 and spf2.0 records to avoid the conflict.
Participants in the Sender-ID experiment need to be aware
that the way Resent-* header fields are used will result in
failure to receive legitimate email when interacting with
standards-compliant systems (specifically automatic forwarders
which comply with the standards by not adding Resent-* headers,
and systems which comply with RFC 822 but have not yet implemented
RFC 2822 Resent-* semantics). It would be inappropriate to advance
Sender-ID on the standards track without resolving this
interoperability problem.
The community is invited to observe the success or failure of the
two approaches during the two years following publication, in
order that a community consensus can be reached in the future."