Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage

From: Miles Fidelman <[email-masked]>
Date: Fri, 24 Oct 2014 10:54:22 -0400

Can we step back from the weeds, for a second and talk practicalities?

The suggestion that started this thread was to add a List-* header to 
indicate the original author of a mailing list posting - in order to, 
hopefully, lead to MUAs that make it easier to reply to that original 
author.

The discussion has quickly wandered into discussion that seems to be 
very far from the original suggestion.

Speaking as one who both is on a bunch of mailing lists, and who hosts a 
bunch of mailing lists, the suggestion strikes me as almost a 
no-brainer.  It solves a very big problem, in a very straightforward way.

1. Right now, for mailing lists that munge DMARC damage (pretty much all 
lists at this point, as far as I can tell), and depending on MUA, about 
the only way to reply to the original author of a message is to actually 
find the original author's address and manually cut and paste it into 
the To: field of your reply.  Not all that easy for non-technical folk 
(at least based on support questions I get).

2. RFC2369 - 16 years old now - specifies a short list of List-*headers 
that are incredibly useful for things like finding list archives, 
finding list help, unsubscribing, etc.
- not all MUAs support them directly, but,
- they're easy to find, simply by looking in the headers
- in most GUI-based MUAs, they're easy to use - simply click on an 
exposed URL (how I typically get to the archive of this list, for example)
- by being standardized, it makes it easier, and hence more likely, that 
MUA developers might start adding "reply to list" and "reply to author" 
buttons in their interfaces

3. More important, perhaps, is that if we simply picked a name, and 
standardized a "List-original-author:" header - it would allow the SMALL 
NUMBER of mailing list software developers (mailman, sympa, ezmlm, a few 
more) to support that header, probably in the same code module where 
they already support the existing RFC239 headers.  I expect that within 
a week of agreeing on a field name, all the major mailing list managers 
would have patches written.

Unless I'm missing something, there's no downside.

Which leads to the purely procedural question:
What would be the most straightforward process for writing and 
promulgating an RFC that essentially updates RFC2369 by adding one 
section that defines an additional header to the current list of List-* 
headers?

Miles Fidelman

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

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Oct 2014 11:24:15 -0400

Adding a new List-XXXXX for the original author is based on the 
premise that the 5322.From header will therefore be open for destruction.

That means there is a new dependency on future verifiers and MUAs to 
support the List-XXXXXX header in order to make a "tie-in," hopefully, 
verifiable, which means a LOOKUP is necessary anyway.

A POLICY lookup is needed no matter what -- in order to maintain some 
sort of security control.  If its done open ended, it will be 
leveraged and abuse across other areas -- we will see more this 
"List-XXXXX" in mail in order to give the "illusion" that the mail is 
ok because some reputable "List" did it.

If the DOMAIN policy exposed a logic that says:

    "It is OK for LIST ABC to rewrite our mail and add LIST-XXXXX"

than I can better support such ideas. But it needs to come from the 
domain, otherwise we have a major mail security loophole.

--
HLS

On 10/24/2014 10:54 AM, Miles Fidelman wrote:
> Speaking as one who both is on a bunch of mailing lists, and who hosts
> a bunch of mailing lists, the suggestion strikes me as almost a
> 1. Right now, for mailing lists that munge DMARC damage (pretty much
> all lists at this point, as far as I can tell), and depending on MUA,
> about the only way to reply to the original author of a message is to
> actually find the original author's address and manually cut and paste
> it into the To: field of your reply.  Not all that easy for
> non-technical folk (at least based on support questions I get).
>
> 2. RFC2369 - 16 years old now - specifies a short list of
> List-*headers that are incredibly useful for things like finding list
> archives, finding list help, unsubscribing, etc.
> - by being standardized, it makes it easier, and hence more likely,
> that MUA developers might start adding "reply to list" and "reply to
> author" buttons in their interfaces
>
> standardized a "List-original-author:" header - it would allow the
> SMALL NUMBER of mailing list software developers (mailman, sympa,
> ezmlm, a few more) to support that header, probably in the same code
> module where they already support the existing RFC239 headers.  I
> expect that within a week of agreeing on a field name, all the major
> mailing list managers would have patches written.
>
> section that defines an additional header to the current list of
> List-* headers?
>
> Miles Fidelman
>
>

