Hi, > > Sorry but this is another WKBI. Off the top of my head some of the > reasons it doesn't work are:
Thank you for your comments, John! > > * There is no way to tell who forwarded a message, in particular you > cannot expect the recipient to be in a To: or Cc: header. You could > invent a Forwarded-By: header, but of course bad guys add fake > headers, so you'd have to track who's supposed to be forwarding what > and you'd end up with a very complex and fragile forwarder whitelist. The Received: header actually does most of this -- it contains the EHLO and MAIL FROM information of previous envelopes. It does not always contain the RCPT TO (max one ends up in optional "for"). Given that SPF approves of a sender [because it is configured as a reliable provider], one might trust the topmost Received: header to have been delivered by that reliable party. That assures us of the sender one step down, and after a few steps we've left the entrance points to our own realm [over which we have control, so not all bad] and then... the customary SPF magic can take place, based on the envelope data available there. The last IP address logged comes from the last trusted Received: header and that's the one that did the crossover to our realm of control. The devil will be in the details, I realise that. But a lot of the info you mentioned actually is there already, and is even obliged. Things like one domain leaving multiple Received: headers, and complex MTA infra that doesn't share input and output addresses. > > * There is a kludge called SRS that embeds the original bounce address > in the forwarder's bounce address, but it doesn't help. I agree. And unpacking the address from SRS doesn't sound like a dream of interoperability either. One might actually rely on the From: header more than SPF does now; unlike To: and Cc: this is a reliable address source [except for bounces, which will normally transport directly and SPF-compliant]. The From: address can then be used at the end of the unraveled envelope history from Received: headers. Whee, it almost sounds like DMARC is teaching SPF how it's done :) > > * Mailing lists invariably replace the incoming bounce address with > their own bounce address so they can handle the bounces, which among > other things means there you can't tell that a mailing list message is > a mutated forwarded message from whoever originally sent it. Skipping > ahead, you might at best end up with a very complex and fragile > mailing list whitelist. Same as SRS, really. > > * Asking users to manage their own security settings doesn't work. > See prior discussion of MUA highlighting and browser warnings. Maybe. They do manage their spam folders, and this may piggyback on that. > > PS: Most courtesy forwards don't break DKIM signatures. That's not an > accident. I know; I am not focussing on these "most" cases, but on the rest. Like this list :-) that requires DKIM re-signing. Thanks for your thoughtful thoughts! -Rick _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
