Subject: [dmarc-ietf] thoughts re. DMARC impacts

From: Miles Fidelman <[email-masked]>
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

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 27 Oct 2014 20:51:57 -0400

Didn't actually mean to send this to the dmarc-ietf list - but, since I 
did... any mailing list developers out there who want to play?

Miles Fidelman

Miles Fidelman wrote:
> 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....").
>
> 16-year-old document defines the List-* headers.  Say by adding a 
> couple of headers along the lines of:
> implemented as part of the process.  (Can you say, "rough consensus 
> and running code?")
>
> be involved from the Sympa community, and/or from the other mailing 
> list software communities?
>

---

From: Brandon Long <[email-masked]>
Date: Mon, 27 Oct 2014 17:58:00 -0700

Some predecessors: http://cr.yp.to/proto/replyto.html

Mail-Reply-To and Mail-Followup-To.  We implemented Mail-Reply-To at
eGroups/YGroups, iirc, but looks like we didn't do it at Google Groups..

Implementation is obviously trivial, do we actually think that list-reply
would result any time soon?

We also considered adding a header/footer to the message with the
poster/author email address in it.

Brandon

On Mon, Oct 27, 2014 at 5:45 PM, Miles Fidelman <[email-masked]>
wrote:

> easier, as list managers - sort of the way that NAT has been dealing with
> IPv4 address exhaustion, while we wait for IPv6 to happen.
>
> 16-year-old document defines the List-* headers.  Say by adding a couple of
> headers along the lines of:
> 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)
> 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?")
>
> 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?
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 27 Oct 2014 21:02:47 -0400

Kind of depends.  Agreement on two header fields, by the developers of 
Mailman and Sympa - yes, that could happen overnight if the right few 
people agree.

Miles

Brandon Long wrote:
> Implementation is obviously trivial, do we actually think that 
> list-reply would result any time soon?
>
> On Mon, Oct 27, 2014 at 5:45 PM, Miles Fidelman 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Folks,
>
>     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....").
>
>     - the ietf-dmarc working group is charted to "enhance DMARC" -
>     dealing with its impacts is not really the focus
>     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.
>
>     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)
>     identifying, and presenting reply options (maybe leading to "reply
>     to list" and "reply to author" buttons starting to show up on
>     toolbars)
>     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?
>
>     [email-masked] <mailto:[email-masked]>

---

From: [email-masked]
Date: Mon, 27 Oct 2014 17:47:16 -0700 (PDT)

> Folks,

<co-chair hat on>

> with its impacts is not really the focus

Please reread the charter. This is not at all what it says.

Among other things, the charter states that:

  The working group will specify mechanisms for reducing or eliminating
  the DMARC's effects on indirect mail flows, including deployed
  behaviors of many different intermediaries, such as mailing list
  managers, automated mailbox forwarding services, and MTAs that
  perform enhanced message handling that results in message
  modification. 

I don't see that as in any way in line with your assertion that the wg is not
chartered to deal with the impact of DMARC. In fact it seems to be exactly the
opposite. And in particular, nowhere in that paragraph is there any requirement
that this must necessarily be done by "enhancing DMARC".

> - folks want a general purpose solution

Of course they do. Unfortunately, people's desires do not magic such a solution
into existence. And if someone has described a viable and deployable
general-purpose solution, I must have missed it. So we are left with
consideration of various partial solutions and compromises.

> be involved from the Sympa community, and/or from the other mailing list

What in the charter makes you think such a draft would be in any way
incompatible with being a product of this group? Indeed, this fits quite nicely
into phase I, which is, you know, what we're supposed to be working on now. (As
opposed to phase II, which is where we will start looking at possible changes
to DMARC itself.)

Of course the fact that this fits within our charter doesn't mean there's
consensus on this particular approach. But to that end, if you want to get
people on board, might I suggest that rather than in effect asking people to
abandon the wg effort for something else, that you instead do what countless
others have done before you, and start by writing a draft that describes your
proposal in detail so participants can assess it?

				Ned

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 27 Oct 2014 21:26:35 -0400

See below....

> that this must necessarily be done by "enhancing DMARC".

Ok... good to hear.  I was inferring from the responses so far, and 
probably read the charter just a bit too quickly.
> consideration of various partial solutions and compromises.

Agreed - hence my preference for dealing with low hanging fruit.

> proposal in detail so participants can assess it?

Well... love to.  Kind of why I posted the question to the sympa list - 
I'd like to see how the concept floats with users/developers of a 
specific list manager (the one I use, obviously), and the one that 
reacted quickest with a patch.

I would still like to have some guidance as to the form and process - 
specifically since I'm essentially proposing to add a paragraph or two 
to an existing RFC.  What would be the best way to frame that?

Cheers,

Miles Fidelman