-- 
HLS

---

From: Steve Atkins <[email-masked]>
Date: Fri, 24 Oct 2014 18:49:11 -0400

On Oct 24, 2014, at 10:54 AM, Miles Fidelman <[email-masked]> wrote:

> The suggestion that started this thread was to add a List-* header to indicate the original author of a mailing list posting - in order to, hopefully, lead to MUAs that make it easier to reply to that original author.
> 
> The discussion has quickly wandered into discussion that seems to be very far from the original suggestion.
> 
> Speaking as one who both is on a bunch of mailing lists, and who hosts a bunch of mailing lists, the suggestion strikes me as almost a no-brainer.  It solves a very big problem, in a very straightforward way.
> 
> 1. Right now, for mailing lists that munge DMARC damage (pretty much all lists at this point, as far as I can tell), and depending on MUA, about the only way to reply to the original author of a message is to actually find the original author's address and manually cut and paste it into the To: field of your reply.  Not all that easy for non-technical folk (at least based on support questions I get).
> 
> 2. RFC2369 - 16 years old now - specifies a short list of List-*headers that are incredibly useful for things like finding list archives, finding list help, unsubscribing, etc.
> - in most GUI-based MUAs, they're easy to use - simply click on an exposed URL (how I typically get to the archive of this list, for example)
> - by being standardized, it makes it easier, and hence more likely, that MUA developers might start adding "reply to list" and "reply to author" buttons in their interfaces
> 
> 3. More important, perhaps, is that if we simply picked a name, and standardized a "List-original-author:" header - it would allow the SMALL NUMBER of mailing list software developers (mailman, sympa, ezmlm, a few more) to support that header, probably in the same code module where they already support the existing RFC239 headers.  I expect that within a week of agreeing on a field name, all the major mailing list managers would have patches written.
> 

If I'm understanding you, your intent is to define (for the subset of email that is received from mailing lists) the "List-original-author:" field as containing the author of the message, i.e. the mailbox of the person or system that was responsible for writing the message, while the "From:" field would specify the mailbox of the mailing list - the agent responsible for the actual transmission of the message?

And there's a hope that that would lead to MUA developers making the List-original-author field available to users - to filter by, to use as a target to "reply to author", and to be visible to identify the original sender?

> What would be the most straightforward process for writing and promulgating an RFC that essentially updates RFC2369 by adding one section that defines an additional header to the current list of List-* headers?

Cheers,
  Steve

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 24 Oct 2014 19:00:03 -0400

> If I'm understanding you, your intent is to define (for the subset of email that is received from mailing lists) the "List-original-author:" field as containing the author of the message, i.e. the…

Well, my proposal is to be agnostic about the From: field - what it's 
supposed to be is well defined, despite various mailing list packages 
munging it in non-standard ways, to get list traffic past restrictive 
DMARC sender alignment policies.  At the moment, different list managers 
are implementing various different From: re-writing options (e.g., From: 
<original author> by way of <list>; rewriting to the list address, 
etc.).  I propose that we don't touch the From: field.

What I propose is ADDING, a new List-original author: field that 
provides an unequivocal place find the (avowed) original email, to be 
written by the mailing list software.

That leaves the list software free to use the Reply-To: field as 
originally intended - something that can be set by list policy to either 
the author or the list, as configured for the list in question.

Though.. it might make some sense to also define a couple of more fields:
List-reply-to:  (the reply to address as set by the list manager)
List-original-reply-to: (the reply to address as set by the original author)

> And there's a hope that that would lead to MUA developers making the List-original-author field available to users - to filter by, to use as a target to "reply to author", and to be visible to iden…

