Opened 2 years ago

Last modified 2 years ago

#12037 assigned Bug/Something is broken

roundcube reply to list button includes sender on mailman lists which caueses problems

Reported by: Owned by:
Priority: High Component: Tech
Keywords: roundcube Cc:
Sensitive: no


When viewing a message, our roundcube webmail has a nice button with two arrows with the title "Reply to list or to sender and all recipients".

However, when you click it while viewing an email sent via our mailman instance, it sends to the list (in the to field) and your mailman bounce address in the cc: field (this is techically the "Return-Path" field from the original message.

This sends a message to mailman that mailman interprets as a bounce which causes problems.

Here are the headers of an example email:

Return-Path: <>
Delivered-To: <>
Received: from
    by (Dovecot) with LMTP id HC+uLDoetlcYQQAAbtgvXg
    for <>; Thu, 18 Aug 2016 16:44:42 -0400
Received: from (localhost [])
    by (Postfix) with ESMTP id 6C6371FCA
    for <>; Thu, 18 Aug 2016 16:44:41 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
X-Spam-Status: No, score=-0.5 required=5.0 tests=RP_MATCHES_RCVD,
    UNPARSEABLE_RELAY autolearn=disabled version=3.4.0
X-Spam-Language: en
Received: from ( [])
    (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
    (No client certificate requested)
    by (Postfix) with ESMTPS id ECB7C1FD1
    for <>; Thu, 18 Aug 2016 16:44:40 -0400 (EDT)
Received: from ( [])
    by (Postfix) with ESMTPS id EBFE783EE
    for <>; Thu, 18 Aug 2016 16:44:32 -0400 (EDT)
Received: from (localhost [])
    by (Postfix) with ESMTP id 222ED1DB62
    for <>; Thu, 18 Aug 2016 16:44:39 -0400 (EDT)
Received: from (localhost [])
    by (Postfix) with ESMTP id D7E471DB5E
    for <>;
    Thu, 18 Aug 2016 16:44:36 -0400 (EDT)
Received: from ( [])
    by (Postfix) with ESMTPS id B079E1DB5D
    for <>;
    Thu, 18 Aug 2016 16:44:36 -0400 (EDT)
Received: from (unknown [])
    by (Postfix) with ESMTP id 9CD853F33
    for <>;
    Thu, 18 Aug 2016 16:44:40 -0400 (EDT)
Received: from [] (localhost []) (Authenticated sender: with ESMTPSA id 77BF23F18
Received: by (Postfix, from userid 1000)
    id 735C4803CC; Thu, 18 Aug 2016 16:44:41 -0400 (EDT)
Date: Thu, 18 Aug 2016 16:44:41 -0400
From: Jamie McClelland <>
Message-ID: <>
MIME-Version: 1.0
User-Agent: Mutt/1.6.0 (2016-04-01)
X-Virus-Scanned: ClamAV using ClamSMTP
X-Virus-Scanned: ClamAV using ClamSMTP
Subject: [Leadership_committee] documentary on internet service providers
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <>
List-Unsubscribe: <>,
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>,
Content-Type: multipart/mixed; boundary="===============6072663371249363877=="
Sender: "Leadership_committee"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Envelope-From: <>
Content-Length: 6086

I'm attaching a screen shot of the view after I hit the reply to list button.

Attachments (1)

roundcube-to-cc-fields.png (11.3 KB) - added by 2 years ago.

Download all attachments as: .zip

Change History (8)

Changed 2 years ago by

comment:1 Changed 2 years ago by

  • Owner set to
  • Status changed from new to assigned

Seems like a couple of things are broken.

First off, since this is a list, the "reply list/reply all" button should just reply to the list, which should be auto-detected so that no other address is displayed. I see a ticket about making this option user-configurable, but not sure what the default is. Ultimately, I think this is the proper fix.

Since roundcube doesn't seem to believe this is a list, it is doing a reply-all. It seems that the sender-path should not be included in a reply-all (just the From, To, and CC). Also, I see an [ issue asking the devs to ignore a -request addresses when using reply-all. So, we could also request an exception for bounces+ addresses??

Steve: I've assigned this to me but would be grateful if you wanted to take it over!

comment:2 Changed 2 years ago by

This is an interesting one. I wonder if roundcube is picking up the value of the Sender header. In this case, Sender's value is the same as Return-Path.

According to,

The "Sender:" field specifies the mailbox of the agent responsible for the actual transmission of the message. For example, if a secretary were to send a message for another person, the mailbox of the secretary would appear in the "Sender:" field and the mailbox of the actual author would appear in the "From:" field.

In this case, the sender is clearly mailman. But I guess there's some room for interpretation as to whether Sender should be leadership_committee@ vs

The roundcube issue is targeted to 1.0-beta, and we're currently running 1.1.2. So if there's a configuration option, it should be available in our roundcube installation.

I also wonder if changing mailman's reply_goes_to_list = "This list" would make roundcube behave better. (This appears under mailman's "General Options" for a mailing list, as "Where are replies to list messages directed?").

Oh wait, I see that roundcube has

// Default behavior of Reply-All button:
// 0 - Reply-All always
// 1 - Reply-List if mailing list is detected
$config['reply_all_mode'] = 0;

I've set $config['reply_all_mode'] = 1; on Can you give that a try?

comment:3 Changed 2 years ago by

Nope, that doesn't quite to it. With a Reply-To header, "Reply" uses the Reply-to: header, "Reply-list" uses the List-Post: header, but "Reply-All:" still uses Sender/Return-path.

Poo :(

comment:4 Changed 2 years ago by

One last bit before I call it a night.

/var/lib/mailman/Mailman/ has

# RFC 2822 suggests that not adding a Sender header when Mailman is the agent
# responsible for the actual transmission is a breach of the RFC.  However,
# some MUAs (notably Outlook) tend to display the Sender header instead of the
# From details, confusing users and actually losing the original sender when
# forwarding mail.  By setting this variable to Yes, list owners will be
# given the option to avoid setting this header.

Mailman's general options have

Should the Sender header be rewritten for this mailing list to
avoid stray bounces? Yes is recommended.  (Details for

Perhaps setting this to "No" might make a difference.

comment:5 Changed 2 years ago by

Alright, this is really the last bit before I call it a night.

Appears that the inclusion of Sender: in CC: is by design

comment:6 Changed 2 years ago by

Thanks Steve for pushing this forward and clarifying my confusion between Return-Path and Sender.

I think you correctly identified the problem and the fix with $config['reply_all_mode'] = 1; - that seems to be exactly what we want but why is it not working? Seems to be a bug in roundcube.

I discovered that, when viewing a message (double click on message rather than viewing in the preview pain), the Reply-All button can be clicked (to get the default value) or there is a down arrow to pick to either Reply-All OR Reply list.

When I view a message that is not from an email list, the "Reply list" option is greyed out. When I pick a message that is from a list, the "Reply list" function is available. So, roundcube is properly detecting that it is from a list.

However, when I click the default reply-all button, it behaves in the "reply-all" fashion (from and sender).

comment:7 Changed 2 years ago by

I seem to have found the bug, but not sure how to fix it. Steve - when you have a chance can you review (in the dev folder on stallman): program/js/app.js.debug.reply_all_mode. That's my version of app.js that demonstrates that the reply_all_mode setting is undefined.

I'm not entirely sure where it should be defined (perhaps we should just open a ticket against roundcube).

Please login to add comments to this ticket.

Note: See TracTickets for help on using tickets.