This isn't fully fleshed out yet, so no I-D, but I've been running short of time, so I decided it would be better to at least get something written down.
Historical SPF discussion: One of the use cases presented for macros in SPF records was to enable senders to dynamically assess information communicated via a DNS query from a receiver. This is described in RFC 7208 Appendix D Section 1 (D.1). I have seen SPF records in the wild that do variants of this, but they are rare. This was seen a one potential solution to the SPF "forwarding problem". Analogy to DMARC: That got me thinking about the possibility of something similar for DMARC. It can't be the same, since one of the indirect mail flow cases we have to address is mailing lists and they typically use their own mail from, so any needed mail from encoding would be lost. It might be useful though to have some opt-in mechanism for DMARC senders to get an additional query for verification purposes. I recall some earlier discussion about encoding information in From local part, but if for no other reason, automatic addition of new email addresses to contacts by some MUAs makes that highly problematic. Fortunately, we don't have to be tied to either mail from or from. We can add a new header field and since we aren't asking the user to interpret is, it need not and should not be displayed. For the purposes of this mail, I'm calling it yaimfs-id. If the concept has legs, we can bike shed the name later. 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. Functional assessment: This idea has similar security properties to the proposal for adding an additional signature with fs=. Since some of the indirect mail flow use cases are one to many transitions, a sender would have to give multple positive responses per message to enable mailing list (for example) use. The security advantage is has over the fs= proposal is that the number of such approvals is in control of the sender. For fs=, signature validity time is the only available replay constraint. For this proposal the sender can determine a policy on maximum number of uses or time limit and implement it unilaterally. This does not require mediators to do anything. This does not require senders or receivers to know who are 'good' mediators. It does require senders to maintain state on the yamfs-id tokens and pass or fail messages. It does create traffic for any DMARC fail message. It's opt-in and doesn't have a significant impact on non-implementers. Utility assessment: This does not require anything that's unique to a large provider. This should scale reasonably well up or down (I think there's enough space in message ID plus yamfs-id to cover large provider needs, but it would be nice to get an assessment from someone at a large provider). It requires changes from the originators and receivers, but not mediators. I think this is useful to consider since we don't have a large/small, no mediator change option on the table at the moment. Thoughts/questions (I'm sure I haven't described this well)? Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
