On 4/9/15 6:24 AM, Anne Bennett wrote: Hector Santos <[email protected]> writes: >> A database is still needed of which domains will have an >> outbound mail stream with two signatures. Some how the list domains >> will still need to register with the Yahoos and tell the Yahoos, >> "Please send us two signatures authorizing out list domain." I >> would like to call this a "registration" problem because thats seems >> to be the area of disagreement as a real problem. > I have to agree; if this is the case, to me, it is a > show-stopper. The genius of the DKIM and SPF and DMARC > approaches is that they are DNS-based, and thus completely > decentralized. The idea that lists would have to register with > the e-mail providers of all of their contributors, or that I > as a (very small!) e-mail provider would have to figure out > what is and isn't a list, doesn't scale. > > I have not yet taken the time to fully understand the "weak and > strong signatures" idea, but if I may be forgiven for commenting > anyway: could the above problem be solved by having "original" > signers always supply various forms of signature (without > needing to figure out if the receiver address is a list), and > having "intermediate" signers (such as mailing lists) add more > signatures as described in the draft? A message that arrives > with only the "original" signatures would be checked against > the strong one, and a message that arrives with "additional" > signatures would be checked as per the draft. > > Of course, if the idea of specifically setting up a third-party > trust is crucial to the proposal, then my suggestion is useless, > and the "registration problem" is not solvable. Dear Anne and Hector,
Tag/conditional DKIM expects ESP now offloading support issues onto various third-parties to instead apply extremely limited signatures against all outbound messages while guessing their user's recipient's signing domain in hopes this new signature might satisfy DMARC's From alignment requirement as seen by receivers implementing DMARC. This still ignores Sender header fields claiming to have actually sent the message. ESPs would have less overhead and would handle smaller message sizes by simply ensuring clients see Sender header fields when used as a basis for acceptance. In any case DMARC should be adjusted to assert support for any new alignment or signature mode of operation. Outlook already provides a means to expose the Sender and can be done with rather simple MUA reconfiguration to select displayed headers. TPA-Label in comparison represents both a database established by the DMARC domain to eliminate any additional message overhead while not imposing changes on third-party services. ATPS remains flawed since it also required special DKIM signatures by third-party services to somehow also determine possible DNS label encoding variants employed by a user's domain. In essence, ATPS imposes a database support requirement onto those likely offering a free third-party service while also expecting similar support from ESPs. Tag/conditional DKIM is not really that much better, since it still depends on support from ESP's and fails to offer a better fallback mode when these ESPs fail to act. Regards, Douglas Otis _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
