Re: [dmarc-ietf] a detour into lists, Another p=reject text proposal
Unsophisticated administration will be mediated when/if software developers make the necessary features available out-of-the-box. At least one reason that we have undesirable DMARC dispostioning is software that implements reject-on-fail without a test mode and without a usable override process. Doug On Sun, Jul 9, 2023, 2:17 PM John Levine wrote: > It appears that Murray S. Kucherawy said: > >1) Are list operators and developers tolerating this situation, > >temporarily, because they think this crew is going to come up with a less > >disruptive permanent solution to which they expect to migrate one day? > > > >2) If not, have they resigned themselves to such things as From rewriting > >as the way of the future? > > In my experience, most list operators don't know much about mail, and > twiddle list settings based on guesses and advice from other list > owners to try and minimize complaints. > > I am on a list where they put the list's name and only the list's name > in the From header. You literally cannot tell who sent a message if > the authors don't put their name in the body. When I suggested to the > list owners that they fix it, they basically shrugged, isn't that how > lists work? > > On a list that I host for a folk dancing group, I have had this dialog > at least five times: > > Owner: X and Y complained that they were unsubscribed, some evil person > must be hacking the list! > > Me: No, when they report a list message as spam, their mail provider > sends an unsubscribe message. > > Owner: They say they didn't do that. > > Me: Well, someone at their provider sent unsubs from their addresses. > The logs don't lie. > > Owner: Oh. > > >3) If so, how big (or small) is the set of DMARC accommodations on which > >they seem to be converging? > > The sophisticated ones do reversible address rewrites like we do, but > that requires having access to the underlying MTA to reverse the > rewrites. Everyone else munges the From header. If you're lucky > they'll put the author's name in the From comment and the address in > the Reply-To, but as often as not, they don't, probably because they > don't understand why it matters. > > ___ > 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] Another p=reject text proposal
Murray S. Kucherawy writes: > On Fri, Jul 7, 2023 at 6:35 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > > Consequently, the problem remains: How does an evaluator distinguish > between a legitimate list and a malicious attack? > > If we had a reliable answer to that, this would've been over ages ago. > Unfortunately, any mechanism we create for lists to distinguish their traffic > can be trivially co-opted by bad actors. I think phishing attacks using mailing list format would not be as efficient as it would be to inpersonate some other user that the intended recipient is familiar with. Mailing list are also something that quite a lot people already have special filters for, i.e., direct them to separate mailbox, allow them to go through without spam checking etc. For mailing lists users actually joined willingly, the users are familiar to, and have ability to cope. If it is mailing list they got added without their real consent, then if some of those messages gets lost because it is run through spam filtering and they get some extra spam points because no dkim signature etc the user probably do not care even if they are thrown away. The problem with DMARC checking is that it is usually done too early, and without consulting intended recipient whitelist/policy etc. Users can't add rules that say that mailing lists having DKIM signature of header.d=ietf.org are ok, and should get through even when the DMARC checks fails. -- kivi...@iki.fi ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] a detour into lists, Another p=reject text proposal
It appears that Murray S. Kucherawy said: >1) Are list operators and developers tolerating this situation, >temporarily, because they think this crew is going to come up with a less >disruptive permanent solution to which they expect to migrate one day? > >2) If not, have they resigned themselves to such things as From rewriting >as the way of the future? In my experience, most list operators don't know much about mail, and twiddle list settings based on guesses and advice from other list owners to try and minimize complaints. I am on a list where they put the list's name and only the list's name in the From header. You literally cannot tell who sent a message if the authors don't put their name in the body. When I suggested to the list owners that they fix it, they basically shrugged, isn't that how lists work? On a list that I host for a folk dancing group, I have had this dialog at least five times: Owner: X and Y complained that they were unsubscribed, some evil person must be hacking the list! Me: No, when they report a list message as spam, their mail provider sends an unsubscribe message. Owner: They say they didn't do that. Me: Well, someone at their provider sent unsubs from their addresses. The logs don't lie. Owner: Oh. >3) If so, how big (or small) is the set of DMARC accommodations on which >they seem to be converging? The sophisticated ones do reversible address rewrites like we do, but that requires having access to the underlying MTA to reverse the rewrites. Everyone else munges the From header. If you're lucky they'll put the author's name in the From comment and the address in the Reply-To, but as often as not, they don't, probably because they don't understand why it matters. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC session agenda for IETF 117
Barry, Can you add pointers to the various text options (perhaps links to the mailing list archive) so we’re all working off the same text? And which is the “current text”? -Jim On 6 Jul 2023, at 8:00, Barry Leiba wrote: > Below is the agenda I am posting for the session at IETF 117. > Comments, changes, and additions are welcome; please post them here. > > Barry > > --- > > DMARC working group session at IETF 117 > Friday, 28 July, 2023 — 12:00-13:30 PDT (UTC-7) > > - Introduction and administration > - Document status > > - Discussion of p=reject: > - What’s needed to deal with the indirect mail flow problems? > - Options currently open: > - No change to current text > - Move ARC to Standards Track (need more data) > - Scott Kitterman’s proposed text > - Barry Leiba’s proposed text (new Interoperability Considerations > section) > - AD will call consensus on this issue > > - Discussion of SPF use in DMARC > - There was a proposal to remove SPF from DMARC > - The proposal is *only* related to use of SPF *in DMARC* > - Options currently open: > - No change to current text > - Simply remove SPF from DMARC consideration > - Add a DMARC record tag to specify use of SPF, DKIM, or either > - Do we also add “both must align”? > > - Any other business > > --- > > ___ > 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] Another p=reject text proposal
The point isn't to place blame. The point is to specify how to maintain interoperability, and in the case of DMARC p-reject there are two places where we can lessen the interop problems: telling the senders not to use p=reject in inappropriate conditions, and telling the receivers to consider the interop issues when honoring the p=reject policy. The latter is necessary partly because some senders will ignore the former... but it is also necessary because even in cases where p=reject *is* used as it was intended, some legitimate mail will get caught up by it and judgment is important. None of this text is meant to chastise or blame. Barry On Sat, Jul 8, 2023 at 2:25 PM Scott Kitterman wrote: > > > > On July 8, 2023 6:16:46 PM UTC, Tero Kivinen wrote: > >Brotman, Alex writes: > >> I suspect the portion that instructs receivers to not act solely on > >> p=reject may be ignored by a fair set of receivers. I'm not > >> necessarily opposed to the language below, just that it seems odd to > >> create language that we know will be ignored. > > > >If receivers ignore that, then at least we can complain to them and > >say that you should not do that, as the RFC says you should use other > >information too if they want to get important forwarded emails > >through. For example we in iki.fi have been regularly been helping > >people with their broken spf etc records which break forwarding, and > >several times we have actually managed to explain the situation and > >they have change their settings. Quite often those people simply > >follow whatever some consultant etc suggested, and they did not > >understood at all that they at the same time broke other things. > > > >Quite often they do want to reduce the amoung of support calls, and if > >they get support calls every time some forwarded email from mailing > >list or from forwarding gets rejected, they most likely will notice > >that and fix their setup. > > > >> Additionally, I find it odd that we won't tell forwarders how to > >> munge messages to avoid this situation, but we will tell receivers > >> how to avoid this situation. > > > >There is no good way for forwards to mungle message in such way that > >return path/DKIM/user expectations stays intact. I myself for example > >find the From address mangling done by this mailing list really > >annoying as I need to use extra time to parse the =40 addresses to > >find out domain name of the sender. > > > >For mailing list this is just annoying but you can do that, but for > >regular forwarding you can't do that as you want to keep the DKIM > >signature intact. > > > >And this problem is not generated by forwarders, it is generated by > >the receivers who only use DMARC and no other information while > >rejecting emails. So there is no point of asking forwarders to fix > >things that was broken by DMARC... > > You can equally argue that these receivers are merely following the policy > advice provided by the sending domain (it has reject right in the name) and > this problem is entirely generated by sender's inappropriate use of p=reject. > > I don't think engineering the location where the blame lands is the right > place to focus. I've done plenty of blame avoidance engineering in my day, > but I don't think it's what the IETF should be doing. > > Scott K > > ___ > 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] Another p=reject text proposal
On 7/8/2023 3:22 PM, Tero Kivinen wrote: Scott Kitterman writes: You can equally argue that these receivers are merely following the policy advice provided by the sending domain (it has reject right in the name) and this problem is entirely generated by sender's inappropriate use of p=reject. True, thats why the proposed text also says you SHOULD NOT put p=reject... :-) If this is a SHOULD NOT mandate for the publisher, then for the compliant receiving verifier it can be translated to: 1) Verifier SHOULD ignore p=reject domains, or 2) Verifier MAY ignore p=reject domains. Which one is better? Is this good to have in the specs? I don't think engineering the location where the blame lands is the right place to focus. I've done plenty of blame avoidance engineering in my day, but I don't think it's what the IETF should be doing. It would be much better when people would really remember that having valid or not valid DMARC/DKIM/SPF for email does not tell anything whether the email is bad/spam/unwanted. Well, my philosophy has always been SPF and DKIM Policy modeling was about deterministic negative filtering of the mail stream. Getting rid of the junk with minimal false positives before feeding it to the next stage. It does not say the valid sender is good or bad. That would be a reputation trust design issue we have not resolved as a IETF community standard yet (see VBR note below). They say there are big systems using proprietary Reputation Engines, but the community does not have access to them. Consider, if big systems are willing to pay a fee to the validation receiver to do a "Good or Bad Mail" lookup at ACME Reputation service that would be interesting and long sought by some early explorers. Yes, I said, Big guy pay the Small guy for handling their spam correctly because there is a significant cost associated with receivers processing mail. Unfortunately, this would be the classic "Batteries Required" syndrome where a receiver would need to buy and/or install branded batteries to get that 2nd Reputation layer. If this SaaS was to materialize, what may happen are Bad Guys beginning to target receivers who lack the Reputation batteries or have different batteries. Smaller receivers may be hurt by this. Regardless whether the DMARC/DKIM/SPF is valid you always need to use other methods to filter emails, so as you need to do that anyways while receiving emails, there is no problems of using same things also for p=reject messages. You can use the failed dmarc with p=reject as one of the inputs to feed your actual email filtering system, the dmarc p=reject SHOULD NOT BE your only email filtering system. The combination of rules and logic that works best as a whole is indeed a holy grail item, a golden egg at the end of the rainbow, etc. But we do have reputation folks who believe that is all we need - subjective reputation method. It doesn't matter what SPF or DMARC says as long as the receiver trust the last signer. It is part of the DKIM-BASE specs for the assessment concept. The problem has been what other identities do we need? As DMARC has shown, there are many DKIM Policy advocates who believe valid 1st party Author published policies about their mail system is a good thing. DMARC proposed the following identities are part of the PASS evaluation equation: SignerID5322.Dkim-Signature "d=" domain AuthorID5322.From domain UserAgentID 5322.Dkim-Signature "i=" domain/address ReturnPathID5321.MailFrom Domain In summary, for me, its about filtering the failures of the protocol rules established. If publisher says ABC and Receiver sees XYZ, there is a detectable condition to work with. Do this first and you have a "cleaner" stream to apply some reputation logic. Levine's VBR "Vouch By Reference" RFC 5598 was suppose to do this part for us. Once the mail is clean (everything is a pass), you do a VBR look up as a function of the signer id, the author id and some "category" tag designed for marketers. That was suppose to be an Authorized Good Reputation lookup, I believe. In my opinion, when VBR was invented in 2009, I didn't think VBR was ready for prime time and people were resisting the idea of a central repository for reputation, who owns it? But almost 15 years later, maybe it would be more acceptable today? Only the editors of the VBR proposal can speak as to why it wasn't pushed or help. -- Hector Santos, https://santronics.com https://winserver.com ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
Our solution approach is binary: either we fix the list problem by doing less authentication, which is Barry's proposal, or we fix the list problem by doing alternate authentication.Alternate authentication is the one we need to pursue, because the other approach has already been rejected by too many participants. List traffic needs to be evaluated based on the list's own reputation. The MailFrom address cannot accomplish this result on its own. From munging provides the necessary trigger to ensure that all evaluators will use the list domain reputation. There is upward and backward compatible with all evaluators. The secondary but largely independent problem is the user experience caused by From munging. Until recently, we had no solution to this. We also had the related objection that From munging fixes DMARC by deception. ARC addresses both of these issues. ARC provides the information needed to reverse the munging, which means that evaluators can solve the user experience problem. ARC also provides data so that the forwarding event is well documented, so there is no deception. >From munging does mean that the list takes full responsibility for the message, and consequently the list takes the reputation hit if unwanted traffic is forwarded. Some posts have suggested that lists think they can presently dodge that risk somehow. I say they bear that risk already. Ideally, all forwarding should be pre-approved. The forwarder needs to know that the traffic is wanted and will be accepted. So we need more than From munging and ARC-derived un-munging. But this combination is a start. Doug On Sun, Jul 9, 2023, 12:27 AM Murray S. Kucherawy wrote: > On Fri, Jul 7, 2023 at 6:35 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> Consequently, the problem remains: How does an evaluator distinguish >> between a legitimate list and a malicious attack? >> > > If we had a reliable answer to that, this would've been over ages ago. > Unfortunately, any mechanism we create for lists to distinguish their > traffic can be trivially co-opted by bad actors. > > >> My answer: Lists need to use From munging to avoid DMARC FAIL, and hope >> that sophisticated evaluators will use ARC data to un-mung before delivery. >> > > Someone else asserted that lists have been dealing with DMARC damage by, > among other things, rewriting From fields for some years now. Let me pose > a couple of questions to list operators and developers and those friendly > to those audiences: > > 1) Are list operators and developers tolerating this situation, > temporarily, because they think this crew is going to come up with a less > disruptive permanent solution to which they expect to migrate one day? > > 2) If not, have they resigned themselves to such things as From rewriting > as the way of the future? > > 3) If so, how big (or small) is the set of DMARC accommodations on which > they seem to be converging? > > -MSK, participating > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Messages from the dmarc list for the week ending Sun Jul 9 06:00:04 2023
Count| Bytes | Who ++--- 47 ( 100%) | 414179 ( 100%) | Total 9 (19.1%) | 70748 (17.1%) | Barry Leiba 6 (12.8%) | 75862 (18.3%) | Douglas Foster 6 (12.8%) | 31399 ( 7.6%) | John Levine 5 (10.6%) | 50719 (12.2%) | Scott Kitterman 5 (10.6%) | 41509 (10.0%) | Murray S. Kucherawy 4 ( 8.5%) | 28375 ( 6.9%) | Alessandro Vesely 2 ( 4.3%) | 22526 ( 5.4%) | Marcello 2 ( 4.3%) | 22448 ( 5.4%) | Hector Santos 2 ( 4.3%) | 19366 ( 4.7%) | Todd Herr 2 ( 4.3%) | 13599 ( 3.3%) | Tero Kivinen 1 ( 2.1%) | 22285 ( 5.4%) | Brotman, Alex 1 ( 2.1%) | 7153 ( 1.7%) | Richard Clayton 1 ( 2.1%) | 5187 ( 1.3%) | Baptiste Carvello 1 ( 2.1%) | 3003 ( 0.7%) | ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