Exactly! And to reduce the need to play with and overload the semantics 
of the From: and Reply-To: fields.

>> What would be the most straightforward process for writing and promulgating an RFC that essentially updates RFC2369 by adding one section that defines an additional header to the current list of L…

Miles

---

From: Douglas Otis <[email-masked]>
Date: Fri, 24 Oct 2014 16:19:35 -0700

> The suggestion that started this thread was to add a List-* header to indicate the original author of a mailing list posting - in order to, hopefully, lead to MUAs that make it easier to reply to t…

Dear Miles, 

DMARC policy affects any message where the From header field domain does not align with either an SPF or DKIM domain.

The problem that needs to be addressed relates to all possible third-party related services, which includes but is not limited to use of discussion lists.  There are many other equally legitimate examples of valid third-party messages (third-party defined as when the From and DKIM or SPF domains do not align). 

> Speaking as one who both is on a bunch of mailing lists, and who hosts a bunch of mailing lists, the suggestion strikes me as almost a no-brainer.  It solves a very big problem, in a very straightf…

Modifying From header fields destroys functionality and dangerously expects users to "repair" the damage caused, such as responding to messages in their spam folder or modifying return addresses by hand.

> - by being standardized, it makes it easier, and hence more likely, that MUA developers might start adding "reply to list" and "reply to author" buttons in their interfaces

How is a List-* header better than permitting exceptions for specific forms of group syntax?  In that way, From header field function can be retained while avoiding possible deceptions caused by normally unseen header fields.  The DMARC goal was to ensure recipients are aware of possible misdirection.  TPA-Label is more secure because it requires DMARC domains to make specific exceptions based on third-party services used by their senders and NOTHING ELSE NEEDS TO CHANGE.  A specific group syntax represents a less secure "least effort" alternative, but is still better than what you're suggesting.

> Unless I'm missing something, there's no downside.

There are a few:
1) The problem is not limited to just mailing-lists so it would be better to define a general purpose header field to mitigate DMARC policy disruptions.
2) Use of a new header field creates another problem in that they would not be seen by recipients.

Ensuring an origination header can be seen is better solved by making specific exceptions for valid use of From header field group syntax permitted by RFC6854 which amended RFC5322.

> What would be the most straightforward process for writing and promulgating an RFC that essentially updates RFC2369 by adding one section that defines an additional header to the current list of Li…

It is not RFC2369 that needs to change.  DMARC needs to either permit exceptions based on a defined group syntax or have DMARC allow an explicit authorization scheme.  Otherwise expect ad hoc hacks to create an even more pernicious spoofing problem.  In my view, such results would be a major downside.

Regards,
Douglas Otis

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 27 Oct 2014 12:36:43 +0100

On Sat 25/Oct/2014 01:00:03 +0200 Miles Fidelman wrote:
> Steve Atkins wrote:
>> On Oct 24, 2014, at 10:54 AM, Miles Fidelman wrote:
>>
>>> 1. Right now, for mailing lists that munge DMARC damage (pretty
>>> much all lists at this point, as far as I can tell), and depending
>>> on MUA, about the only way to reply to the original author of a
>>> message is to actually find the original author's address and
>>> manually cut and paste it into the To: field of your reply.  Not
>>> all that easy for non-technical folk (at least based on support
>>> questions I get).

Yes, except some lists didn't care at all (lucky them).

>>> List-*headers that are incredibly useful for things like finding
>>> list archives, finding list help, unsubscribing, etc.
>>>   that MUA developers might start adding "reply to list" and "reply
>>>   to author" buttons in their interfaces

Hm... the resulting likelihood would still be very low, IMHO.

