On Thu, Aug 13, 2020 at 1:57 AM Alessandro Vesely <ves...@tana.it> wrote:
> On 2020-08-12 5:16 p.m., Steve Atkins wrote: > > On 12/08/2020 04:32, Dave Crocker wrote: > >> > >> Here's why I think it won't: They already have From:. > >> > >> The real value in DMARC is not what is displayed to the end-user but > >> in having a required field that cites the originating domain name. > >> That doesn't change if there are additional fields that might or > >> might not mention the originating domain. > > > > I think we disagree on the goal of DMARC. The entire point of DMARC is > > brand protection. Control over what is displayed to the user, not > > what's in any particular header. You could use it for other things, > > but that's what informed publishers of DMARC say they're using it for > > (sometimes phrased as "protection against phishing" but that too is > > all about what's displayed to the recipient). > > > Both MX filtering and MUA displaying are relevant, possibly more or > less relevant according to users and organizations. > > > > If you display the contents of Author to the user, then DMARC > > publishers will want to control that. > > > > If MUAs will display the contents of the Author: header where the > > From: header is now then draft-crocker-dmarc-author-00 effectively > > moves what used to be Sender: header to the From: header and what used > > to be the From: header to the Author: header. > > > I'd bet we have a good deal of time before MUAs react to the addition > of Author:. MX filters will react before them. MLM software will > hopefully react even faster. In fact, MUAs reaction will be based > rather on how the field usage will have been shaped by MXes and MLMs > than on Dave's I-D directly. > > IMHO, Author: is a necessary complement to DKIM transformations. One > transformation being "From: was rewritten, original value was saved in > Author:". Based on that tag, a DKIM verifier can produce a > canonicalization where the value of From: is put back in place, along > with undoing other transformations, so as to verify the original > signature. > > > > You could achieve exactly the same result, with much less deployment > > effort, by updating DMARC to enforce the Sender header and leaving > > MUAs displaying the From: header. > > > Sender: and Author: are not mutually exclusive. While it's true that > they aim at the same result, they are /not exactly/ like each other. > MLMs already set Sender:, and can easily begin to set Author:, but > won't stop to rewrite From: until they know MXes have upgraded. We > should conceive a standard that allows such dynamics. > > > > That wouldn't be acceptable to anyone who wants to publish DMARC, > > so the Author: proposal won't be either. > > Both these workarounds presume that domains hosting users' mailboxes > may want to publish a somewhat relaxed policy, yet stricter than > p=none. That seems plausible, especially if the class of acceptable > senders is tunable. Tunable! You said the magic word I have a client now getting spoofing. Tightening above p=none is a non starter as about 100% of MajorCRM emails fail SPF (foo.majorcrm is the RFC5321.from), 62% of MajorCRM mail fails DKIM, and 100% of MajorCRM Marketing * fails SPF (bar.some-esp.com). Oh, and some local office has a random MailChimp account not authenticated. We can't turn the knob on policy and MajorCRM support says you can't have your own mail from. Normally, with a client we would get on a screen share with Bob (the doer of all things) at a company or some other efficient arrangment to be able to make changes in applications, update DNS, test, monitor. Here, there's this dept with control of the CRM, another for marketing, another controls DNS, and a vendor says something isn't possible. My point is that it sure would be nice to be able to tune so that BigCRM and BigCRM Marketing * mail would pass DMARC comfortably, and we could then turn the dial on policy to cut off the spoofers without breaking legit mail. Yes, I know that this isn't the mailing list issue but tuning could solve that problem, too. Neil
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
