Does the group have any further thoughts here? I'm happy to suggest language for Gene's suggestion if there are no further comments.
On Tue, May 9, 2017 at 4:02 PM, Gene Shuman <[email protected]> wrote: > I definitely can't imagine any sensible case in which the d= tags should > be different. I do think the tag should still be specified in both the AS > & AMS though. While not strictly necessary technically, it does make the > language in the spec & implementation details a bit cleaner. So I would > suggest simply adding a line/section in the chain validation section of the > draft or somewhere else that says cv=fail(or invalid?) if the d= tags > aren't identical. I think this is an entirely reasonable restriction. > > =Gene > > On Thu, May 4, 2017 at 3:44 PM, Brandon Long <[email protected]> wrote: > >> When thinking about how to extract information from an arc chain, I was >> wondering at the "owner" of a section of the chain. >> >> Theoretically, that's the ADMD. A single hop, however, has three >> separate domain ownerships, the srv_id from the AAR, and the d= field from >> the AS and AMS. >> >> Our current implementation uses google.com for the d= field, and we have >> three different srv_id's for different pools that serve different >> purposes. That said, the srv_id has no "validation" except for by the key >> signature, so d= seems like a stronger "owner". >> >> Except, the AMS and AS can have separate selectors and domains. I'm not >> sure if that's useful or desirable. I'm tempted to only consider a chain >> valid if the domains are the same, and I guess not care if the selectors >> are. >> >> Should we require them to be the same? If we do, should they only be >> specified once? >> >> For changing algorithms, I guess s would be different, along with a, >> though I would think you would need a separate set of headers for the hop >> for each a in transition... >> >> So: >> Should we require d= to be the same? Should we specify it only once? If >> not, why not? >> >> Brandon >> >> _______________________________________________ >> dmarc mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmarc >> >> > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc > > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols [email protected] +1-415-894-2724 <415-894-2724>
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
