Re: [secdir] SECDIR review of draft-kucherawy-authres-vbr

["Murray S. Kucherawy" <[e-mail]>]

Hi David.  Thanks for your comments.

> -----Original Message-----
> From: David McGrew [mailto:[e-mail]]
> Sent: Thursday, January 06, 2011 7:58 AM
> To: [e-mail]; [e-mail]; The IESG
> Subject: SECDIR review of draft-kucherawy-authres-vbr
> 
> [...]
> 
> Section 1.  It is not clear what problem is referred to in paragraph
> two.

The "problem" (though I agree it could be worded better) is that VBR came along after Authentication-Results was published, and so there's currently no standard way to convey VBR results in past a border gateway.

> 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.

Reactions to the information provided within an Authentication-Results field is entirely up to the consumer(s) of that information.  It's all a matter of local policy, and thus not specified in either document.  RFC5451 and its extensions only define the mechanism for transmitting that information inbound past border gateways.

> 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.

Again, it's a matter of local policy.  A gateway detecting a VBR, DKIM, SPF or any other failure is at liberty to reject or quarantine the message, or allow it to pass after adding those results via the mechanism of RFC5451 so that internal filters or MUAs can take whatever action they deem necessary without repeating those mechanisms themselves.

Since this is just an extension to the existing mechanism, I'm not sure it's useful to discuss it in this memo.  It would be better discussed in an RFC5451bis since it applies to the mechanism itself and not this extension.  That said, I'll add mention of this in an -03 draft if that's the preference.

-MSK