Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

[Douglas Foster <[e-mail]>]

Baptiste, you are partially right.

For those who want more reliable delivery and better UX, improvement can
advance on two-prongs.    Evaluators who have the savvy and the motivation
to implement an unmunging algorithm can be advised to do so for the benefit
of their users.   Mailing List Operators who have the savvy and the
motivation to use recipient preferences to minimize munging can also be
advised to do so for the benefit of their subscribers.   Neither group will
see 100% deployment of a solution, so the best outcome will occur if each
participant implements what they can.   Both solutions depend on evaluators
knowing how to characterize messages from any particular mailing list, and
that becomes complicated if the message is forwarded.   IETF MAY be able to
facilitate all three aspects of the problem space, although that remains to
be seen.

Those who are unmotivated to optimize delivery rates can certainly wait for
others to implement a solution.


On Wed, Oct 13, 2021 at 9:36 AM Baptiste Carvello <
[e-mail]> wrote:

> Hi,
>
> I'm happy to see the discussion advancing: we now seem to have consensus
> that redesigning mailing lists behind their backs is a bad idea, and
> that the existence of From rewriting as an emergency hot-fix does not
> preclude looking for more satisfactory solutions. Good work!
>
> Now, I'm skeptical of your solution. First, I don't think 100%
> deliverability at all times is a hard requirement. The Open Source
> mailing lists I care about really don't have a deliverability problem:
> I'm sure LKML can afford that messages from and/or to a few peculiar
> domains get lost for a few months, if that's the price to pay to build
> incentives for a collaborative solution (I don't expect receivers to
> invest into unmunging if they don't have a strong incentive).
>
> Also, having this munging-then-unmunging dance as the *normal* procedure
> sounds backwards. If the receivers make the delivery decision alone, why
> can't they implement it all on their side: let the incoming message
> pass, munge it with an alias under their control, wrap it into a
> message/rfc822 body part, silently discard it, whatever they want, it's
> their system, their UX, their users.
>
> The only reason for insisting that mailing lists speculatively do the
> munging on their side is some strange fetish on the value of the From
> field during transit… where nobody will read it. Oh, and the risk of
> bounces, of course, which should IMHO be eliminated in this special case.
>
> Cheers,
> Baptiste
>
> Le 12/10/2021 à 12:04, Alessandro Vesely a écrit :
> > From: rewriting confers 100% deliverability on messages, but has a bad
> > impact on the end user.
> >
> > If we consider collaborative solutions, we see that, because of their
> > very nature, they cannot cover all cases.  So, it is safer to look for
> > collaborative solutions that allow unmunging than to solutions that
> > avoid munging in the first place.  Indeed, in the former case the risk
> > is to deliver a munged message, while in the latter one the risk is to
> > either not deliver or not to implement DMARC.
> >
> > Even ARC can be turned into a method to unmunge.  It requires
> > collaboration between MLM and receiver.  My unmunging method requires
> > cooperation between author's domain, MLM, and receiver.  Whitelisting
> > can be done unilaterally by receivers, who can restore the original
> > From: without validating the author's domain signature, just because
> > they trust the MLM.  By collecting similar techniques, we might be able
> > to cover almost all cases while still ensuring deliverability.
> >
> >
> > Best
> > Ale
> >
> >
> >
> > On Tue 12/Oct/2021 04:40:12 +0200 Douglas Foster wrote:
> >> Barry, you did a nice job of talking me off the ledge.
> >>
> >> If this is about helping list operators and message evaluators to
> >> collaborate in a way that avoids From-Munging, I have no objections.
> >>
> >> Repeatedly, the topic has seemed to turn in directions that make the
> >> evaluator appear irrelevant -- as if the Lists don't need to talk to
> >> them.
> >>
> >> The reality right now is that a lot of From-Munging is unnecessary
> >> because:
> >> - many evaluators do not enforce DMARC
> >> - some evaluators enforce DMARC but have made exceptions for active
> lists
> >> - some other evaluators enforce DMARC and will make exceptions if
> >> asked to
> >> do so by their users
> >> This leaves a small group, like AOL, who enforce DMARC and yet are
> >> unresponsive to their users.   This small group needs From-Munging, or
> >> unmodified messages, or different email accounts for list participation.
> >>
> >> I claim, without proof, that many of the most vocal critics of
> >> From-Munging
> >> are using domains that do not require From-Munging on incoming messages.
> >>   In such cases, the DMARC-enforcing sender is not the real
> >> problem, ignorance is.
> >>
> >> Once the list and the evaluator have agreed to collaborate, we have a
> >> bunch
> >> of signalling options, including options that survive forwarding.   They
> >> are mostly simple extensions of things we are already doing, much
> simpler
> >> and more determinative than ARC.
> >>
> >> Doug Foster
> >>
> >>
> >> .
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Mon, Oct 11, 2021 at 10:28 AM Barry Leiba <[e-mail]>
> >> wrote:
> >>
> >>> It's not that the IETF shouldn't be involved with advice on what
> >>> mailing lists should do.  It's that if we should put out a BCP or a
> >>> standard that says mailing lists MUST NOT alter messages that they
> >>> forward, those who write mailing list software (and those who deploy
> >>> it) will not listen.  That's where Scott's "we're not the police"
> >>> statement comes in.
> >>>
> >>> For whatever it's worth, mailing lists have been behaving this way
> >>> for, as others have said, decades, and it has been considered good
> >>> practice and has been found useful.  Mailing lists add footers on
> >>> messages, whether to advertise the list, to add disclaimers, or
> >>> whatever.  They like it, and won't change.  Mailing lists add the list
> >>> name to the Subject line because it makes it easier to create filters,
> >>> and because it makes it easier for eyeballs to filter (for the vast
> >>> majority of users who don't know and don't want to know how to create
> >>> filters).  They like that too, and that, too, won't change.  We could
> >>> advise change, but it would be wasted effort.
> >>>
> >>> In contrast, the mailing list folks are saying that it's DMARC that
> >>> came later, that is being deployed incorrectly, and that must change.
> >>> Clearly, those who find benefit from strict DMARC policies disagree,
> >>> and they've said clearly that they won't change.  And again, we're not
> >>> the police.  We could put, in the standards track version of DMARC,
> >>> that p=reject MUST be used ONLY for transactional mail, which MUST be
> >>> isolated from mail that might go to mailing lists (worded better than
> >>> that, but we all know what I mean here).  It would be shouting at the
> >>> wind.
> >>>
> >>> We do the best we can to write reasonable standards and to give
> >>> reasonable advice about using them.  We can identify problems and
> >>> write our best advice about how to avoid/mitigate them.  Beyond
> >>> that....
> >>>
> >>> Barry
> >>>
> >>> On Sun, Oct 10, 2021 at 1:13 PM Douglas Foster
> >>> <[e-mail]> wrote:
> >>> >
> >>> > This is disappointing and problematic.
> >>> >
> >>> > So, AOL publishes a policy which says that they do not want their
> >>> outbound messages altered in transit, and implements filtering which
> >>> demonstrates that they do not want inbound messages modified in
> transit.
> >>> >
> >>> > In opposition, we have mailing lists that claim an unrestricted
> >>> right to
> >>> alter messages in transit.
> >>> >
> >>> > What is the justification for IETF to be involved with developing
> >>> strategies to undermine AOL's interests in favor of a Mailing List's
> >>> interests?   It is capricious and misleading for you to say that we
> >>> are not
> >>> being the Internet Police, because we are clearly taking sides.  If
> >>> we are
> >>> not the Police, then apparently we are the Internet Smuggling Cartel.
> >>> This just looks wrong.
> >>> >
> >>> > Doug Foster
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > On Sat, Oct 9, 2021 at 6:09 PM Scott Kitterman <[e-mail]
> >
> >>> wrote:
> >>> >>
> >>> >> Technically it's pretty easy to set up a mailing list which doesn't
> >>> modify the message in ways likely to make DKIM fail.  Almost no one
> >>> bothers
> >>> to do so despite pressures resulting from widespread use of DMARC
> >>> p=reject.
> >>> >>
> >>> >> Operators do not need to justify anything to us.  We are not the
> >>> internet police.
> >>> >>
> >>> >> For our purposes it's enough to know that they do and there's no
> >>> evidence that it's likely to change.
> >>> >>
> >>> >> Scott K
> >>> >>
> >>> >> On October 9, 2021 7:39:36 PM UTC, Douglas Foster <
> >>> [e-mail]> wrote:
> >>> >> >I would be pleased to see a document which explains why lists
> >>> MUST or
> >>> >> >SHOULD alter content.    After more than 2 years following this
> >>> discussion,
> >>> >> >no reason for this practice has ever been documented.
> >>> >> >
> >>> >> >Content changes would be easier to justify if subscribers granted
> >>> >> >authorization to modify as part of the subscription process.   But
> >>> there
> >>> >> >was not informed consent when I joined this list, so I doubt that
> >>> informed
> >>> >> >consent occurs on other lists either.
> >>> >> >
> >>> >> >What if, after reviewing the SHOULD list, an organization says
> >>> "That's
> >>> >> >interesting but unconvincing.   Please send messages to our domain
> >>> without
> >>> >> >alteration?"   Are lists equipped to give participants what they
> >>> want,
> >>> or
> >>> >> >not?
> >>> >> >
> >>> >> >Doug
> >>> >> >
> >>> >> >On Thu, Oct 7, 2021 at 9:58 AM Barry Leiba <
> [e-mail]>
> >>> wrote:
> >>> >> >
> >>> >> >> Just on one point, for us to consider:
> >>> >> >>
> >>> >> >> > Personally, I think mailing lists changing From has horrible UX
> >>> and I
> >>> >> >> don't
> >>> >> >> > really think anyone disagrees.  It's only advantages are that
> >>> it's
> >>> >> >> relatively
> >>> >> >> > easy to implement in a Mailing List Manager (MLM) and it
> >>> solves the
> >>> >> >> entire
> >>> >> >> > DMARC problem for a specific mailing list without needing
> anyone
> >>> else to
> >>> >> >> change
> >>> >> >> > anything.  I understand the appeal.
> >>> >> >>
> >>> >> >> I think Scott is right that we all agree that rewriting From
> >>> mitigates
> >>> >> >> problems that mailing lists have with DMARC, but at a significant
> >>> cost
> >>> >> >> in usability.
> >>> >> >>
> >>> >> >> I think it would be bad to publish From-rewriting as a standard.
> >>> >> >>
> >>> >> >> But here:  I think it is reasonable, perhaps advisable, to
> >>> >> >> informationally document From-rewriting as a mechanism that is in
> >>> use,
> >>> >> >> and to include in that documentation a clear exposition of the
> >>> >> >> problems that it causes.  Why not get those horrible UX issues
> >>> down
> >>> on
> >>> >> >> paper so that when someone decides to deploy it they are better
> >>> >> >> informed?  Perhaps we can lead people to take steps to reduce
> >>> the UX
> >>> >> >> challenges (for example, rewriting the way the IETF is doing it
> at
> >>> >> >> least addresses the issue of knowing who sent the message, and
> >>> how to
> >>> >> >> reply to the actual sender, as compared to a rewrite directly
> >>> to the
> >>> >> >> mailing list address).
> >>> >> >>
> >>> >> >> Doesn't that make sense?
> >>> >> >>
> >>> >> >> Barry
> >>> >> >>
> >>> >> >> _______________________________________________
> >>> >> >> dmarc mailing list
> >>> >> >> [e-mail]
> >>> >> >> https://www.ietf.org/mailman/listinfo/dmarc
> >>> >> >>
> >>> >>
> >>> >> _______________________________________________
> >>> >> dmarc mailing list
> >>> >> [e-mail]
> >>> >> https://www.ietf.org/mailman/listinfo/dmarc
> >>> >
> >>> > _______________________________________________
> >>> > dmarc mailing list
> >>> > [e-mail]
> >>> > https://www.ietf.org/mailman/listinfo/dmarc
> >>>
> >>
> >>
> >> _______________________________________________
> >> dmarc mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dmarc
> >>
> >
> >
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>