Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
In article you write: >> "DISCUSS" shouldn't really be a joke. draft-crocker-dmarc-sender suffers >from a similar problem as PRA in the SenderId draft. There is no way to >validate that the specific intermediary is authorized by the (From) domain >originating the email through it's generic signalling that it >authorizes intermediaries. This means that any source can emit a message >claiming to be a legitimate intermediary just as any source could game PR >to gain a neutral result. That's a feature, not a bug. I want recipients to be able to assess the mail my lists send on its own merits. >One could achieve similar outcomes using >only reputation and local policy override of DMARC policy. Only if you believe that the domain on the From: line is automatically more credible than the one on the Sender: line. The whole third party problem is that the people sending their mail through lists or whatever are in fact doing so legitimately, but for various reasons their organizations' DMARC policies lie and say they aren't. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] third party authorization, not, was non-mailing list
In article <2e5408af-c3c1-1b34-4600-70a355ef0...@bbiw.net> you write: >I remember back then hearing various ideas or proposals and for many of >them thinking "I've no idea whether that will be useful or successful >but it sounds like something worth trying." Not so much these days. Alas. I'm perfectly happy to try stuff but considering how concentrated the mail business has gotten, unless a gorilla or two seems interested, "try" won't really happen. Also, we now have several more decades of experience about stuff that seemed appealing but failed. There's no shame in learning from experience. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] third party authorization, not, was non-mailing list
On 8/13/2020 5:21 PM, Murray S. Kucherawy wrote: I'm disappointed that the experiment never really got its day in court, but the consensus is clear. +1. 30 years ago, there was a generally adventurous tone in the community. Things are a lot more cautious now. I remember back then hearing various ideas or proposals and for many of them thinking "I've no idea whether that will be useful or successful but it sounds like something worth trying." Not so much these days. Alas. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
On Thu, Aug 13, 2020 at 8:23 PM Murray S. Kucherawy wrote: > On Mon, Aug 10, 2020 at 12:05 PM Tim Wicinski wrote: > >> During IETF 108, the chairs realized that there was interest in Dave's >> RFC5322.Sender draft. >> >> This starts a Call for Adoption for draft-crocker-dmarc-sender >> >> The draft is available here: >> https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/ >> >> Currently, the draft is marked as "Standards Track". The chairs feel if >> the >> working group does adopt this, it should begin as "Experimental". If we >> start >> to see adoption of this work, this can be changed back to "Standards >> Track" before >> Working Group Last Call. Of course, we welcome input from the working >> group on this. >> >> Please review this draft to see if you think it is suitable for adoption, >> and >> send any comments to the list, clearly stating your view. >> >> Please also indicate if you are willing to contribute text, review, etc. >> >> This call for adoption ends: 24 August 2020 >> > > DISCUSS. > > (just kidding; +1 for adoption) > > -MSK, participating, except for the joke part, that was with full authority > > "DISCUSS" shouldn't really be a joke. draft-crocker-dmarc-sender suffers from a similar problem as PRA in the SenderId draft. There is no way to validate that the specific intermediary is authorized by the (From) domain originating the email through it's generic signalling that it authorizes intermediaries. This means that any source can emit a message claiming to be a legitimate intermediary just as any source could game PR to gain a neutral result. This raises a significant question as to the value of this proposed draft. It essentially reverts to depending on reputation as to whether the intermediary's assertions (I'm really really trustworthy) should be accepted. One could achieve similar outcomes using only reputation and local policy override of DMARC policy. The only way a scheme along the lines of the proposed one would be if the specific intermediary were authorized either through a seperate DKIM signing of a field (with the intermediary domain ) that would remaintact even if the DKIM signing of the entire message were broken by the (authorized) intermediary. The proposed approach is easily abusable by individuals with malicious intent. Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
On Mon, Aug 10, 2020 at 12:05 PM Tim Wicinski wrote: > During IETF 108, the chairs realized that there was interest in Dave's > RFC5322.Sender draft. > > This starts a Call for Adoption for draft-crocker-dmarc-sender > > The draft is available here: > https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/ > > Currently, the draft is marked as "Standards Track". The chairs feel if > the > working group does adopt this, it should begin as "Experimental". If we > start > to see adoption of this work, this can be changed back to "Standards > Track" before > Working Group Last Call. Of course, we welcome input from the working > group on this. > > Please review this draft to see if you think it is suitable for adoption, > and > send any comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 24 August 2020 > DISCUSS. (just kidding; +1 for adoption) -MSK, participating, except for the joke part, that was with full authority ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] third party authorization, not, was non-mailing list
On Mon, Aug 10, 2020 at 10:27 AM Dave Crocker wrote: > > We have had a lot of attempts at third-party authorization schemes > > > With this in mind, I cannot see any point in designing yet another > > vouching or authorization scheme unless we have evidence that an > > interesting fraction of the world's mail systems want to use it. I > > don't see that, and honestly see no chance that we ever will. > > +1 > I'm disappointed that the experiment never really got its day in court, but the consensus is clear. +1. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
In article you write: >-=-=-=-=-=- > >During IETF 108, the chairs realized that there was interest in Dave's >RFC5322.Sender draft. > >This starts a Call for Adoption for draft-crocker-dmarc-sender It needs some work but it's worth adopting. I might do a review or two but you know how shy I am. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] "Email architecture is single author"
On 8/13/20 7:13 AM, Doug Foster wrote: > My thinking is based on these foundations: > - the incoming email gateway is an AAA server which conditionally allows > anonymous logins > - The NIST framework for digital identity. https://pages.nist.gov/800-63-3/ I fail to see how NIST SP 800-63-3 Digital Identity Guidelines has anything to do with this. Jim Fenton Altmode Networks ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Firing the vendor
Yours is the better answer!DF Original message From: Dotzero Date: 8/13/20 5:54 PM (GMT-05:00) To: dmarc@ietf.org Subject: Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ? On Thu, Aug 13, 2020 at 5:43 PM Kurt Andersen (b) wrote: > On Thu, Aug 13, 2020 at 2:33 PM Doug Foster 40bayviewphysicians@dmarc.ietf.org> wrote: > >> The current DMARC architecture supports authorizing a vendor to mail on >> behalf of their clients if the client includes them in their SPF policy or >> delegates a DKIM scope to them and they use it. >> >> >> >> I agree that SPF is too limiting (including hard limits on complexity), >> and DKIM is too complex for an uncooperative vendor. >> >> >> >> In most cases, a solution would be a controlled third-party signature >> authorization along the lines of RFC 6541. >> >> The client would configure the authorization in his own DNS and the and >> the vendor would only need to sign with their own DKIM signature. >> > > If "DKIM is too complex for [this] uncooperative vendor", why would having > the "vendor...sign with...DKIM" be workable? > Wrong answer. If the vendor is uncooperative then fire the vendor. 4-5 years ago it was difficult to find vendors who were willing to deal with DKIM and able to do a good job in implementing. The common mantra was "how does this fit into my business model". These days I would consider it table stakes. Michael Hammer > > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
On Thu, Aug 13, 2020 at 5:43 PM Kurt Andersen (b) wrote: > On Thu, Aug 13, 2020 at 2:33 PM Doug Foster 40bayviewphysicians@dmarc.ietf.org> wrote: > >> The current DMARC architecture supports authorizing a vendor to mail on >> behalf of their clients if the client includes them in their SPF policy or >> delegates a DKIM scope to them and they use it. >> >> >> >> I agree that SPF is too limiting (including hard limits on complexity), >> and DKIM is too complex for an uncooperative vendor. >> >> >> >> In most cases, a solution would be a controlled third-party signature >> authorization along the lines of RFC 6541. >> >> The client would configure the authorization in his own DNS and the and >> the vendor would only need to sign with their own DKIM signature. >> > > If "DKIM is too complex for [this] uncooperative vendor", why would having > the "vendor...sign with...DKIM" be workable? > Wrong answer. If the vendor is uncooperative then fire the vendor. 4-5 years ago it was difficult to find vendors who were willing to deal with DKIM and able to do a good job in implementing. The common mantra was "how does this fit into my business model". These days I would consider it table stakes. Michael Hammer > > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
On Thu, Aug 13, 2020 at 2:33 PM Doug Foster wrote: > The current DMARC architecture supports authorizing a vendor to mail on > behalf of their clients if the client includes them in their SPF policy or > delegates a DKIM scope to them and they use it. > > > > I agree that SPF is too limiting (including hard limits on complexity), > and DKIM is too complex for an uncooperative vendor. > > > > In most cases, a solution would be a controlled third-party signature > authorization along the lines of RFC 6541. > > The client would configure the authorization in his own DNS and the and > the vendor would only need to sign with their own DKIM signature. > If "DKIM is too complex for [this] uncooperative vendor", why would having the "vendor...sign with...DKIM" be workable? --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
On Thu, Aug 13, 2020 at 12:06 PM Neil Anuskiewicz wrote: > > Tunable! You said the magic word I have a client now getting spoofing. > Receiving spoofed mail or having their domain *being* spoofed? > 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. > Passing DMARC is not a be-all-end-all. That's what local policy is for. I fail to see why local policy would not solve your problem (as described). --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
If I followed Neil’s discussion of MajorCRM: The current DMARC architecture supports authorizing a vendor to mail on behalf of their clients if the client includes them in their SPF policy or delegates a DKIM scope to them and they use it. I agree that SPF is too limiting (including hard limits on complexity), and DKIM is too complex for an uncooperative vendor. In most cases, a solution would be a controlled third-party signature authorization along the lines of RFC 6541. The client would configure the authorization in his own DNS and the and the vendor would only need to sign with their own DKIM signature. This is not an unreasonable ask for most vendors, but this particular one seems inexcusable. Unfortunately, the past attempts with third-party signatures have died for lack of interest. The clients of this vendor might be motivated to participate, but it would also require participation from the domains that receive messages from this vendor on behalf of the client. Dave Crocker’s proposal has the same obstacles because it is a form of third-party signature authorization. We would need to find a highly respected mailer who thinks they could stir up interest from their clients. But major mailers will not depend on a new system until they are sure that it is fully deployed. So the chicken-and-egg problem may doom every effort. DF ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
On Thu, Aug 13, 2020 at 12:21 PM Dotzero wrote: > > > On Thu, Aug 13, 2020 at 3:06 PM Neil Anuskiewicz > wrote: > >> >> >> 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. >> >> So what you are saying is that you want an IETF working group to write a > standard that papers over poor self control on the part of your > organization. > Not my organization. I'm a freelancer. No, I'm saying that the IETF should write a standard that helps people in the field solve problems. > > >> 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. >> >> > The way you solve the problem described above is to get control of your > mail flows. I've worked with various "big CRM" vendors and they will gladly > accept a delegated subdomain (they control DNS and therefore SPF and DKIM > signing as well as publishing DMARC. There are other approaches as well. > Your post illustrates one of the problems with the discussion on this list. > People are conflating internal organizational issues with requirements for > interoperability. You could always publish 0.0.0.0 -all for your SPF record > and solve all your DMARC assertion issues very easily. > I set up subdomains for clients to use for their mail streams all the time so I agree. It's just the standard that sometimes stands in the way of cutting off spoofers. And that's ultimately the goal of the standard. Allow legit mail, stop bad guys. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
On Thu, Aug 13, 2020 at 3:06 PM Neil Anuskiewicz wrote: > > > 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. > > So what you are saying is that you want an IETF working group to write a standard that papers over poor self control on the part of your organization. > 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. > > The way you solve the problem described above is to get control of your mail flows. I've worked with various "big CRM" vendors and they will gladly accept a delegated subdomain (they control DNS and therefore SPF and DKIM signing as well as publishing DMARC. There are other approaches as well. Your post illustrates one of the problems with the discussion on this list. People are conflating internal organizational issues with requirements for interoperability. You could always publish 0.0.0.0 -all for your SPF record and solve all your DMARC assertion issues very easily. Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
On Thu, Aug 13, 2020 at 1:57 AM Alessandro Vesely 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
Re: [dmarc-ietf] non-mailing list use case for differing header domains
-Admittedly, that's where my bias comes in. My job is working with organizations that have paid my employer for me to be that outside help, so it's rare for me to see how badly it can be done by people setting restrictive DMARC policies without knowing what they're doing. If they all talked to you first, we'd be having a very different discussion. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] "Email architecture is single author"
In brief: My thinking is based on these foundations: - the incoming email gateway is an AAA server which conditionally allows anonymous logins - The NIST framework for digital identity. https://pages.nist.gov/800-63-3/ In that regard, digital identity is the focus, not human headcount. "customerserv...@example.com" can be an author, even though different individuals are responsible for different messages. My definition of a multiple-author architecture would be one where: - General: The different section of the message must be tagged with the identity of the author for that section. - Specific: Since the email infrastructure is an untrusted environment, the identities must be verifiable by some mechanism. The chairs would probably consider this off-topic at this time, but I would be willing to pursue a theoretical discussion at an appropriate time or forum. On the larger point: You can launch an experiment with or without the paperwork blessing of IETF Experimental status, and you may get IETF blessing despite my objections. You can begin recruiting domain owners immediately. So I am not your problem. What you need is a really good sales pitch to convince many thousands of domain owners, and the trade press, that this is something that they should implement.The pitch needs to include: - The mailing list problem is important to the email security manager. - The mailing list behavior which creates the problem is legitimate. (Abandon the argument that DMARC creates the problem.) - This proposal is a sufficient solution to the problem. - This proposal is the best solution to the problem. - This proposal is a secure solution to the problem. You should view me as the practice session for the sales pitch that really matters. You will not get far with the sales pitch my telling your audience that they are wrong. My warning is that you do not have a convincing sales pitch at this time. I believe the sales pitch has problems in every one of these categories. DF ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] The DMARC WG has placed draft-crocker-dmarc-sender in state "Call For Adoption By WG Issued"
On 2020-08-13 1:59 a.m., John Levine wrote: In article <01d670ee$e38f8750$aaae95f0$@bayviewphysicians.com> you write: The author fails to recognize that we have a single-author email architecture. Consequently, the last entity to alter the message IS the author. Sorry, but no. The structure of Internet mail is quite clear, and that's not it. I can believe there are people who wish it were like that, but no. I think Doug meant the email architecture as induced by DMARC. Some people can sit together and write a multi-authored message. If they set a multi-mailbox From:, then their message cannot be DMARC validated, and can hardly be sent to a mailing list. Let me note that much of Doug's analysis is correct. We need to fix the weak points he mentions. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] non-mailing list use case for differing header domains
"I do get the instinct to be proactive but if you’re going to be proactive, get ready to take the time and, if outside help needed, the money to do it without breaking legit mail." -Admittedly, that's where my bias comes in. My job is working with organizations that have paid my employer for me to be that outside help, so it's rare for me to see how badly it can be done by people setting restrictive DMARC policies without knowing what they're doing. Best, Autumn Tyr-Salvia atyrsal...@agari.com Agari Principal Customer Success Engineer From: Neil Anuskiewicz Sent: Wednesday, August 12, 2020 3:17 PM To: John Levine Cc: dmarc@ietf.org ; Autumn Tyr-Salvia Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains > On Aug 7, 2020, at 12:12 PM, John Levine wrote: > > In article > > you write: >> I feel like what is happening sometimes is that central university IT is >> trying to drag their whole institutions into a >> more secure posture before anybody in a position to stop them fully >> understands what's going on lest they be told to >> stop because it might make things a little inconvenient. > > I was with you up until that sentence, since it trivializes the real > problems that overly strict DMARC policies cause. > > Just yesterday I was sorting out a problem with people trying to > finish editing a revised IETF standard about real-time web > applications. Some of the authors' messages were disappearing, > apparently at random. I saw what the problem was, one of the authors > is at a big company whose IT department insists on p=reject (and has > blown off complaints from fairly senior people about the problems it > causes), the other uses an MIT alumni address that recently moved its > hosting to Microsoft without telling anyone that the new host enforces > DMARC policy while the old one didn't. > > My guess is that MIT figured Microsoft will host this for free, that's > great, totally unaware that some of its users' mail would silently > break. > > I told them as a workaround they needed to directly cc each other when > they send anything to the group list, but the whole thing is a > self-inflicted wound. > > R's, > John > > ___ > dmarc mailing list > dmarc@ietf.org > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmarcdata=02%7C01%7Catyrsalvia%40agari.com%7C2388c4693f9a41d84d4308d83f0d7ab4%7C05773123385e420d844ef01aee5e37ab%7C0%7C0%7C637328674420006184sdata=u2xp7UMS7OHzkkyzHeoKa9Ri3w8v7sjJWvW%2BXuepmj4%3Dreserved=0 When mail breaks it’s more than an inconvenience. In business it can materially affect people’s livelihoods. I do think that sometimes people don’t take p=reject seriously enough, and don’t realize how much time and monitoring and prep it takes. I mostly work with smaller entities but I advise staying at p=none of the time unless there’s spoofing. Otherwise, it’s reporting only, watch the reports, and take action if and only if there’s a problem. I do get the instinct to be proactive but if you’re going to be proactive, get ready to take the time and, if outside help needed, the money to do it without breaking legit mail. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
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. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
On 2020-08-10 9:04 p.m., Tim Wicinski wrote: This starts a Call for Adoption for draft-crocker-dmarc-sender +1, the I-D needs work and coordination with other I-Ds by the WG. Please also indicate if you are willing to contribute text, review, etc. Yes, I will. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
