On 08/04/2017 10:15 AM, Jordan Brown wrote:

On 8/4/2017 8:24 AM, Mark Sapiro wrote:

...

On 08/03/2017 07:15 PM, Jordan Brown wrote:

...

Is there a way to control the From value when it gets munged so we pass DMARC? There's no configuration for it, but it's a simple patch.

Thanks. Alas, I'm a hosting-provider customer, not standalone, and so don't have access to make source changes. Maybe it can go on the wish list?

You could submit a request at https://bugs.launchpad.net/mailman/+filebug or for Mailman 3, at https://gitlab.com/mailman/mailman/issues, but It's unlikely that anything will be done, at least for 2.1.

For Mailman 2.1, I see two ways to do this. The easy way is to create an mm_cfg.py setting with which one could specify 'xxx' to be added to the address as in listname-xxx@example.com. This wouldn't help you and other hosting provider customers however as the hosts would almost certainly not change the default.

The alternative of making it a list setting is more work as it affects the web admin UI and the translations thereof.

Also, with either method, forward porting to MM 3 is an additional consideration.

I'm aware of issues with Microsoft services adding 'spoofing' warnings to messages where the From: address and the To: address are the same. Is this what you were referring to by "Setting it to the list name interacts badly with outloook.com and hotmail.com replies." in your OP. If not that, then what?

In any case, if these issues become more problematic, we'll probably have to do something, but what, I don't know.

-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 08/04/2017 01:35 PM, Jordan Brown wrote:

On 8/4/2017 12:51 PM, Mark Sapiro wrote:

...

I'm aware of issues with Microsoft services adding 'spoofing' warnings to messages where the From: address and the To: address are the same. Is this what you were referring to by "Setting it to the list name interacts badly with outloook.com and hotmail.com replies." in your OP. If not that, then what?

I haven't investigated deeply, but with an original message like:

Thanks for the info.

Return-Path: <list1-bounces@listdomain.org>
Return-path: <list1-bounces@listdomain.org>
Date: Wed, 2 Aug 2017 19:44:35 +0000 (UTC)
To: list2 <list2@listdomain.org>, 
	list1 <list1@listdomain.org>
Subject: [list1] ...
X-BeenThere: list1@listdomain.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: "list1" <list1.listdomain.org>
List-Unsubscribe: <http://listdomain.org/mailman/options/list1_listdomain.org>, 
	<mailto:list1-request@listdomain.org?subject=unsubscribe>
List-Post: <mailto:list1@listdomain.org>
List-Help: <mailto:list1-request@listdomain.org?subject=help>
List-Subscribe: <http://listdomain.org/mailman/listinfo/list1_listdomain.org>,
	<mailto:list1-request@listdomain.org?subject=subscribe>
From: Jane User via list1 <list1@listdomain.org>
Reply-To: Jane User <jane@example.net>
Errors-To: list1-bounces@listdomain.org
Sender: "list1" <list1-bounces@listdomain.org>

Two of my users (on outlook.com and hotmail.com) ended up with reply-to-all results that were addressed to Joe User and list2, but not to list1 at all. ...

My theory is that MS is (wrongly) dropping the "To" copy of list1 from the reply because it's the From, and then (correctly) using the Reply-To instead of the From.

It looks to me as if your theory is correct, except I wouldn't say "wrongly". I think an MUA is arguably doing the right thing by overriding the From: address with the Reply-To: address on a reply-all even though the From: address is also in To:.

I agree that this is an issue because without From: munging the message would be From: Jane User jane@example.net and presumably reply-all would go to Jane and both lists in To:.

Here's what I say in the code

# MAS: We need to do some things with the original From: if we've munged
# it for DMARC mitigation.  We have goals for this process which are
# not completely compatible, so we do the best we can.  Our goals are:
# 1) as long as the list is not anonymous, the original From: address
#    should be obviously exposed, i.e. not just in a header that MUAs
#    don't display.
# 2) the original From: address should not be in a comment or display
#    name in the new From: because it is claimed that multiple domains
#    in any fields in From: are indicative of spamminess.  This means
#    it should be in Reply-To: or Cc:.
# 3) the behavior of an MUA doing a 'reply' or 'reply all' should be
#    consistent regardless of whether or not the From: is munged.
# Goal 3) implies sometimes the original From: should be in Reply-To:
# and sometimes in Cc:, and even so, this goal won't be achieved in
# all cases with all MUAs.  In cases of conflict, the above ordering of
# goals is priority order.

Clearly in this case with these MUAs we don't meet Goal 3) and this falls into "even so, this goal won't be achieved in all cases with all MUAs."

I think it might be possible to munge the address to no_reply@example.com instead of listname@example.com in all cases of From: munging. I have to consider all the possible consequences of this, or as many as I can think of, before actually doing it.

One issue that comes to mind immediately is when the original From: goes in Cc:. This is when the Reply-To: is munged to be the list address and is done so that "reply" goes only to the list and "reply-all" includes the original From:. In this case, "reply-all" may (arguably wrongly, but still ...) include the no_reply address which is bad.

I'm inclined to leave it as is for now, but I'll continue to think about it.

-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 08/04/2017 07:30 PM, Jordan Brown wrote:

What I'm objecting to is the fact that it hunts down *other* instances of the address in From and removes them (or perhaps replaces them with the Reply-To and then eliminates duplicates). I think Reply-All should take {Reply-To, else From}, To, and CC, and reply to them.

I agree that what you think would be reasonable and what people generally expect, but what RFC 5322 says is

  Note: Some mail applications have automatic reply commands that
  include the destination addresses of the original message in the
  destination addresses of the reply.  How those reply commands
  behave is implementation dependent and is beyond the scope of this
  document.  In particular, whether or not to include the original
  destination addresses when the original message had a "Reply-To:"
  field is not addressed here.

Which basically says that whatever the specific MUA does with reply-all when there is a Reply-To: is not addressed by the standard and is up to the implementer, so while you and I may not like the behavior of outlook/hotmail in this case, we can't say it is non-compliant.

As an aside, you don't want to convince me that this behavior is wrong, because you'd like me to do something in Mailman to make this reply-all behavior work as expected, but I'm not interested in kludging Mailman to accommodate broken MUAs.

-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 8/6/2017 11:36 PM, Stephen J. Turnbull wrote:

Unfortunately, you can assume that the large freemail services do not care what you think.

Yep.

50% :-) 50% :-(

I'm not sure why they've all gone substantially downhill in the last decade, but they have. Probably they get complaints and feel they have to "do something, anything" about them.

Sometimes I think they're trying to drive everybody to Facebook.

That said, I don't know if it's a useful option for you, but one possibility would be to set reply-to to the list as well as using one of the munge_from settings. Because munge_from has the effect of hiding the author's address, it also places the author's address in the reply-to, even if the list is already there.

Alas, no. I've seen too many messages intended to be private sent to the entire list with that configuration; I would never use it. (I've boycotted lists simply because they insisted on that configuration.)

Thanks.