On Thursday, October 7, 2021 5:37:43 AM EDT Alessandro Vesely wrote:
> On Thu 07/Oct/2021 09:48:12 +0200 Laura Atkins wrote:
> >> On 7 Oct 2021, at 01:08, Scott Kitterman <[email protected]> wrote:
> >> 
> >> On October 6, 2021 11:37:26 PM UTC, John Levine <[email protected]> wrote:
> >>> It appears that Alessandro Vesely  <[email protected]> said:
> >>>> Doug's emphasis on aliases tends to give that impression.  Otherwise it
> >>>> can
> >>>> finally be a much needed attempt at formalizing the old, known From:
> >>>> rewriting.>>> 
> >>> To point out what I would think is obvious, formalizing a bad idea
> >>> doesn't make it any less bad an idea.
> >> 
> >> Agreed.
> >> 
> >> To give a specific example:
> >> 
> >> The mobile mail client I use (K-9 Mail) will either display friendly name
> >> or email address.  Due to the compact user interface, both isn't an
> >> option.
> >> 
> >> There's one Google Group I'm a member of with a number of users with
> >> DMARC p=reject domains, so their addresses are rewritten to the list
> >> address.  As a result, when people don't bother to say who they are in a
> >> message, I end up digging through the message header to find out who
> >> wrote it.
> >> 
> >> This is not a good user experience.  It's not salvageable.
> > 
> > Agreed. The other day I was trying to refer work to a colleague I’ve only
> > really interacted with on a professional mailing list. Due to header
> > re-writing and no email address in any other place in the email, I didn’t
> > actually have a direct email address for her.
> > 
> > It’s also become almost impossible to search for messages from some people
> > in some clients because you can’t search on from: address any longer.
> > 
> > These are usability and UX problems induced by DMARC.
> 
> What do we want to do, then?
> 
> Let's exclude, for the sake of reality, both dropping DMARC altogether and
> stopping to use mailing lists.  What realistic possibilities are there?
> 
> ARC, when 60% of receivers will have (reliably) implemented it?  This is not
> more realistic than the Vernon's kook I cited upstream.
> 
> After careful consideration, header re-writing doesn't have to imply no
> email address in any other place.  Savvy lists save the original From: in
> Reply-To: or Cc:.  If some lists don't do that, perhaps specifying how to
> re-write From: can improve that condition, no?  When everything is done
> well, it is possible to unmunge From: and fully recover pre-DMARC
> functionality while still enjoying DMARC checks.
> 
> 
> Do you see other possibilities?

I don't think there is a single "solution".  If there was, we would have 
achieved some kind of consensus around it.  There is a mix of different things 
which can be done to mitigate the impact of DMARC on mailing lists.

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.

The From field and its related semantics are nearing a half-century in age.  
It's out of our charter's scope to try and change them and even if we could, I 
don't think we should try.  I doubt anyone can anticipate the unintended 
consequences of doing so.

I'm also extremely skeptical of solutions that require user interface changes.  
If reading email "correctly" requires training a non-technical end user, we've 
lost.

Some of you will recall what we did to address the SPF "forwarding problem" in 
Appendix D of RFC 7208.  I suspect that a compendium of solutions like this is 
the best way forward, although I doubt that's the right way to structure it.  
Note that this appendix didn't standardize anything.  For problems that don't 
have a single, or even small, solution set this is essential.

Here's a start on some ideas (none new):

Things a MLM can do on their own:

1.  Don't modify messages in ways that break DKIM signatures
2.  Don't accept messages for delivery by the list from p=reject domains
3.  Rewrite From to avoid negative DMARC assessments (I seriously dislike 
this, but let's not pretend it's going to go away)

Things a MLM can do to support receivers:

1.  Add and DKIM sign List-* header fields
2.  Exclude mail originally from p=reject domains from bounce counts related 
to unsubscribing bouncing list participants
3.  ARC

Things receivers can do
1.  Don't reject based on DMARC fail
2.  ....

I'm out of time, but something like that which defines the solution space 
rather then trying to specify THE solution is probably the only path forward.

Scott K








_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to