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

Juri Haberland juri at sapienti-sat.org
Sat May 28 13:43:23 PDT 2016


On 25.05.2016 21:26, Juri Haberland wrote:
> On 25.05.2016 21:56, A. Schulze wrote:

>> It enable us to theoretical add the Delivery-Result to failure reports.
>> 
>> These reports use field defined by https://tools.ietf.org/html/rfc6591#section-3.1
>> 
>> Unfortunately the code to calculate adisposition ( openmarc.c, ~line 3100 )
>> come after the code generating the rfc6591 fields ( ~ line 2900 )
>> 
>> would it be possible to calculate adisposition earlier?
>> then a Delivery-Result defined by https://tools.ietf.org/html/rfc6591#section-3.2.2 could be added.
> 
> Unfortunately not, as it depends on 'result', which is determined right
> before it. But maybe we can delay the sending of the failure report until
> we calculated the adisposition - I'll have a look at it tomorrow.

Ok, here is a patch that moves the sending of the failure report after the
calulation of the disposition.
I added the mandatory Identity-Alignment header and the optional
Delivery-Result and Source-Port headers to the feedback report.

And while I was at it, I changed the subject of the failure report to not
report the subject of the failed email, but have a more generic contents:
"DMARC failure report for <domain>" - see the second patch.

Have fun,
  Juri

-------------- next part --------------
A non-text attachment was scrubbed...
Name: moreHeadersFailureReport.patch
Type: text/x-diff
Size: 9578 bytes
Desc: not available
URL: <http://www.trusteddomain.org/pipermail/opendmarc-dev/attachments/20160528/c8e954f9/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: changeSubjectFailureReport.patch
Type: text/x-diff
Size: 896 bytes
Desc: not available
URL: <http://www.trusteddomain.org/pipermail/opendmarc-dev/attachments/20160528/c8e954f9/attachment-0001.patch>


More information about the opendmarc-dev mailing list