Christian via Mailman-Users writes:
Hi Michael
I don’t think you have a problem here. The "From:"-address will probably look like this:
"Firstname Lastname username@domain.com" <listname@listdomain.com>
This isn't true. "domain.com" is replaced by "---" because it's believed that having more than one address in any part of From (including the display name and comments) is a spam indicator at many recipients.
This means that the original sender’s address is in the "realname" (or "comment")-part of the address field. The sender appears still to be <listname@listdomain.com> and replies should go there - unless your list is set to deliver replies only to the original sender (as it is here in the Mailman list).
It's more complicated than that. We try very hard to ensure there is a machine-replyable address for the author. So when either of the "munge From" options is set, the author's address will be added to Reply-To. The only case where this is not done is for an anonymous list, but that's probably extremely unattractive.
After years of working fine, we'd recently been having bouncing problems specifically with gmail addresses.
I'm surprised you have problems specifically with Gmail. Their DMARC policy is still p=none, so DMARC is not why they're bouncing. Lack of SPF seems more likely. AOL and Yahoo! are much more comon sources of problems.
I changed from_is_list to Munge From but now the reply to headers have both the list address and the original sender's address. So I assume the original sender gets sent two copies of responses, one from the list and the other directly to them.
That is correct.
I'm hoping I can fix this easily.
Getting rid of the poster address in Reply-To requires patching the code. We are not going to change this in Mailman 2, for sure. The general sense of the developers is that it's a bad idea to completely remove the poster's address, and they can work around with no-dupes, so we probably will not change it in Mailman 3 either.
Depending on the size of the list, it may be easy. Go into the Membership Management | Membership List section, and set the no-dupes attribute on for everybody. If this would be annoying to impossible because the list is very large, Mark may have script for this but your provider would have to run it.
This is not a proper fix, because it's implemented by not sending the post to subscribers whose addresses are already in To or CC. There's no way for Mailman to be sure they actually get it (although they almost always do), and of course they lose any decorations (such as useful links in the footer).
You can partially mitigate the problem by setting from_is_list to "No", and instead setting dmarc_moderation_action to "Munge From". Any users from DMARC p=none domains will not suffer from duplicates. However, AOL, Yahoo!, and several other major email providers set p=reject, and users at those providers will suffer from duplicates unless they set no-dupes.
If you have access to a DNS query utility, you can find out whether common subscriber domains have a p=reject or p=quarantine policy by prefixing the domain with "_dmarc." and querying the TXT record. For example, with the popular 'host' program for gmail.com addresses, the query looks like this:
% host -t TXT _dmarc.gmail.com _dmarc.gmail.com descriptive text "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com" %
You're looking for the "p=" attribute. The "sp=" attribute isn't relevant. On Un*x hosts, you may also have the nslookup or dig utilities. The query template suggested above is not 100% reliable because of variations in email addressing to the same domain, but it's probably 95% reliable