ares_parse() fails on outlook.com/alum.mit.edu added header

[mdomsch]

Similar to trusteddomainproject/OpenDKIM#73

alum.mit.edu is an email forwarding service operated by outlook.com. Mail being forwarded through this service gets Authentication-Results headers added by the service which are unparsable by openarc, which leave "can't parse Authentication-Results; ignoring;" messages in maillog.

Two examples:
Authentication-Results: spf=pass (sender IP is 167.89.0.165)#12 smtp.mailfrom=e.slashjobalerts.com; alum.mit.edu; dkim=pass (signature was#012 verified) header.d=slashjobalerts.com;alum.mit.edu; dmarc=pass action=none#012 header.from=slashjobalerts.com;compauth=pass reason=100

Authentication-Results: spf=pass (sender IP is 167.89.106.17)#12 smtp.mailfrom=em.alum.mit.edu; alum.mit.edu; dkim=pass (signature was#012 verified) header.d=alum.mit.edu;alum.mit.edu; dmarc=bestguesspass action=none#012 header.from=mit.edu;compauth=pass reason=109

Full headers available upon request.

[kurta]

Those Authentication-Results examples that you cited are invalid per RFC8601. I'm not sure why openarc would be trying to parse them at all...?

…

--Kurt

On Sat, May 16, 2020 at 7:08 AM Matt Domsch ***@***.***> wrote: Similar to trusteddomainproject/OpenDKIM#73 <trusteddomainproject/OpenDKIM#73> alum.mit.edu is an email forwarding service operated by outlook.com. Mail being forwarded through this service gets Authentication-Results headers added by the service which are unparsable by openarc, which leave "can't parse Authentication-Results; ignoring;" messages in maillog. Two examples: Authentication-Results: spf=pass (sender IP is 167.89.0.165)#12 <#12> smtp.mailfrom= e.slashjobalerts.com; alum.mit.edu; dkim=pass (signature was#012 verified) header.d=slashjobalerts.com;alum.mit.edu; dmarc=pass action=none#012 header.from=slashjobalerts.com;compauth=pass reason=100 Authentication-Results: spf=pass (sender IP is 167.89.106.17)#12 <#12> smtp.mailfrom= em.alum.mit.edu; alum.mit.edu; dkim=pass (signature was#012 verified) header.d=alum.mit.edu;alum.mit.edu; dmarc=bestguesspass action=none#012 header.from=mit.edu;compauth=pass reason=109 Full headers available upon request. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#131>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGU3SK6UAT25KUDJ7V6HKDRR2M5LANCNFSM4NC55XXQ> .

[mdomsch]

Per the admin team for alum.mit.edu, they are using Office365 for handling mail, which also forwards to my personal domain address. Therefore it's Office365 that's adding this malformed header. Furthermore, it's added upon receipt into Office365, not during the forwarding phase, as it's present in the copy left in Office365 as well.

[kurta]

I'm not sure we have any MSFT folks following the bugs for OpenARC - you might try arc-discuss@dmarc.org instead.

…

--Kurt

On Mon, Jun 8, 2020 at 12:44 PM Matt Domsch ***@***.***> wrote: Per the admin team for alum.mit.edu, they are using Office365 for handling mail, which also forwards to my personal domain address. Therefore it's Office365 that's adding this malformed header. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#131 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGU3SKQIUMCCGR4HBBBVGTRVU5TNANCNFSM4NC55XXQ> .