On Thursday, April 30, 2015 10:00:46 AM Kurt Andersen wrote: > On Thu, Apr 30, 2015 at 9:06 AM, Scott Kitterman <[email protected]> > > wrote: > > It might be useful though to have some opt-in mechanism for DMARC senders > > to > > get an additional query for verification purposes. > > > > Concept: > > > > Participating senders add a new optional tag to their DMARC record, > > something > > like yaimfs=y and a new field in the header that is something like: > > > > yaimfs-id: localpart@domain > > > > Domain must be aligned with the From domain > > > > For mail that passes DMARC, no changes are made. If a message fails DMARC > > checks and both the DMARC record (which is already in the local cache) has > > yaimfs=y and the message has yaimfs-id is possible, then the receiver > > sends a > > DNS query to message-id.yamfsidlocalpart._dmarc.domain. The sender then > > replies pass/fail/error. > > > > I suggest message ID be included since it's supposed to be globally unique > > to > > reduce the risk of collision. > > > > This idea effectively would create a new authentication protocol based on > > direct query/feedback and extend DMARC to use it. It would be totally > > opt-in. > > Interesting idea - essentially it would allow senders to provide an > independent authorization channel for messages. What worries me, is why a > sender would sanction a message that presumably has been sufficiently > altered as to fail DKIM validation without knowing something about the > content as received. > > It seems somewhat like saying that if you get a check (the old-fashioned > paper kind), that if you call me and tell me what color the paper is, then > you can cash the check (presuming that the color is correct). I would not, > personally, be granting any such approvals.
I think it's a bit more than that. It's more like "Give me the serial number" "Oh, I just wrote a check with the number 30 seconds ago, OK" I agree it's not a 100% secure solution since there's a replay risk, but the risk is less than with the fs= proposal. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
