ATPS requires signatures by multiple parties. What I'm proposing only requires a 2nd signature from the originating domain. This significantly simplifies the requirements for the specification as well as ongoing operational requirements. MLMS or other known intermediaries would have to do nothing or very little to make sure they don't break the 2nd signature.
As to why there is likely to be adoption now vs ATPS, ATPS was published in 2012 when there was very little adoption of DMARC, specifically by domains with end users likely to send mail through intermediaries. The MLM problem became significantly greater when domains such as AOL and Yahoo! deployed DMARC with p=reject wreaking havoc among parts of their user base as well as with MLMs. I would suggest that the approach I suggest is simpler to implement and requires less effort than ATPS or Dave's proposed changes to DMARC. Michael Hammer On Thu, Jun 25, 2020 at 10:16 PM Scott Kitterman <[email protected]> wrote: > On Thursday, June 25, 2020 8:05:43 PM EDT Dotzero wrote: > > After reading Dave Crocker's proposal, which I consider fundamentally > > broken, I've given some thought to the issues. > > > > 1) Many MLM's do not want to change their current practices yet suffer > > consequences from DMARC implementations at their subscribers domains. > > > > 2) There is a mismatch between the granularity (domain) which DMARC > > operates at and individual subscriptions to mailing lists. > > > > 3) It would be useful for domains with individual users to show > > authorization for messages by individuals that are likely to flow through > > intermediaries such as MLMs. > > > > Without formulating all the details, what I propose for the groups > > consideration is a new field which I will call "Intermediary" as a > stalking > > horse. This field would be DKIM signed separately from the current DKIM > > signing. This would ensure more robust survivability in passing through > the > > intermediary. There would likely need to be some additional elements > signed > > to mitigate against replay attacks using the second signature. > > > > Variations on this approach might include: > > > > A) Generic signing of "Intermediary". This seems as risky or perhaps more > > risky to me as signing using the "*l*=" tag. Presumably generic signing > > should not be used in conjunction with reject. > > > > B) Specifying the specific Intermediary in the Intermediary Field. This > > would indicate that the users domain recognizes that the user uses the > > intermediary and by policy exempts this use even though it breaks both > DKIM > > and SPF validation. The receiving domain would need to recognize some > > potential risk of malicious modifications or additions to the message. > > > > Benefits of this proposal include: > > > > 1) This is an addition to DMARC that does not change the underlying > > functionality of DMARC for those domains not interested in participating > in > > this extended functionality. > > > > 2) It resolves the mismatch in granularity between the domain level and > the > > user level as far as authentication/authorization. > > > > 3) It would require no effort on the part of known intermediaries other > > than not breaking the second signature. > > > > Issues: > > > > 1) It increases administrative complexity for the originating domain in > > that it requires the domain to either track user:intermediary > relationships > > or enable users to self approve such relationships ad hoc. > > > > 2) A more detailed specification would need to be fleshed out to > determine > > whether this approach would survive likely modifications by known > > intermediaries. > > > > 3) This does not address the issue of modifications by intermediaries not > > identified in advance and authorized. > > > > Feel free to start pulling this apart. This is a proposal for an > approach, > > not a complete proposed solution. > > > > Michael Hammer > > I think a good place to start is ATPS (RFC 6541). At least at this level > of > detail it sounds similar to me. I think it would be useful to know what > you > would do differently or alternately why you think it might catch on now > when it > didn't when it was developed. > > Scott K > > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
