On Monday, November 05, 2018 01:06:13 PM Brandon Long wrote: > On Fri, Nov 2, 2018 at 2:13 AM Kurt Andersen (b) <[email protected]> wrote: > > On Fri, Nov 2, 2018, 18:09 John R Levine <[email protected] wrote: > >> On Fri, 2 Nov 2018, Kurt Andersen (b) wrote: > >> >> I mean ARC as it's implemented now, not in our multi-signing draft. > >> > > >> > It seems like a poor implementation choice to be enforcing something > >> > >> which > >> > >> > is not part of the spec :-), especially when there are parenthetical > >> > comments and references to things like ARC-MULTI to warn you against > >> > leaping to foot-shooting enforcement choices. > >> > >> I see it also says: > >> Valid ARC Sets MUST have exactly one instance of each ARC header > >> field (AAR, AMS, and AS) for a given instance value and signing > >> algorithm. > >> > >> I'm reasonably sure that doesn't match a lot of running code. I'm > >> particularly thinking of gmail here. > > > > That should be easy to test but not with a tiny keyboard as I board my > > flight from ICN --> BKK. > > If it does work, I'd be a surprised. Most likely, it'll fail validation > prior to full parsing (we extract the i= first, and only fully parse all > the k=v pairs later). > > Also, does that mean you have to use the same algorithm in both the AMS and > AS for a given instance? And how does that correspond to an AAR which > doesn't have an algorithm... and how does that work with the AS signing > previous headers, does it only sign the ones with matching algorithm? > > I'd be a bit surprised if all of those caveats are correctly matched in the > original arc spec.
OK. Thanks for the implementation feedback. Do you have any suggestions for a change that would make an AMS/AS be silently ignored? My thought had been one AMS/AS pair per algorithm (treated effectively as one AMS/AS) and a single AAR. I guess it won't be that easy. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