>>> ezmlm, a few more) to support that header, probably in the same
>>> code module where they already support the existing RFC239
>>> headers.  I expect that within a week of agreeing on a field name,
>>> all the major mailing list managers would have patches written.
>>>
>> If I'm understanding you, your intent is to define (for the subset
>> of email that is received from mailing lists) the
>> "List-original-author:" field as containing the author of the
>> message, i.e. the mailbox of the person or system that was
>> responsible for writing the message, while the "From:" field would
>> specify the mailbox of the mailing list - the agent responsible for
>> the actual transmission of the message?
>
> DMARC sender alignment policies.  At the moment, different list
> managers are implementing various different From: re-writing options
> (e.g., From: <original author> by way of <list>; rewriting to the list
> address, etc.).  I propose that we don't touch the From: field.
>

That's very equivocal.  It goes without saying that From: is going to 
be munged, so why don't we say it explicitly?  In addition, if we 
propose a simple munging scheme --one that can be easily undone 
manually-- we provide users with the ability to reply to authors even 
if their MUA doesn't recognize the new field.  Consider:

    From: John Doe <[email-masked]>
    List-Original-Author:  John Doe <[email-masked]>

We can even set up a dummy server which always replies:

    551 User not local; please try <[email-masked]>

The RFC ought to also tell that that is a temporary solution, until 
general solutions for every indirect flow case are agreed upon.

> originally intended - something that can be set by list policy to
> either the author or the list, as configured for the list in question.

Yes.

> List-original-reply-to: (the reply to address as set by the original

Please, no.

jm2c

---

From: Douglas Otis <[email-masked]>
Date: Mon, 27 Oct 2014 09:47:49 -0700

On Oct 27, 2014, at 4:36 AM, Alessandro Vesely <[email-masked]> wrote:

> That's very equivocal.  It goes without saying that From: is going to be munged, so why don't we say it explicitly?  In addition, if we propose a simple munging scheme --one that can be easily undone manually-- we provide users with the ability to reply to authors even if their MUA doesn't recognize the new field.  Consider:
> 

Dear Alessandro,

DMARC affects many third-party services, only one being a mailing list.  Rather than munging From header fields and expect users to change it, especially when dealing with different languages, a more concise and compliant scheme would be to have DMARC adopt specific policy exceptions for group syntax.  Such exceptions would then permit third-party services a means to modify their From in a manner not requiring hand editing and yet be DMARC compliant.  Hand editing defeats protections due to the many diverse ways of saying "Do not trust this From"  as would defining an unseen replacement for the From header field to stand in its place.  In addition, only group syntax ensures the From header field being relied upon remains visible.  The From header field being visible is a key aspect of DMARC.  

It still makes far more sense for DMARC to declare a group such as ☠: or DMARC-UNKNOWN:.  Group syntax would offer a fairly uniform way for any third-party service to side-set DMARC policy restrictions. It would also require faster adoption of code able to handle group syntax, which should be seen as a win in both camps.

Regards,
Douglas Otis

---

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

> The problem that needs to be addressed relates to all possible third-party related services, which includes but is not limited to use of discussion lists.  There are many other equally legitimate e…

Seems to me that this is a case of the perfect being the enemy of the good.

What say we try to deal with three issues separately:

1. short-term standardization of measures that people are taking to deal 
with the impact of DMARC on specific classes of breakage - in 
particular, dealing with mailing list breakage

2. more general mechanisms for dealing with the impacts of DMARC

3. "enhancing" or "fixing" DMARC

Right now, the most pressing issue is that a number of large players 
have imposed DMARC on the rest of the net.  As a matter of policy, DMARC 
expects receiving MTAs to impose a sender's policy - whereas the 
traditional mechanism for dealing with authentication is for receiving 
MTAs to make their own decisions based on multiple inputs.  And, in the 
process, the DMARC approach essentially tells intermediate services to 
go screw.

The Internet is reacting as it traditionally does - it's routing around 
breakage.  Unfortunately, it's doing so in lots of different ways, that 
make life rather difficult.

Somehow, given the way that DMARC came to be, and particularly the way 
several large players have chosen to use p=reject, I would say that 
"fixing" DMARC is a long-term proposition, at best (sort of like IPv6).

What say we spend some of our efforts on dealing with narrow, and 
tractable issues.  Such as my proposal re. mailing lists, by a 
straightforward extension to an existing practice (the List-* headers).

Or.. how about a proposal for a somewhat more general mechanism (see below).
> Modifying From header fields destroys functionality and dangerously expects users to "repair" the damage caused, such as responding to messages in their spam folder or modifying return addresses by…

This is going to happen, no matter what.  How do we mitigate the 
damage?  (By analogy - NAT was a short term solution to the long-delayed 
adoption of IPv6 - which we're still waiting for. Let's deal with what 
we can deal with, while sorting out larger issues.)
> Ensuring an origination header can be seen is better solved by making specific exceptions for valid use of From header field group syntax permitted by RFC6854 which amended RFC5322.

Can you make a clear proposal?

For the case of lists, the semantics and syntactic of how to use From: 
and Reply-To: have never been quite clear, and DMARC simply makes things 
murkier.  It strikes me that adding a couple of List-* headers clarifies 
things all around.  Adding some authentication mechanisms, through 
modifications to DMARC, can come later.

If you have a more general case solution - that doesn't require 
cooperation of Yahoo et al, let's see it!

> It is not RFC2369 that needs to change.  DMARC needs to either permit exceptions based on a defined group syntax or have DMARC allow an explicit authorization scheme.  Otherwise expect ad hoc hacks…

I'd argue that point.  At this point, the community hasn't accepted the 
DMARC approach to imposing sender authentication - rather, a popular 
reaction has been to ignore DMARC policies.  I suggest that this is a 
situation that will continue.

Miles Fidelman

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 28 Oct 2014 14:22:28 +0900

Douglas Otis writes:

 > Modifying From header fields destroys functionality and dangerously
 > expects users to "repair" the damage caused, such as responding to
 > messages in their spam folder

Please stop using "user looks in spam folder" as an example.[1][2]  Users
*should* look in their spam folders, at least if they have well-
managed spam filters.  Well-managed spam filters provide spam folders
not because they think users want to look at spam, but because they
know that there *will* be false positives.  The filter's goal is to
keep that folder as empty as possible, but perfection is unachievable.

For example, my car dealer's messages occasionally (but more than
once!) ended up in the spam folder because they *are* spammy (one
particularly egregious one got 13 stars when I ran it through
SpamAssassin, although evidently Gmail didn't think it bad enough to
discard even though it did put it in the spam folder), but they're not
UCE by definition because I opted in to that list properly.

