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
<[email protected]> 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 <[email protected]>
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 <
[email protected]> 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 <[email protected]>
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
>> >> [email protected]
>> >> https://www.ietf.org/mailman/listinfo/dmarc
>> >>
>>
>> _______________________________________________
>> dmarc mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/dmarc
>
> _______________________________________________
> dmarc mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmarc
