Hi,

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

I’ve seen a lot of discussion about this draft, so I’ll enter my reasons of why I think that the document is (again) ready.

First, looking at this from an operational, “on the wire” perspective, the Expires header field will pose no additional security concerns over those defined in RFC 5322. I usually like to recommend to the authors that they have a statement in the Security Considerations section referencing the Security Considerations sections of at least a preceding RFC, but RFC 5322 contains a very minimal Security Considerations section. I don’t think anyone implementing the Expires header field would benefit from reading that.

While I don’t keep up with discussions regarding email in the IETF, I surmised two things from the minimal Security Considerations section of RFC 5322: 
-	If the email community had consensus about the operational security of header fields, they would have gotten together and written an RFC about it by now.
-	The email community has been operating email systems for a long time and have figured out how to deal with any “on the wire” operational concerns of header fields.
From that, I don’t think that the authors of this draft need to add anything more to the Security Considerations section than what they have. Making them do so would require them to take on the work, and obtain consensus, of what should have been done in creating RFC 5322. 

I did see an email go across the list that said something about the folding white space in this header field. I don’t think that the authors of this draft need to specifically address that. The reference to the ABNF of RFC 5322 was sufficient and processing folding white space has been done for a long time. There’s nothing in this field that would change that long-standing practice.

Second, I feel certain that the administrative policies of individuals and companies for email systems will not be changed by receiving emails that contain an Expires header field. I believe that all systems receiving an email from outside their domains have, and will continue to have, a healthy distrust of all received header fields. As others have said in the thread of this discussion, at best the received header fields have been considered to be “advisory”. The Expires header field doesn’t bring in anything new. Other headers set by the originators, like orig-date, are usually not trusted if they come from outside the domain, and I expect that they are not fully trusted even if the email originates and stays within a domain. 

Along those lines, I saw that there is an implementation where the Expires header field is being used solely to provide some additional notification to recipients. That seems appropriate. I’ve also seen enterprises enforce retention policies to the extent that received emails are deleted at a certain time after receipt, whether they’ve been read or not. I don’t see that the Expires header is going to change those policies. 

From that, I feel that what the authors have written in the draft is sufficient. 

Happy Holidays and Best Regards,
Chris