We are laying out options, not specifying a MUST, So there is room for multiple approaches. The situation has been stuck because there is no good way to identify an innocuous edit from a harmless one.
Your proposal stimulated my thinking, so let me try to build on yours and come back to mine later. Assume that lists and most of the participating organizations want to cooperate, and that these evaluators will make accommodations if the list can be reliably identified. I can define three ways that a list can be reliably identified. The list bounce address is known to the evaluator, and: - The list bounce address is known to the evaluator and the message is DKIM-signed by the list bounce address. - The list bounce address is known to the evaluator, is the message's MailFrom address, and the message produces SPF PASS. - The list's server identities are known to the evaluator, and can be verified by IP address and/or Forward-confirmed DNS. The signature mechanism is preferred As a supplement, the LIST-ID could also be known to the evaluator. How is the "known" information conveyed? By a disclosure statement provided during list enrollment. It says something like this: This list validates author identity during enrollment and upon message submission, so messages from this list are not subject to identity-spoofing attacks. However, the list also applies standard edits to the message as it is being relayed, and these changes prevent normal authentication based on DKIM signatures from being used to validate the author address. Consequently, participating organizations are requested to bypass author (From Address) filtering for messages received from this list. List messages can be identified by <see above>. Please ask your email support organization to implement one of these exception mechanisms so that you can receive all posts to this list. If an exception is not granted, From addresses will be rewritten to work around this constraint, but many subscribers find that the rewritten address hinders usability." But many proposals die on the feedback problem. Even if an evaluator has made accommodations for the list, the list also needs to know that the accommodations are in place. So the rest of the enrollment process needs to look like this: "Please indicate the results of your exception request:" "___ Success. My organization has implemented the accomodation to bypass sender verification for messages coming from the list." "If you were unsuccessful, please indicate all of the situations which will require workarounds:" "___ A. My organization enforces sender DMARC policies. Please rewrite any affected messages." "___B. My organization will block list messages that use my domain in the >From address. Please rewrite these messages." "___C. My organization applies unconditional blocking of some domains based on domain suffix. As the effect of these filters may be unpredictable, please rewrite all messages coming to me." A savvy list operator should be able to construct some test messages to validate the subscriber's submission. If the subscriber responds to the test message, then the list operator knows that the test message was allowed. The subscriber should have a way to update his assessment at any time. Something along these lines would allow the list to rewrite messages going to AOL, rather than rewriting messages coming from AOL and going to organizations that have accommodated the lists in which they participate. Because the research is requested before the first message is sent, we escape the pattern of watching things break and then doing damage control. Doug Foster On Wed, Oct 6, 2021 at 5:20 AM Baptiste Carvello < de...@baptiste-carvello.net> wrote: > Hi, > > I'll just make a few quick points here, as my message from yesterday was > long enough :-) > > Le 06/10/2021 à 00:30, Douglas Foster a écrit : > > > > We clearly disagree about whether mailing list SHOULD be a closed > > group. > > Indeed we do, but ultimately it doesn't matter that much. > > The relevant question is not what mailing lists *should be*, but what > they *are*. > > It just so happens that some people (me included) would rather *not* be > protected from «any risk associated with interacting with strangers» by > some entity out of their control. Which can also mean taking one's own > precautions, as you describe. Still, if I wanted Facebook, I know where > to find them (OK, maybe not yesterday :-) > > > We also disagree about authorship. I argue that a message received > > directly from you is very different from a message received via the > > list. > > We indeed disagree. I can understand your point *in theory*. But in > practice, mailing lists do not *substantially* modify the contents of > the messages. This practice is not ensured through any *technical* > means, but through *social* means: reputation, threat of legal action in > the worst case… Communication is not just technology. > > FWIW, I would never post to a mailing list that altered the substance of > the messages, *even if* it would also alter the "From" field. > > > You propose special handling of messages from lists, but you gloss over > > the difficulties of identifying a list message. List headers appear > > in lots of mass mailings, and any header that cannot be authenticated > > cannot be trusted. > > To clarify my view: I don't believe messages from mailing list should > get a free PASS, except maybe as a temporary measure while a solution is > devised. > > What I believe is that DMARC implementers should take their own > responsibilities. If a receiving domain decides to enforce p=reject on > mailing-list messages, they should *silently discard* the messages and > face any related user complaints, not dump the problem onto the mailing > lists operators by bouncing. > > > Currently, lists have an outsized impact on network security. > > […] As a result, spammers know that universities are widely respected > > that universities are widely respected and easily spoofed, so those > > and easily spoofed, so those domains become weapons. > > You seem to view mailing lists as the only roadblock towards *universal* > DMARC adoption and subsequent end of all spoofing. I'm afraid this is > way unrealistic… > > Anyway, asking mailing lists to sacrifice themselves in the name of the > greater good (or your view thereof) does not seem like a constructive > strategy, nor an efficient one. > > Any constructive solution should take mailing lists as they are and work > with those requirements. Otherwise, the situation will stay as stuck as > it has been for several years already. > > Cheers, > Baptiste > > _______________________________________________ > 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
