Christian H. Kuhn via Mailman-users writes:
i used - as recipient_delimiter for a long time. Now it was brought to my attention that + is the current default, so i changed in the main.cfg of all postfix instances to recipient_delimiter = +-
Now of course
Do you mean that confirmation emails worked in Mailman 3 before changing recipient_delimiter, and now they fail?
confirmaiton mails for mailing list qtest to qtest-request@domain fail, because the recipient qtest is unknown.
I don't understand. You say that "qtest" is the mailing list, but that *must* be known, otherwise the mailing list is unusable.
Why do you think "qtest" is unknown? Please provide the log or error message, and name the program or module reporting the error. Or do you mean "qtest-request" is unknown? But that should be explicitly listed in postfix_lmtp along with "qtest".
Are you sure the confirmation message is addressed to "qtest-request"? Confirmation messages should *not* be addressed to "qtest-request". They should be addressed to "qtest-confirm+$40_hexchar_cookie" (or perhaps just "qtest-confirm" if verp_confirmations = no). "qtest-request" should be used by users trying to issue commands to Mailman via email, and a quick grep suggests that it is *never* generated by Mailman except for help text and in the postfix_lmtp file.
I guess it's possible that the subscriber is manually addressing a confirmation to "qtest-request", but that should be delivered, and return an error message to sender unless accidentally the message contains a valid command (join, leave, who, help).
I changed [mailman] listname_chars: [_.0-9a-z]
This is likely to mess you up, because it's very common to have "-" in the List-Post address local part as in "mailman-users". You can insist on using "_" instead of "-" in list names. I think that will work, but "-" is so much more common that users are likely to make mistakes when typing out addresses.
[mta] verp_delimiter: +-
This is actually almost a no-op. "+" is hard-coded throughout the verp and confirmation address parsing code. So verp_delimiter must have "+" as the first character. I recommend changing it to "+" (without the quotation marks) or removing that stanza entirely. (issue mailman#1274)
but still the generated address is qtest-request@domain. Is it possible to generate emails as qtest_request@domain?
That cannot be changed without multiple changes to the Python code.
If not, would the owner_request_special of postfix help?
I don't think so. If I remember correctly, the special address treatment is for *prefixed* "owner-" or "request-". Anyway, that feature has very low priority and I think it sends the message to the wrong local address.
Without more information, it's impossible to have any confidence, but I suspect this is either a Postfix configuration problem or a mismatch in Postfix-Mailman configuration.
- Postfix's 'recipient_delimiter' *must* be set to "+", "+-", or "-+".
- Mailman's 'verp_delimiter' *must* be set to "+".
- Mailman's 'verp_confirmations' *should* be set to "yes".
- Postfix's 'transport_maps' *must* point to Mailman's 'postfix_lmtp' database; there is a configuration for 'postfix_domains' as well.
Here's how this is supposed to work.
- Mailman notices a new address that needs to be confirmed (eg, a subscription)
- Mailman sends a confirmation request from ${list}-bounces to ${new_address} with Reply-To set to $list-confirm+${40_hexchar_cookie}, the cookie in the Subject, and a clickable link containing the cookie in the body
- Subscriber replies by email to ${list}-confirm+${40_hexchar_cookie}
- Postfix receives subscriber's reply
- Postfix tries to deliver to ${list}-confirm+${40_hexchar_cookie} and fails to find it anywhere in its address databases
- Postfix checks recipient_delimiter, finds '+' in it, and strips off +${40_hexchar_cookie}, then tries to deliver to ${list}-confirm, which it finds in postfix_lmtp.db, and sends to Mailman's LMTP runner
- lmtp.py recognizes ${list}-confirm and puts the message in the 'in' queue, and Mailman takes it from there.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan