Reviewer: Rifaat Shekh-Yusef Review result: Has Issues 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
