Skip to main content

Last Call Review of draft-melnikov-smtp-priority-tunneling-
review-melnikov-smtp-priority-tunneling-secdir-lc-emery-2012-07-19-00

Request Review of draft-melnikov-smtp-priority-tunneling
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-07-17
Requested 2012-06-19
Authors Alexey Melnikov , Ken Carlberg
I-D last updated 2012-07-19
Completed reviews Genart Last Call review of -?? by Martin Thomson
Secdir Last Call review of -?? by Shawn M Emery
Assignment Reviewer Shawn M Emery
State Completed
Request Last Call review on draft-melnikov-smtp-priority-tunneling by Security Area Directorate Assigned
Result Ready w/nits
Completed 2012-07-19
review-melnikov-smtp-priority-tunneling-secdir-lc-emery-2012-07-19-00


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.





        This experimental draft describes a SMTP tunneling method to
        support priority message values for Mail Transfer Agents (MTA)
        that don't understand the MT-PRIORITY 




SMTP extension.





        The security consideration section does exist and is quite
        detailed in listing the various attack scenarios and mitigating
        against these attacks.  It goes on to provide exceptions of when
        MT-Priority header values are not required to be stripped. 
        These have consequences such as breaking DKIM signatures,
        assuming subsequent MTAs are compliant with the new tunneling,
        or rejecting the messaging.  The document may clarify on when it
        is acceptable to break DKIM signatures and/or describe the
        environment.  On the other hand, if the MSA/MTA decides to alter
        the message and needs to resign the message then is there any
        ambiguity of what the message/fields would be when resigned?





        General comments:





        Thanks for providing the before and after examples as this was
        helpful in my understanding of the protocol.





        Editorial comments:





        s/Example of such/Examples of such/





        Shawn.


        --