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.
1. Postfix's 'recipient_delimiter' *must* be set to "+", "+-", or "-+".
2. Mailman's 'verp_delimiter' *must* be set to "+".
3. Mailman's 'verp_confirmations' *should* be set to "yes".
4. 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.
1. Mailman notices a new address that needs to be confirmed (eg, a
subscription)
2. 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
3. Subscriber replies by email to ${list}-confirm+${40_hexchar_cookie}
4. Postfix receives subscriber's reply
5. Postfix tries to deliver to ${list}-confirm+${40_hexchar_cookie} and
fails to find it anywhere in its address databases
6. 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
7. 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
_______________________________________________
Mailman-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
Archived at:
https://lists.mailman3.org/archives/list/[email protected]/message/KIZ4WUPELLOT3F5KOA55MST4QB4DD2N3/
This message sent to [email protected]
