Re: [mlmmj] What do you do with Gmail accounts?
Konstantin Ryabitsev <[email protected]> Tue, 5 Mar 2024 11:04:22 -0500
| Newsgroups | org.mlmmj.mlmmj |
|---|---|
| Message-ID | <20240305-futuristic-arcane-potoo-f2bb4f@meerkat> |
On Tue, Mar 05, 2024 at 11:35:33AM +0100, Christof Thalhofer wrote: > Hello, > > I migrated a couple of Mls from Mailman2 to Mlmmj (1.3). > > With MM2 we did Reply-To-Munging (replaced the original Reply-To header with > 'Reply-To: list@listserver'. > > Mlmmj does not allow this. I can add 'Reply-To: address@list' but I cannot > delete 'Reply-To: from@home' with delheaders because then Mlmmj also removes > the 'From:' header ... why ??? > > So if I set 'Reply-To: list@listserver' in customheaders there are often > two 'Reply-To:' in the headers of an outgoing mail: > > 'Reply-To: from@home' (set by the author of the mail) > 'Reply-To: list@listserver' (set by Mlmmj) > > which causes Gmail to bounce that mail. > > Now we have the problem with a mailinglist that Gmail does not have a > 'reply-to-list'-button. > > It has the options 'reply' and 'reply to all'. > > 'reply' answers to the address in 'From:' and the mail doesn't go to the > list. > > 'reply to all' answers to the addresses in 'From:' and 'List-Post:' creating > dupes at the person whose mail was answered. > > Reply-To-munging seems to be the only way to give Gmail-users the > possibility to answer direct to the list. But is is impossible to be done in > Mlmmj. > > What to do? If you rewrite headers such as Reply-To, this will almost certainly invalidate the DKIM signature of the original message if you also keep the original "From:" header. If you want to modify any signed headers, you *must* rewrite the From: address. There are only two possible solutions when it comes to mailing lists these days: 1. Don't touch any headers, only add List-* headers (e.g. List-ID) 2. If you do change any headers, you *must* also rewrite the original From: header (e.g. by moving it to X-Original-From:), because otherwise you will violate DKIM/DMARC policies of the sender's domain -K