Footnotes: 
[1]  I consider this an example of the technical fallacy: "security
problems can be solved with sufficiently advanced technology."  I
don't trust people who advocate it, however technically proficient
they may be, to manage or design security systems.

[2]  It's specious here, anyway.  Modifying "From" should make the
message *less* likely to end up in the spambucket, since there will be
a From-aligned, valid DKIM signature (at least in the case of a
well-managed indirect mailer).  The problem is that it's likely to
make the user vulnerable to various forms of social engineering that
emulate this kind of From-munging.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 28 Oct 2014 14:51:03 +0900

> >> 3. More important, perhaps, is that if we simply picked a name,
 > >>    and standardized a "List-original-author:" header - it would
 > >>    allow the SMALL NUMBER of mailing list software developers
 > >>    (mailman, sympa, ezmlm, a few more) to support that header,
 > >>    probably in the same code module where they already support
 > >>    the existing RFC239 headers.  I expect that within a week of
 > >>    agreeing on a field name, all the major mailing list managers

Written, yes.  Accepted, maybe.  Mailman is unlikely to accept such a
thing without a fight.  See reasons 1-4 below.  Other reasons have
been mentioned, but these are the ones that get me hot under the collar.

 > >> Unless I'm missing something, there's no downside.

1.  It is insufficiently general (doesn't appear to apply to non-list
    use cases) and therefore would induce unnecessary complexity or
    uneasiness among standards-conforming admins who would be queasy
    about using a List-* field for a non-list use case.

2.  Unlike the RFC 2369 and 2919 fields, which add useful information
    to the message, without changing existing information, this field
    is useless unless From is munged, which is nonconforming behavior.

