My own feeling is that lists should have a service agreement / disclosure
statement that says,
"We will modify your text in {manner} for {reason}.".
"We will do {feature} to reduce the risk of unwanted or dangerous list
posts".
"We will do {feature} to minimize use of off-topic posts. The following
behaviors will ..."
"Your email address will be released to all list participants. This list
does not condone use of list addresses for non-lust purposes, but cannot
prevent that from occurring. Consider this possibility when choosing an
address to use for list participation."
My only point of reference is this list, and I am not happy that such a
disclosure was not provided at sign-up.
DF
On Wed, Apr 12, 2023, 2:16 PM Murray S. Kucherawy <[email protected]>
wrote:
> I've been thinking about the point a few people have made now that DMARC
> has two actors that cause the problem: Those who "blindly" apply
> "p=reject", and those who advertise "p=reject". You do, indeed, need two
> to tango; enforcement doesn't happen without an advertising sender and a
> participating receiver. Maybe any "MUST NOT" advice we provide needs to
> cover both ends. We need to be careful about admonishing participating
> receivers though. What would we say to them about how to be selective in
> application?
>
> We've talked about having signal from the enforcing receivers back to the
> MLM that the bounce occurred because of DMARC, but we haven't seen much
> uptake of that idea for various reasons.
>
> I've also been thinking about ways to push the burden back on the
> advertisers. Imagine we have some kind of signaling mechanism that MLMs
> can take advantage of indicating to them that the author is using a strong
> policy, and so it would be possibly a bad idea for the MLM to accept,
> mutate, and re-send this message. This could be a header field or an SMTP
> extension (though the latter is complex to get right in a store-and-forward
> system). The MLM can then decide if it is willing to pass the message
> unmodified to the list, or reject it with an error like "The policies of
> this list require modification of your message, which violates your
> domain's apparent policy. Your submission therefore cannot be accepted.
> Please contact your support organization for further assistance." There's
> never an opportunity for the collateral bounce to occur if the message is
> never distributed, and the author domain has to either soften its policy or
> separate its regular users from its transactional stuff somehow.
>
> This avoids the "collateral" and "persistent" damage issues I raised in a
> separate post. It still requires the MLMs to do something new, but avoids
> the need to implement any of a variety of unsavory mutations. MLMs could
> also determine this by querying the current DMARC policy of the author's
> domain, to be sure, so it's a choice between MLMs looking for a header
> field (which they already know how to do) or becoming DNS-aware (relatively
> simple, but pulls in some complexities and dependencies they may not want).
>
> -MSK, trying to be useful here
> _______________________________________________
> dmarc mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmarc
>
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
