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

[David McGrew <[e-mail]>]

Hi Murray,

On Jan 6, 2011, at 10:36 AM, Murray S. Kucherawy wrote:

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

I'm surprised that it's not discussed in RFC5451, but given that fact  
I certainly agree that RFC5451bis would be the right place for it.

David

>
> -MSK
>