Skip to Content.
Sympa Menu

en - [sympa-users] thoughts re. DMARC impacts

Subject: The mailing list for listmasters using Sympa

List archive

Chronological Thread  
  • From: Miles Fidelman <address@concealed>
  • To: "address@concealed" <address@concealed>, "address@concealed" <address@concealed>
  • Subject: [sympa-users] thoughts re. DMARC impacts
  • Date: Mon, 27 Oct 2014 20:45:32 -0400

Folks,

Many of us just had to deal with the impacts of DMARC on our lists.

In the aftermath, I've been participating on the dmarc-ietf email list - trying to discuss ways to "fix DMARC" to better coexist with lists and other 3rd-party services (like "send this article to....").

Unfortunately, it seems like the discussion is bogged down in two regards:
- the ietf-dmarc working group is charted to "enhance DMARC" - dealing with its impacts is not really the focus
- folks want a general purpose solution

Personally, I'd like to see a short-term solution to make our lives easier, as list managers - sort of the way that NAT has been dealing with IPv4 address exhaustion, while we wait for IPv6 to happen.

I've been thinking along the lines of an update to RFC2369 - the 16-year-old document defines the List-* headers. Say by adding a couple of headers along the lines of:
List-Original-Author: <the original author>
List-Original-Reply-To: <the original message's Reply-To>
List-Reply-To: <the list-specific reply-to - either author of list>

Seems to me that this would:
1. give us a standard way to find the original author (and for HTML mail, to reply by clicking on a mailto: URL in the header)
2. provide standardized information that could be used by MUAs for identifying, and presenting reply options (maybe leading to "reply to list" and "reply to author" buttons starting to show up on toolbars)
3. set the stage for adding some authentication mechanisms that accomplish what DMARC is intended to do (e.g. by adding a few more headers that cryptographically authenticate the new List- headers and bind them to the message body)

It strikes me that this might proceed rather quickly, if incorporated into an RFC co-authored and submitted by folks from the mailing list software community (i.e., the folks who'd write the patches to Sympa, Mailman, ezmlm, etc) - particularly if some running code were to be implemented as part of the process. (Can you say, "rough consensus and running code?")

Reactions? Anybody want to collaborate on a draft RFC for submission through the independent submissions path? Any thoughts on who needs to be involved from the Sympa community, and/or from the other mailing list software communities?

Miles Fidelman (a frustrated sympa administrator)





--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra




Archive powered by MHonArc 2.6.19+.

Top of Page