Re: [dmarc-ietf] list history, Signaling MLMs
On Sat, Apr 15, 2023 at 1:40 PM Scott Kitterman wrote: > > > On April 15, 2023 8:17:41 PM UTC, John R Levine wrote: > >> I'm assuming that the "long list of stinky possible workarounds" are > the existing "whatever" mitigations, and rewriting seems to be acceptable > enough as a mitigation to convince large [enterprise] mail systems to move > forward with restrictive policies. ... > > > >I think you are greatly overestimating the connection between cause and > effect here. The people setting the policies have no idea what effect they > have on their users, and to the degree they do, they do not care. IETFers > at large organizations who support their IETF work, and that have p=reject, > tell me they've told the IT departments that the policy is making it hard > for them to get their work done and the response is either "duh?" or "not > our problem." > > > >> I intentionally published > "p=quarantine pct=0" specifically to find > the MLMs that implemented no mitigations, weighed that against what I knew > about which receivers enforced non-mitigated mail, and then made a judgment > call to move forward. > > > >It sure would be nice if people at other organizations were as concerned > about the quality of mail service to their users. But noo. > > > >> I believe Wei suggested that we need to find a better "whatever" (in > the form of an alternative to SPF and DKIM that works with mailing lists) > ... > > > >I would like a pony, too. But ARC is as good as we have now and after a > decade of beating our heads against the wall, I don't think we're going to > find anything better. I've suggested a bunch of things that would make > lists' life better, and nobody is interested: > > > > Agreed. > > If someone has a great idea for a third way in email authentication, they > should develop the idea, get some deployment experience, and then document > the protocol. After that would come the question of adding it to DMARC. > This is not the working group to do that work. > Agreed such a proposal shouldn't be worked on in DMARC. Also agreed that it's a good idea to get deployment experience. That said, I think there is a lot of value in getting early IETF feedback in some other forum/mailing-list to help review the potential proposals. -Wei > > Scott K > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > smime.p7s Description: S/MIME Cryptographic Signature ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] list history, Signaling MLMs
On 4/15/2023 4:39 PM, Scott Kitterman wrote: On April 15, 2023 8:17:41 PM UTC, John R Levine wrote: I would like a pony, too. But ARC is as good as we have now and after a decade of beating our heads against the wall, I don't think we're going to find anything better. I've suggested a bunch of things that would make lists' life better, and nobody is interested: Agreed. If someone has a great idea for a third way in email authentication, they should develop the idea, get some deployment experience, and then document the protocol. After that would come the question of adding it to DMARC. This is not the working group to do that work. ARC is overhead junk to reach a more optimized solution with a TPA (Third Party Authorization) protocol. Anyone. Pick one. Maybe we should add an optional new SPF directive -DMARC:5322.From.domain To help resolve this problem DMARC discovery issues at SMTP? ARC is junk. Why is it IETF perpetuated is beyond me. Soon we will I-D proposals to clean up this massive overhead. -- HLS -- Hector Santos, https://santronics.com https://winserver.com ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] list history, Signaling MLMs
On April 15, 2023 8:17:41 PM UTC, John R Levine wrote: >> I'm assuming that the "long list of stinky possible workarounds" are the >> existing "whatever" mitigations, and rewriting seems to be acceptable enough >> as a mitigation to convince large [enterprise] mail systems to move forward >> with restrictive policies. ... > >I think you are greatly overestimating the connection between cause and effect >here. The people setting the policies have no idea what effect they have on >their users, and to the degree they do, they do not care. IETFers at large >organizations who support their IETF work, and that have p=reject, tell me >they've told the IT departments that the policy is making it hard for them to >get their work done and the response is either "duh?" or "not our problem." > >> I intentionally published > "p=quarantine pct=0" specifically to find the >> MLMs that implemented no mitigations, weighed that against what I knew about >> which receivers enforced non-mitigated mail, and then made a judgment call >> to move forward. > >It sure would be nice if people at other organizations were as concerned about >the quality of mail service to their users. But noo. > >> I believe Wei suggested that we need to find a better "whatever" (in the >> form of an alternative to SPF and DKIM that works with mailing lists) ... > >I would like a pony, too. But ARC is as good as we have now and after a >decade of beating our heads against the wall, I don't think we're going to >find anything better. I've suggested a bunch of things that would make lists' >life better, and nobody is interested: > Agreed. If someone has a great idea for a third way in email authentication, they should develop the idea, get some deployment experience, and then document the protocol. After that would come the question of adding it to DMARC. This is not the working group to do that work. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] list history, Signaling MLMs
I'm assuming that the "long list of stinky possible workarounds" are the existing "whatever" mitigations, and rewriting seems to be acceptable enough as a mitigation to convince large [enterprise] mail systems to move forward with restrictive policies. ... I think you are greatly overestimating the connection between cause and effect here. The people setting the policies have no idea what effect they have on their users, and to the degree they do, they do not care. IETFers at large organizations who support their IETF work, and that have p=reject, tell me they've told the IT departments that the policy is making it hard for them to get their work done and the response is either "duh?" or "not our problem." I intentionally published > "p=quarantine pct=0" specifically to find the MLMs that implemented no mitigations, weighed that against what I knew about which receivers enforced non-mitigated mail, and then made a judgment call to move forward. It sure would be nice if people at other organizations were as concerned about the quality of mail service to their users. But noo. I believe Wei suggested that we need to find a better "whatever" (in the form of an alternative to SPF and DKIM that works with mailing lists) ... I would like a pony, too. But ARC is as good as we have now and after a decade of beating our heads against the wall, I don't think we're going to find anything better. I've suggested a bunch of things that would make lists' life better, and nobody is interested: https://datatracker.ietf.org/doc/draft-levine-may-forward/ https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ 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] list history, Signaling MLMs
On Sat, Apr 15, 2023, at 12:07 PM, John Levine wrote: > It appears that Jesse Thompson said: > >Why not turn off rewriting on this list, as an experiment? The hypothesis is > >that everyone will switch to Gmail and not tilt > >at IETF, but instead they will tilt at their domain owners. > > That's how we got here. A lot of IETF participants use mail systems > that enforce DMARC policy (notably including Gmail) and we were > getting a lot of complaints about lost mail, and a lot of work with > people getting bounced off lists who list managers had to resubscribe. > Barry says that even with our mitigations, we still have the latter problem. > > We went through a long list of possible workarounds including several > kinds of rewrites and several kinds of message wrapping. They all > stauk but the one we picked, per-address rewrites for domains with > DMARC policies, stunk less. The option we picked requires more control > over the MTA than typical mailman or sympa installations have, so most > people's options are worse. > > I still don't understand the point of this argument. We all agree that > DMARC causes damage to interoperability, but some people appear to be > saying we should ignore it or pretend it doesn't exist because DMARC > has other advantages. The honest thing to do is to describe both. > > Nobody thinks we're going to get Yahoo to turn off p=reject (they said > at the time they turned it on that they don't care about mailing > lists) but I think there's some hope we can get large mail systems to > be more aware of the damage and use ARC or whatever to mitigate it. I'm assuming that the "long list of stinky possible workarounds" are the existing "whatever" mitigations, and rewriting seems to be acceptable enough as a mitigation to convince large [enterprise] mail systems to move forward with restrictive policies. I intentionally published "p=quarantine pct=0" specifically to find the MLMs that implemented no mitigations, weighed that against what I knew about which receivers enforced non-mitigated mail, and then made a judgement call to move forward. I believe Wei suggested that we need to find a better "whatever" (in the form of an alternative to SPF and DKIM that works with mailing lists) so that every domain, even those with members of the general publiic, may gain the benefits of DMARC. If an acceptable mitigation/auth-mechanism is established, does that mean DMARC will be revised to remove the "MUST NOT p=reject if general purpose"? Or is that going to be permanent? How about this?: "MUST NOT publish p=reject|quarantine if the domain owner, after examining the report data, has no means to mitigate all identified legitimate mail flow that which has no authenticated identifier aligned to the RFC5322.from domain. Mitigations may include arranging with all affected intermediaries and email sending providers to establish an aligned authenticated identifier, require the intermediary/ESP to use a different domain when sending this mail flow, or devise an alternative authentication mechanism outside the scope of this specification but is otherwise agreed upon by all affected parties." Jesse___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] list history, Signaling MLMs
It appears that Jesse Thompson said: >Why not turn off rewriting on this list, as an experiment? The hypothesis is >that everyone will switch to Gmail and not tilt >at IETF, but instead they will tilt at their domain owners. That's how we got here. A lot of IETF participants use mail systems that enforce DMARC policy (notably including Gmail) and we were getting a lot of complaints about lost mail, and a lot of work with people getting bounced off lists who list managers had to resubscribe. Barry says that even with our mitigations, we still have the latter problem. We went through a long list of possible workarounds including several kinds of rewrites and several kinds of message wrapping. They all stauk but the one we picked, per-address rewrites for domains with DMARC policies, stunk less. The option we picked requires more control over the MTA than typical mailman or sympa installations have, so most people's options are worse. I still don't understand the point of this argument. We all agree that DMARC causes damage to interoperability, but some people appear to be saying we should ignore it or pretend it doesn't exist because DMARC has other advantages. The honest thing to do is to describe both. Nobody thinks we're going to get Yahoo to turn off p=reject (they said at the time they turned it on that they don't care about mailing lists) but I think there's some hope we can get large mail systems to be more aware of the damage and use ARC or whatever to mitigate it. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
