The document shepherd is Alan Ross. The responsible Area Director is Sean Turner.
This document specifies how S/MIME signing and encryption can be applied between a Message Submission Agent (MSA) and a Message Delivery Agent (MDA) or between 2 Message Transfer Agents (MTA).
This document is an updated version of Experimental RFC 3183. This specification re-uses the concepts described in RFC 3183 for: Domain Signatures; and Domain Encryption and Decryption. The changes from RFC 3183 that have been incorporated in this specification have been declared in Appendix A.
There are several existing implementations of this document, so it is suitable for being published on Standard Track.
2. Review and Consensus
This is an individual submission based on an existing RFC.
This document was reviewed by several S/MIME experts.
There is at least one implementation of the document and several older implementations that are doing similar things (for example <https://signing-milter.org/> and <http://www.postfix.org/addon.html#security-gateway>).
3. Intellectual Property
Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document.
4. Other Points
A question was raised about the need to register "smtp" and "submit" URI schemes.
The "smtp" URI is in wide use and can be provisionally registered.
For example see <http://camel.apache.org/mail.html> and <http://pic.dhe.ibm.com/infocenter/wsdatap/v3r8m1/index.jsp?topic=%2Fxs40%2Furlopensmtp.htm>
The IANA Considerations section might change if the "submit" and/or "smtp" URI scheme needs to be registered.
A question was raised about deprecating other signature types from RFC 3183 ("Review Signature" (Section 2.2 of RFC 3183) and "Additional Attributes Signature" (Section 2.3 of RFC 3183)). This was not the original intention of draft-melnikov-smime-msa-to-mda-02. An option may be to move them from RFC 3183 to draft-melnikov-smime-msa-to-mda-02.
In addition to this if these signature types or others are required for draft-melnikov-smime-msa-to-mda-02 it may make sense to obsolete RFC 3183.
The document needs an old boilerplate, as RFC 3183 used an old one. This can be fixed once IETF LC is over.