> On Nov 12, 2023, at 4:00 AM, Alessandro Vesely <ves...@tana.it> wrote: > > On Sat 11/Nov/2023 14:57:12 +0100 Neil Anuskiewicz wrote: >>>> On Oct 23, 2023, at 11:00 AM, Alessandro Vesely <ves...@tana.it> wrote: >>> My opinion is that Barry's text is good as is. As far as delimiting a >>> SHOULD NOT with another SHOULD is legit, this sentence sounds clear to me: >>> It is therefore critical that domains that host users who might >>> post messages to mailing lists SHOULD NOT publish p=reject. Domains >>> that choose to publish p=reject SHOULD implement policies that >>> their users not post to Internet mailing lists. >>> The exceptions to the latter SHOULD are rather obvious. Do we really need >>> to formally specify domain policing? >>> My perception is that Section 8.6 puts the issue in very clear terms. It >>> is even overly clearly and thoroughly explained for average readers. Only >>> IETF purists longing for email as it was in the 80s consider it important >>> to point out how DMARC is unjustly oppressing email forwarding, including >>> mailing lists. The rest of the world just use it as needed. >> What happened to the general purpose domain, actually subdomain, which I >> understood to be a non enforcing subdomain just for distribution lists. That >> idea was far from perfect but it seemed good. To clarify were you obliquely >> supporting the general purpose domain idea? >> I can think of alternatives but those alternatives clearly affect >> interoperability. Since. Discussion some weeks ago I learned here that we >> must consider interoperability at every step, which makes sense morally and >> practically in the face of a real interoperability issue. >> Yeah, I lurk enough to have drunk the koolaid. That said, are there list >> operators who participate and cogently make their case on why there’s no >> viable mitigating changes they could make? It’s plausible that the answer is >> no but it’s not 100% clear that this is a problem that can’t be solved. It’s >> pretty clear there aren’t good solutions on less bad ones. >> If this issue is already decided on and I’m beating a dead horse, I >> apologize. If I’m going to lurk it’s got to be every day for at least a few >> minutes to avoid dead horse beating that I’m sure is annoying. > > > A taxonomy of possible mitigations was published in 2014: > https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail > > That page distinguishes among sending side workarounds and other approaches. > The former can be implemented unilaterally without further discussions. > Discussions take decades, as we see. It seems that mailing lists, and > forwarding in general constitute a minor problem for the vast majority of > mailbox providers. The urgency for a better solution is only perceived by > mailing list users, an area where ietfers are especially active but the rest > of the world, on average, is not. > > There are cooperative solutions, but they won't be implemented until > forwarding becomes a noticeable problem for large operators.
Sir, that these mitigations can be implemented without discussion, then doesn't that make the problem needing mitigation outside the scope of this working group? The difference between no discussion and a working group is like the ocean and a bucket of water. Don't let anything that isn't a flat out blocker get in the way. Encourage use of the bucket but you can lead an admin to water. Neil > -- > > > > > _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
