Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers

I can see there being an issue here if the inbound smtp server that would
normally remove existing AuthRes headers for its admd before adding its own
uses a different algorithm than any downstream systems used.

In particular, theoretically the inbound smtp server may use software from
a different source than the spam system or the clients which consume this
header.

In practice, I don't know how common it is for clients to consume this
header.

Also, any mis-handling should be treated as a bug.

The system should remove the quotes when comparing, and should also do any
decoding to get the admds into the same format.

Brandon

On Fri, Apr 3, 2020 at 9:10 AM Damian Lukowski <rfc@arcsin.de> wrote:

> RFC8601 sec 5 states:
>
> any MTA conforming to
> this specification MUST delete any discovered instance of this header
> field that claims, by virtue of its authentication service
> identifier, to have been added within its trust boundary but that did
> not come directly from another trusted MTA.
>
> In my opinion, a header that does not conform to the specified
> authres-header-field in the RFC, is not an Authentication-Results header,
> has no authentication service identifier, and as such cannot claim anything
> in the context of the RFC. So suppose there is a mail system with an
> UTF-8-non-ASCII authserv-id. When creating its own A-R headers, it puts the
> authserv-id into quotes, because it cannot use it without them, as
> discussed in the separate thread.
>
> What should the system do with an A-R header of an inbound message that
> incorporates the system's authentication service identifier without using
> quotes, but that otherwise would be syntactically correct?
>
> Again in my opinion, the system needs to keep the header, but what is the
> RFCs intention?
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>