On May 24, 2017 8:34:38 PM EDT, Dave Crocker <dcroc...@gmail.com> wrote: >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.
Nothing other than potentially ARC requires multiple AR header fields for different authentication types to be combined. These different verification operations (e.g. SPF, DKIM, and DMARC) are generally performed be different processes that add their own AR field. Requiring a single AR field will not make the system any less complicated, it only changes where you put the complexity. It probably makes sense to stick the sender with the complexity of dealing with multiple AR fields and combining then, but let's not pretend there's an overall simplification here. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
