On 5/24/2017 5:27 PM, John R Levine wrote:
Seems reasonable, give or take a word or two to make it clear we're just
talking about the ones for the current hop.
There should only be the ones from the current hop if the admd is
stripping
previously existing ones prior to adding any new ones per the authres
rfc.
I meant not to use a-r with different admds. Should be obvious, but you
never know.
I'd expect a spec to declare that there must be only one A-R header
field, and that it is applied within the current, integrated mail
processing environment. (I'd say within the current ADMD, but I think
there are valid scenarios where that characterization doesn't quite fit,
although the language can probably be contorted to make that
more-limited language sufficient.)
Unless there is a very compelling need for multiple A-R header fields --
and I don't think I've seen that asserted -- then the simplest thing is
to declare them illegal and any occurrence of them as invalidating the
authentication mechanism(s).
Really. The goal here needs to be to make this a simple as possible.
It's the only way to get large scale support that interoperates well.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
