On Thu, Jun 1, 2017 at 10:30 PM, Murray S. Kucherawy <[email protected]> wrote: > > I'm taking the opposite approach: There might be some utility later to > them being different, so why proscribe it just because we don't see > anything to gain when the protocol is nascent? I'd rather lock things down > later, or lock them down as a local policy matter, than do MUST NOT in the > protocol document absent a compelling reason. >
I'm on the same page. Furthermore (and I say this mostly ignorant of IETF precedent here), I think it's beneficial for the AS and AMS to remain as close to normal DKIM-Signatures as possible, and additional constrains or variance in acceptable tags/values or semantical constraints across them be kept to a bare minimum. I think everything else really belongs as local policy for a receiver, unless there is specific and clear benefit to the protocol to impose the restriction. I don't think requiring d= to match between AS and AMS clears this bar for the protocol, but it absolutely makes sense for a receiver to factor into delivery decisions. And then, as MSK just said, if a good reason for doing this arises later, it's possible. And if a malicious use arises, then receivers are still in their right to shut those chains down and might already be doing so by default. Seth -- [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
