Skip to main content

Last Call Review of draft-kucherawy-authres-vbr-
review-kucherawy-authres-vbr-secdir-lc-mcgrew-2011-01-10-00

Request Review of draft-kucherawy-authres-vbr
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-01-18
Requested 2010-12-03
Authors Murray Kucherawy
I-D last updated 2011-01-10
Completed reviews Secdir Last Call review of -?? by David McGrew
Assignment Reviewer David McGrew
State Completed
Request Last Call review on draft-kucherawy-authres-vbr by Security Area Directorate Assigned
Completed 2011-01-10
review-kucherawy-authres-vbr-secdir-lc-mcgrew-2011-01-10-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 draft defines a way that a border mail gateway that assesses  


inbound email using VBR can use AUTHRES to pass along the results of  


its assessment to user agents or other entities such as mail filters.   


This is a sensible and useful thing to do, and the draft is  


straightforward and clear.  I have a few comments/questions.






Section 1.  It is not clear what problem is referred to in paragraph  


two.




Section 4.



What behavior should a mail filter have upon receiving the result  


codes defined in that section?   If the recommended behavior is  


defined elsewhere (presumably [VBR]), then it should be referenced in  


this section.






What behavior should a border mail gateway have upon receiving a VBR  


response?   For instance, under what conditions (if any) should a  


border mail gateway not forward an email on which VBR has returned  


"fail"?   I would guess that this draft expects gateways to always  


forward emails, and regards a mail filter as a logically separate  


entity.  I suggest clarifying this point.






Section 6.  The Security Considerations are short, but I agree with  


what they say (that the Security Considerations of [VBR] and [AUTHRES]  


should be read and understood).




regards,

David