[Mailman-Users] Assistance with altering reply-to behaviours and DMARC

[Mark]

On 28/08/15 4:37 pm, Stephen J. Turnbull wrote:
> Stock Mailman 2.1.12 doesn't do any DMARC detection.  This is quite
> bizarre that they would backport such a feature rather than update to
> 2.1.18-1 or later.  Mailman 2.1 is hardly an unstable package.

I am not sure why the changes were back-ported - maybe it had something to do with the version of Python on the platform.  I fully understand that the ability of the developers is 
limited to supporting known releases, and this release is not a supported one. So I don't expect more than some general guidance :)

>   > Normally the lists we use are configured with reply_goes_to_list
>   > and anonymous_list is off.  We have done some testing, and we have
>   > not been able to identify settings that will retain
>   > reply_goes_to_list functionality and turn on DMARC Mung.
>
> You'll have to talk to the vendor who did the modifications.
>
>   > Generally what happens is that the first message is successfully
>   > sent to a yahoo.com address and this user can reply to the message
>   > as normal.  However, mailman adds the original sender to the
>   > reply-to meaning that when another user replies to this message
>   > reply_goes_to_list doesn't work.
>
> What do you mean by "doesn't work"?  That it doesn't go to the list at
> all, or that although it goes to the list, it *also* goes (separately)
> to the original poster?

I will try to explain, but its only on subsequent replies the issue appears:-

Step 1:  email is sent to the list - the mail to DMARC protected domain is received ok by Yahoo web client.  Reply-to is set to the list.

Message source of first email is:

  From: Mark <mark at incet.com>
  Reply-To: Test <test at testdomain.org>

Step 2: Reply from Yahoo client sends an email to the list and this has the following source when viewed on Thunderbird MUA

  From: Mark H via Test <test at testdomain.org>
  Reply-To: Mark H <markhnzy at yahoo.com>, Test <test at testdomain.org>

Step 3: A reply from the TB MUA goes to markhnzy at yahoo.com and test at testdomain.org

Because mailman helpfully recognises that a copy has already been sent to the user directly, a copy is not sent to markhnzy@ from the list.

Step 4: Now, when markhnzy@ replies, the conversation is between the recipient and the sender alone.



>
> Not going to the list at all means the MUA is broken IMO; multiple
> addresses in Reply-To are explicitly allowed by the RFC, and MUAs
> should reply to all of them.
>
>   > It seemed to me that a small modification to CookHeaders.py could
>   > prevent the adding of the original sender email to "Reply-To"
>   >
>   >          # We also need to put the old From: in Reply-To: in all cases.
>   >          if o_from:
>   >              add(o_from)
>   >          # Set Reply-To: header to point back to this list.  Add this last
>
> After disabling the "add(o_from)" operation, if reply_goes_to_list is
> set, then (1) the reply goes *only* to the list by default, and (2) it
> is impossible for the user's MUA to automatically format a reply to
> poster.  If reply_goes_to_list is not set, (1) reply by default will go to
> list (since it's the address in From), and (2) it is impossible to
> automatically format a reply to poster.

I agree that this is not a bug as such; its more about the desired behaviour for a specific need of mailman and that new non-RFC compliant behaviour will result.

I tried commenting out if o_from and add(o_from), but original from address was still added to the reply-to(as well as the list address).  I did change some permissions and restart 
mailman and confirm that a new py file was created, so I don't think its that my change wasn't included.

Is there any other code in the standard mailman where the reply-to is populated with the original sender?  I realise  fully aware that the version of mailman I have here isn't 
supported, or released, and other bugs may have been introduced.

thanks again for the replies.

Mark.

> It is our opinion that (2) is a sufficiently important bug that we are
> unlikely to change this, even to provide an option.  But if you want
> to make that edit, it probably does what you want.  Depending on your
> users, you may or may not get complaints about inability to respond
> privately.