3.  To make it conformant, RFC 5322 would need to be updated.

 > etc.).  I propose that we don't touch the From: field.

Well, no, you can't really do that.  See 2 and 3 above.

 > the author or the list, as configured for the list in question.

You misunderstand RFC 5322 and all of its predecessors.  Use of
Reply-To by discussion lists is non-conformant, although common.  In
case of announce lists DMARC should not be a problem (unless they
suffer from a non-list-related indirect mail issue).

I have a old proposal for a List-Reply-Preference header, which allows
the list to specify whether it prefers the default reply function to
go to List or Author (never made it to an IETF draft due to Antarctic
response from MUA authors).  Maybe I could dust that off (but it would
go through apps-wg, I think -- in general most of the Reply-To related
proposals here belong there, I would suppose).

 > > And there's a hope that that would lead to MUA developers making
 > > the List-original-author field available to users - to filter by,
 > > to use as a target to "reply to author", and to be visible to
 > > identify the original sender?
 > 

Uh-oh.

4.  If this field were made visible to users in popular MUAs, they
    would surely learn to interpret it as a "Really-Truly-From" field,
    and thus it would become a vector for attacks.  If not made
    visible, it's not clear to me what good it would be.  Yes, you
    could give it precedence over the From field for Reply-To-Author,
    but that would be confusing to users, and possibly open to abuse.

Note that previous proponents of Original-Author fields have
maintained that the good thing about it would be that it would *not*
be visible to users, and thus would not attract the attention of the
folks using "p=reject".

 > >> Which leads to the purely procedural question: What would be the
 > >> most straightforward process for writing and promulgating an RFC
 > >> that essentially updates RFC2369 by adding one section that
 > >> defines an additional header to the current list of List-*
 > >> headers?

The first thing you need to do is realize that these proposals only
make sense under the presumption that From will be munged.  That is
nonconformant to RFC 5322, and *that* is a nonexistence proof for
"straightforward".

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 28 Oct 2014 01:24:52 -0500

On October 28, 2014 12:51:03 AM CDT, "Stephen J. Turnbull" <[email-masked]> wrote:
>managers 
>either 

So because RFC 5322 the email I see in my inbox on a daily basis with a munged From is a figment of my imagination? 

Also, since Mailman already supports From munging, it seems odd to suggest related patches wouldn't be accepted because From munging is evil.  I believe the Rubicon has been crossed. 

Scott K

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 28 Oct 2014 17:11:23 +0900

> > The problem that needs to be addressed relates to all possible
 > > third-party related services, which includes but is not limited
 > > to use of discussion lists.  There are many other equally
 > > legitimate examples of valid third-party messages (third-party
 > > defined as when the From and DKIM or SPF domains do not align).
 > 

I think most participants here agree with you (with all due respect to
Douglas, who's done a ton of work on TPA-labels).

Have you read the archives, going back way before the WG formation,
even?  All of these issues (including perfect vs. good :-) have been
hashed repeatedly since April, and most all have a distinguished
lineage (discussion of some of them have recently been discovered in
previously uninterpretable portions of the Dead Sea Scrolls ;-).

 > particular, dealing with mailing list breakage

Even though I'm a MLM developer, I object to that "particularization"
for the same reasons others do: often there is a trivial or simple
generalization that covers more use cases.  Specifically, I see no
point whatsover in a "List-" prefix for any of the headers proposed.
The main advantage seems to be that it makes it look like a small,
no-brainer change to existing practice for a particular use-case.  But
it's neither (as I've argued elsewhere).

 > MTAs to make their own decisions based on multiple inputs.

And they still do.  Just not all of them.  In fact, the DMARC document
phrases these things in terms of "advice".  (It doesn't use that word,
but clearly "p=reject" is an abbreviation for "p=[we have a security
problem so anything that's not From-aligned is surely inauthentic and
probably malicious so without bothering your users you can and should
peremptorily ]reject".)

 > And, in the process, the DMARC approach essentially tells
 > intermediate services to go screw.

