[opendmarc-dev] draft: patch to implement an override mechanism for MLMs

[Scott Kitterman]

On Thursday, May 26, 2016 03:52:02 PM Juri Haberland wrote:
> Scott Kitterman wrote:
> > On Thursday, May 26, 2016 12:20:22 PM Juri Haberland wrote:
> >> The values defined in section 3.2.2 are:
> >> "delivered" / "spam" / "policy" / "reject" / "other"
> >> 
> >> Shall we map like this:
> >> NONE      -> delivered
> >> QURANTINE -> policy
> >> REJECT    -> reject
> >> 
> >> Or do we use "adisposition" verbatim?
> >> 
> >> Unfortunately RFC 6591 is not updated to support DMARC...
> > 
> > RFC 6591 doesn't need updating directly as the DMARC RFC itself contains
> > the new information needed to generate AR header fields for DMARC.
> > 
> > https://tools.ietf.org/html/rfc7489#page-42
> 
> Ah, thanks, I'll look into this.
> 
> > Since this is a failure report, why isn't the Delivery-Result always
> > reject?
> > 
> > Delivery-Result is for the delivery result, not the result of DMARC
> > processing.  The result of DMARC goes in the AR field.
> 
> Are we supposed to only send failure reports if we do not deliver the mail?
> I thought for DMARC, a failure report is always sent if authentification
> fails, regardless of the delivery result (at least section 7.3 of RFC 7489
> seems to state this).

You're right, sorry.  The challenge is that the DMARC processing element 
generally won't know the actual message disposition (it might be rejected or 
quarantined at some later stage of processing), so I'm not sure how you fill 
that out accurately at the DMARC stage.

Scott K