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.


Section 7.1.  Forged Header Fields

In addition to a recommended solution, this section has list a potential 
alternative solutions which the document then states that it is not appropriate 
for this document to specify which mechanism should be used.

Since an implementer is not expected to do anything with this information, it 
might be more appropriate for this to be moved to an appendix at the end of 
document.



Section 7.2.  Misleading Results, First paragraph, last sentence

   "In particular, this issue is not resolved by forged header field removal 
   discussed above."

which seems to be in conflict with the following statement from section 5:

   "For simplicity and maximum security, a border MTA could remove all
   instances of this header field on mail crossing into its trust
   boundary."
   

   
Section 7.2.  Misleading Results, Second paragraph

   "Hence, MUAs and downstream filters must take some care with use of
   this header even after possibly malicious headers are scrubbed."

How do you expect an MUA or downstream filter to act on "take some care"?
Can you elaborate on that?



7.3.  Header Field Position

This section explains that headers fields are *not* guaranteed to be in a 
specific order. The section then states that "there will be *some* 
indication..."

Since the order is not guaranteed, what do you expect an implementer to take 
away from this?



7.8.  Intentionally Malformed Header Fields

This is a general issue with any header. Is there anything specific to this 
header that an implementer should pay attention to?

Regards,
 Rifaat