Hi, I'm familiar with Mailman v2 at DreamHost, and now setting up & learning Mailman v3 with Affinity at EMWD.com (EMWD is looking good so far, review coming later).
One setting I'd like to check in about is MUNGE . What should I be doing with Munge? My gut feeling is to use; "Explicit Reply-To header set". But I'm here to ask, not to tell.
The drawback is that after Munging the "From", it is no longer trivial to see who sent the message to the group. Sort of good. Sort of bad, depending. I mostly prefer to easily see the poster's email address. And the big mail providers would mostly accept this From format if it matched the Mailman sending server.
I have set up everything I can think of to try for good delivery; SPF, DKIM, DMARC, and a SSL certificate on the server.
My discussion group lists all work best with any reply being sent to the list, not to the poster directly. And it is helpful to somehow indicate who wrote the message.
The Munging options I see are: No Munging Reply goes to list Explicit Reply-To header set Explicit Reply-To header set, no CC added.
And there are some similar DMARC Mitigations.
Anyway, are we still doing Munging with MailMan v3 with Affinity?
What is the v3 best setting for handling the From address?
Best, Dave Nathanson Mac Medix
On 7/17/26 11:00, Dave Nathanson via Mailman-Users wrote:
Hi, I'm familiar with Mailman v2 at DreamHost, and now setting up & learning Mailman v3 with Affinity at EMWD.com (EMWD is looking good so far, review coming later).
One setting I'd like to check in about is MUNGE . What should I be doing with Munge? My gut feeling is to use; "Explicit Reply-To header set". But I'm here to ask, not to tell.
The drawback is that after Munging the "From", it is no longer trivial to see who sent the message to the group. Sort of good. Sort of bad, depending. I mostly prefer to easily see the poster's email address. And the big mail providers would mostly accept this From format if it matched the Mailman sending server.
It has been a long time since I have had anything to do with Affinity so
I'm not familiar with the web UI, but it seems the above is conflating
two settings. One of these is the Reply goes to list setting which has
to do with munging the Reply-To: and has nothing to do with munging the
From:. This corresponds roughly to the MM 2.1 setting
reply_goes_to_list. We generally recommend No Munging for this
setting, at least for discussion lists. However, it seems that your MM
2.1 lists are set for reply_goes_to_list = This list and the
corresponding MM 3 setting is Reply goes to list.
I don't know what Affinity's help for Reply goes to list says, but Postorius says
Where are replies to list messages directed? No Munging is strongly
recommended for most mailing lists.
This option controls what Mailman does to the Reply-To: header in
messages flowing through this mailing list. When set to No Munging, no
Reply-To: header is added by Mailman, although if one is present in the
original message, it may be stripped depending on First strip Reply-To.
Setting this value to Reply to List or either of the Explicit Reply
settings causes Mailman to insert a specific Reply-To: header in all
messages, either adding to or overriding the header in the original
message depending on First Strip Reply-To. Explicit Reply inserts the
value of Explicit reply-to_address, Reply goes to list inserts the list
posting address. Explicit Reply-to set; no Cc added is useful for
announce-only lists where you want to avoid someone replying to the list
address. There are many reasons not to introduce or override the
Reply-To: header. One is that some posters depend on their own Reply-To:
settings to convey their valid return address. Another is that modifying
Reply-To: makes it much more difficult to send private replies. See
Reply-To' Munging Considered Harmful <http://marc.merlins.org/netrants/reply-to-harmful.html> for a general discussion of this issue. See Reply-To' Munging Considered Useful
<http://marc.merlins.org/netrants/reply-to-useful.html> for a dissenting
opinion. Some mailing lists have restricted posting privileges, with a
parallel list devoted to discussions. Examples are patches' or checkin' lists, where software changes are posted by a revision control
system, but discussion about the changes occurs on a developers mailing
list. To support these types of mailing lists, select Explicit Reply and
set the Reply-To: address option to point to the parallel list.
The main issue with setting this to Reply goes to list is it makes it easy to inadvertently send a private reply to the list which can be a serious and irreversible error whereas inadvertently replying to the poster instead of the list is easily correctable. You should read the articles linked in the above help for additional information.
The other setting is for DMARC mitigations. Our recommendation for this
setting is Replace From: with list address. This does not hide the
sender. We take greate pains to expose the sender. For example assume a
post From: Jane User <jane@example.com> to list@example.com. The munged
From: will be
From: Jane User via List Display Name <list@example.com>
and jane@example.com will be added to either Reply-To: or Cc: depending on list settings. See <https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/handlers/dmarc....>
I have set up everything I can think of to try for good delivery; SPF, DKIM, DMARC, and a SSL certificate on the server.
My discussion group lists all work best with any reply being sent to the list, not to the poster directly. And it is helpful to somehow indicate who wrote the message.
The Munging options I see are: No Munging Reply goes to list Explicit Reply-To header set Explicit Reply-To header set, no CC added.
And there are some similar DMARC Mitigations.
Anyway, are we still doing Munging with MailMan v3 with Affinity?
What is the v3 best setting for handling the From address?
If you are talking about From: munging, yes - it is the recommended option for DMARC mitigation which must be done for reliable delivery.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Thanks for asking, Dave. I am interested too! And also the EMWD eval.
Joly
On Fri, Jul 17, 2026 at 2:00 PM Dave Nathanson via Mailman-Users < mailman-users@python.org> wrote:
Hi, I'm familiar with Mailman v2 at DreamHost, and now setting up & learning Mailman v3 with Affinity at EMWD.com (EMWD is looking good so far, review coming later).
One setting I'd like to check in about is MUNGE . What should I be doing with Munge? My gut feeling is to use; "Explicit Reply-To header set". But I'm here to ask, not to tell.
The drawback is that after Munging the "From", it is no longer trivial to see who sent the message to the group. Sort of good. Sort of bad, depending. I mostly prefer to easily see the poster's email address. And the big mail providers would mostly accept this From format if it matched the Mailman sending server.
I have set up everything I can think of to try for good delivery; SPF, DKIM, DMARC, and a SSL certificate on the server.
My discussion group lists all work best with any reply being sent to the list, not to the poster directly. And it is helpful to somehow indicate who wrote the message.
The Munging options I see are: No Munging Reply goes to list Explicit Reply-To header set Explicit Reply-To header set, no CC added.
And there are some similar DMARC Mitigations.
Anyway, are we still doing Munging with MailMan v3 with Affinity?
What is the v3 best setting for handling the From address?
Best, Dave Nathanson Mac Medix
Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-leave@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/ Member address: joly@punkcast.com
--
Joly MacFie +12185659365
Dave Nathanson via Mailman-Users writes:
I'm familiar with Mailman v2 at DreamHost, and now setting up & learning Mailman v3 with Affinity at EMWD.com (EMWD is looking good so far, review coming later).
For reliable answers, any questions about Affinity (and the EMWD proprietary archive application Empathy) must be directed to EMWD. They are proprietary, closed source products we have no special access to.
That said, Mark seems to have missed that we don't have a Munge From option other than DMARC Mitigation Action, so probably Affinity is just exposing the same options that Postorius does, I will present the same information he did, but organized differently assuming that is true.
I have set up everything I can think of to try for good delivery; SPF, DKIM, DMARC, and a SSL certificate on the server.
You should also configure ARC (RFC 8617). This is a protocol that most of the big sites participate in that allow a domain to testify to the original authentication results of received mail that is sent back out to the Internet after alteration. The most common MTA plugin is openarc.
It is best if SPF, DKIM, and ARC are implemented in your MTA. ARC is less common, and can be enabled (with some tiny risk that your MTA will mess it up somehow) in Mailman 3 itself. The configuration is done in mailman.cfg in the [ARC] section. (See Python's site-packages/mailman/config/schema.cfg for the ARC variables. You can use all the same crypto settings as for DKIM.)
My discussion group lists all work best with any reply being sent to the list, not to the poster directly. And it is helpful to somehow indicate who wrote the message.
Mailman 3 puts the original display name in From's display name if available. IIRC if it's a "naked" address, it uses that. That *should* be sufficient, except a lot of MUA's prefer to show the MUA's *contact list* display name corresponding to the From *address*. Nothing we can do about that. Also, the original From will appear in CC when From is munged for DMARC, but Reply-To is not.
The Munging options I see are: No Munging Reply goes to list Explicit Reply-To header set Explicit Reply-To header set, no CC added.
It looks like this is just exposing the core Mailman 3 Reply-To Munging option via Affinity. It has nothing to do with From munging.
And there are some similar DMARC Mitigations.
These are the ones that do From munging. If they also just expose the corresponding Mailman 3 core option, you should see:
- No munging
- Replace From: with list address
- Wrap message # Probably won't work for your users.
- Reject # Don't use. These two are just a GTFO from
- Discard # the Mailman developers to Yahoo and AOL.
There should also be a "DMARC Mitigate Unconditionally" option, and a "DMARC Addresses" option.
Anyway, are we still doing Munging with MailMan v3 with Affinity?
What is the v3 best setting for handling the From address?
We recommend:
- Reply-To munging: No Munging
- DMARC Mitigation Action: Munge From
- DMARC Mitigate Unconditionally: No
- DMARC Addresses: ^.*@gmail\.com$
"Mitigate Unconditionally: Yes" is appropriate only if users are vociferously complaining that people at strict DMARC domains get munged but others don't, or you're seeing lots of bounces for posters at random small domains that appear to be "stealth DMARC" sites.
"DMARC Addresses" should contain at least "^.*@gmail\.com" to handle "stealth DMARC" at large sites. That is, when sites tell the world *not* to reject mail from them that fails domain authentication, then reject it themselves. Gmail is known to do this, it's the only major that does as far as I know.
If you want to strongly encourage replies to the list, you have to accept some compromises because MUAs handle the default reply behavior poorly and inconsistently across MUAs. We prioritize ease of reply: When you have Reply-To munging enabled, we put the author's name there (instead of CC) on the assumption that the list has naive users who expect "Reply" to do the right thing. On the other hand they would be confused if they had to use "Reply All" to fetch the author's address from CC to reply personally (and probably would broadcast the reply to a bunch of addresses not intended). We don't do both because historically some MUAs would put both in the addressee list in case of "Reply All", and some MTAs would proceed to send multiple copies.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Am 18.07.26 um 10:04 schrieb Stephen J. Turnbull:
You should also configure ARC (RFC 8617). This is a protocol that most of the big sites participate in that allow a domain to testify to the original authentication results of received mail that is sent back out to the Internet after alteration. The most common MTA plugin is openarc.
I considered ARC to be obsolete (and to should-be-replaced-by DKIM 2)?
https://www.ietf.org/archive/id/draft-adams-arc-experiment-conclusion-00.htm...
Alexander Inzinger-Zrock via Mailman-Users writes:
I considered ARC to be obsolete (and to should-be-replaced-by DKIM 2)?
Not a chance. Both "ARC Failed" [1] and "DKIM 2" [2] are expired drafts. Doesn't mean they won't get picked up in the future, but there's not momentum for them now.
ARC remains somewhat useful and not terribly burdensome for an intermediary such as a mailing list to implement. "ARC Failed" trash-talks ARC, but DKIM 2 as described is not a replacement for ARC that is helpful to mailing lists. In fact, it's more problematic for mailing lists than DMARC itself. Many Mailman mailing lists will find it impossible to participate in DKIM 2 at all, as I understand the MUSTs in that draft.
(1) There's no reason to suppose that mom-and-pop ESPs and ISPs sending posts to mailing lists will implement DKIM2 section 2.2 quickly if at all.
(2) See 2.4.1. Many mailing lists also remove and discard "problematic" MIME parts, and transform top-level text/html to text/plain, but do not satisfy the conditions that make this less problematic for "security gateways". So such mailing lists are likely to have trouble with any recipients that bounce mail that cannot be restored to original signed content. This is *worse* than DMARC because the draft provides no way to recognize such sites, nor any way to remedy the mail except to pass through content that violates list policy.
Steve
Footnotes: [1] https://www.ietf.org/archive/id/draft-adams-arc-experiment-conclusion-00.htm...
[2] https://datatracker.ietf.org/doc/html/draft-ietf-dkim-dkim2-motivation-02
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
participants (5)
-
Alexander Inzinger-Zrock -
Dave Nathanson -
Joly MacFie -
Mark Sapiro -
Stephen J. Turnbull