In practice, yes.  

However, from the point of view of the letter of the document, Yahoo!
and AOL know very well that in their case failure of From alignment
does *not* mean the message is inauthentic (at least not sufficiently
reliably), and therefore they should not be using it as they do.  I'm
not sure what the AOL people are thinking, but pretty clearly the
Yahoo! technical staff are aware of the problem and do not like the
collateral damage associated with their "p=reject" policy.  I
personally believe they would be amenable to trying From-Domain-side
mitigations that solve most of their problems.  Eg, Levine's "DKIM
Conditional Signatures", the Crocker-Kucherawy "Delegating DKIM
Signing Authority", or Otis's "Third-Party Authorization Label":

http://tools.ietf.org/html/draft-levine-dkim-conditional
http://tools.ietf.org/html/draft-kucherawy-dkim-delegate
http://tools.ietf.org/html/draft-otis-tpa-label

It just won't happen until we have our ducks in a row, and some large
scale experiments have been conducted.

 > straightforward extension to an existing practice (the List-*

It's not straightforward.  You may think it's straightforward, and you
have every right to your opinion, but (as discussed elsewhere) a lot
of people disagree, and that makes the politics of getting something
into place anything but straightforward.

It will also be difficult to get people to *stop* doing those things
once there is a better fix.  That is especially true if they discover
convenient abuses of the new fields (like Reply-To munging).

 > >> Speaking as one who both is on a bunch of mailing lists, and who
 > >> hosts a bunch of mailing lists, the suggestion strikes me as
 > >> almost a no-brainer.  It solves a very big problem, in a very
 > >> straightforward way.

It doesn't solve *anything* until MUAs support it.  Most MUAs
currently "support" it only by providing an "original message"
functionality which allows the cognoscenti to look it up themselves.
This may or may not take as much time as it takes Yahoo! and AOL to
adopt Author-Domain-side mitigations.

 > > Ensuring an origination header can be seen is better solved by
 > > making specific exceptions for valid use of From header field
 > > group syntax permitted by RFC6854 which amended RFC5322.
 > 

It's in the archives of this mailing list.

 > and Reply-To: have never been quite clear,

Oh, yes they have.  Discussion lists that use Reply-To are simply
nonconformant, and the costs and benefits of doing so have long been
clear.   People simply disagree on the values associated with it, and
nobody has gone to the effort to (1) write a protocol for a field for
list use (more generally, any Mediator's use), and (2) provide patches
for the major open source MUAs to support them.

 > cooperation of Yahoo et al, let's see it!

The cooperation of Yahoo! is likely to be forthcoming (IMO YMMV of
course), although it won't be 100% of what we'd like and it won't be
tomorrow.

 > I'd argue that point.  At this point, the community hasn't accepted
 > the DMARC approach to imposing sender authentication - rather, a
 > popular reaction has been to ignore DMARC policies.  I suggest that
 > this is a situation that will continue.

No.  They do not ignore them, at least if you're talking about Gmail.
Gmail only downgrades from p=reject to p=quarantine.

Nor does DMARC itself *impose* sender policies (despite the names of
the p= policy options).  As described above, once one wades through
all the technical verbiage, "p=reject" is *advice*, but (if the Author
Domain is something like a bank) advice that no sane mailbox provider
would care to ignore.  So Gmail has *always* treated p=reject as
p=quarantine (some discussion of this point from Gmail personnel is in
the archives here), and it just *seems* as if they suddenly started
ignoring p=reject during the April Debacle because whatever algorithm
they use is sane vs. the intended use cases for DMARC p=reject.  It's
only when Yahoo! started using p=reject that it became clear that
they're quite sane for that use case too. :-)

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 28 Oct 2014 18:22:04 +0900

Scott Kitterman writes:

 > So because RFC 5322 the email I see in my inbox on a daily basis
 > with a munged From is a figment of my imagination?

What is a figment of your imagination is your interpretation of what I
wrote, and you quoted.

It was somewhat abbreviated, so let me expand.  The fact that some
agents do not conform to a standard is rarely considered a sufficient
reason to amend the standard, much less so to build on the
nonconformance without amending the standard.  Such changes will be
anything but straightforward, unless you make a deliberate effort to
generate a "submarine" RFC without attracting attention from those of
us who believe our reasons for disliking the idea are good ones.

 > Also, since Mailman already supports From munging, it seems odd to
 > suggest related patches wouldn't be accepted because From munging
 > is evil.

Mailman supports From-munging for the same reasons that it supports
Reply-To munging: so that it can

 - document that behavior demanded by users is non-conformant and not
   recommended,

 - document why that is so, 

 - document the limitations and "gotchas" provided by the feature, and

 - where possible, provide features that limit the damage but are
   substantially more difficult to implement because they not only are
   flexible, but also need support from the list configurate routines.

In the Reply-To case, Mailman provides options to *set* the Reply-To
field to list, or to *add* the list's address to Reply-To.  In the
DMARC case, From-munging can be selectively performed only when the
message's Author Domain publishes a "p=reject" policy), and again
Reply-To handling has several options.  Such more complicated features
are rarely provided by the 3rd-party patches, which often become quite
widely used.

It is not clear to me that there will be any demand at all for such
patches by Mailman sites.  If and when there is, we'll think about it.
As an abstract exercise, I will oppose standardization of an "original
author" field, and it was considered likely when I was delegated to
particpate here that most of the core developers of Mailman will agree
with me (that's why they ain't here and I is).

 > I believe the Rubicon has been crossed.

I appreciate your discussion.  It's made me take a lot more care in my
own thinking on the matter.  But I think you're on the wrong
continent.  The Tigris has been crossed, but we can still avoid
crossing the Euphrates, and at least for now, I believe we should go
no farther.

Specifically, ISTR you are one of the advocates of an "original
author" header field who maintains that it's safe because MUAs *won't*
display it, and therefore it does not pose the kind of "recommender
spam" and phishing risks that the From field does.  But here you are
supporting two posters who suggest that display by the MUA is a
desirable feature.  It's definitely not straightforward when different
proponents advance diametrically opposed features as important
advantages of the proposal.

Regards,

Steve

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 28 Oct 2014 15:27:01 -0400

> advantages of the proposal.

Thanks for the thoughtful reply.

My personal want is very limited.  When I click on "reply to author" in Kmail, 
I want it to go to the person that wrote the mail (Kmail also has reply to 
list, which is very useful for me).  If there's no interest in standardizing, 
then I'll just make sure X-Original-Sender which is being used by multiple 
parties already is supported.  I still think picking a common header field name 
to use is better than not, but meh.

Scott K

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 28 Oct 2014 20:37:59 -0400

Scott Kitterman wrote:
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

Stephen - thanks for your comments - obviously it's not as 
straightforward as I might think.

Then again, Scott makes a pretty good point.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 29 Oct 2014 15:00:19 +0900

Miles Fidelman writes:

 > > My personal want is very limited.  When I click on "reply to
 > > author" in Kmail, I want it to go to the person that wrote the
 > > mail (Kmail also has reply to list, which is very useful for me).
 > > If there's no interest in standardizing, then I'll just make sure
 > > X-Original-Sender which is being used by multiple parties already
 > > is supported.  I still think picking a common header field name

Yes, he does.  It's very similar to the one I made to Hector just now
about From-munging being a de facto BCP (best current practice).

But I strongly believe that we should not make either be a de jure
normative RFC.  And I think it's best to leave these de facto BCPs
informal, for private agreement among participating parties (that
latter is very much IMHO YMMV, I understand that it will be annoyingly
unreliable and tedious in Scott's use case).  That's quite aside from
the consideration that the IETF process will cough up a hairball on
any proposal that involves "reinterpreting" the semantics of the From
field. :-)

Regards,
Steve