Re: integrating mm3 with postfix / lmtp
On 10/25/2017 05:41 PM, Fabian A. Santiago wrote:
No to the domains part and I think virtual alias maps is needed:
mail postfix/trivial-rewrite[19445]: warning: do not list domain xxx in BOTH virtual_mailbox_domains and relay_domains Oct 25 20:39:19 mail postfix/trivial-rewrite[19445]: warning: do not list domain xxx in BOTH virtual_mailbox_domains and relay_domains Oct 25 20:39:19 mail postfix/submission/smtpd[19441]: NOQUEUE: reject: RCPT from pool-108-53-239-102.nwrknj.fios.verizon.net[108.53.239.102]: 550 5.1.1 <test123@xxx>: Recipient address rejected: User unknown in virtual mailbox table; from=<fsantiago@xxx> to=<test123@xxx> proto=ESMTP helo=<[10.0.0.29]>
(above slightly sanitized for return to the list)
The issue here is your list domain cannot be a virtual_mailbox_domain or a virtual_alias_domain.
I have the same issue on mail.python.org where we have both Mailman 2 and Mailman 3 lists @python.org. and python.org is a virtual_alias_domain.
I have a group of MRs for a branch that implements "alias_domains" to deal with this.
Basically it works by creating another (virtual_alias_maps) postfix_vmap mapping to map list addresses @python.org to addresses @x.python.org. Then the postfix_domains and postfix_lmtp maps have the x.python.org domain and there is a patch to mailman/runners/lmtp.py to map the x.python.org domain back to python.org.
The various MRs are <https://gitlab.com/mailman/mailman/merge_requests/202> for the core, <https://gitlab.com/mailman/mailmanclient/merge_requests/18> for the REST bindings used by Postorius and <https://gitlab.com/mailman/postorius/merge_requests/186> to be able to set an alias_domain via Postorius.
That's not all implemented at mail.python.org. What's there is the basic Postfix config, a bash script the generate the new mappings from the old and a simple patch to mailman/runners/lmtp.py.
So, the bottom line is it can be done and it's in process, but it won't really be supported until Mailman 3.2. In the mean time, you just need to have a separate domain for your lists that isn't a virtual_*_domain.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On October 25, 2017 9:13:20 PM EDT, Mark Sapiro <mark@msapiro.net> wrote:
On 10/25/2017 05:41 PM, Fabian A. Santiago wrote:
No to the domains part and I think virtual alias maps is needed:
mail postfix/trivial-rewrite[19445]: warning: do not list domain xxx
Oct 25 20:39:19 mail postfix/trivial-rewrite[19445]: warning: do not
Oct 25 20:39:19 mail postfix/submission/smtpd[19441]: NOQUEUE: reject: RCPT from
in BOTH virtual_mailbox_domains and relay_domains list domain xxx in BOTH virtual_mailbox_domains and relay_domains pool-108-53-239-102.nwrknj.fios.verizon.net[108.53.239.102]: 550 5.1.1 <test123@xxx>: Recipient address rejected: User unknown in virtual mailbox table; from=<fsantiago@xxx> to=<test123@xxx> proto=ESMTP helo=<[10.0.0.29]>
(above slightly sanitized for return to the list)
The issue here is your list domain cannot be a virtual_mailbox_domain or a virtual_alias_domain.
I have the same issue on mail.python.org where we have both Mailman 2 and Mailman 3 lists @python.org. and python.org is a virtual_alias_domain.
I have a group of MRs for a branch that implements "alias_domains" to deal with this.
Basically it works by creating another (virtual_alias_maps) postfix_vmap mapping to map list addresses @python.org to addresses @x.python.org. Then the postfix_domains and postfix_lmtp maps have the x.python.org domain and there is a patch to mailman/runners/lmtp.py to map the x.python.org domain back to python.org.
The various MRs are <https://gitlab.com/mailman/mailman/merge_requests/202> for the core, <https://gitlab.com/mailman/mailmanclient/merge_requests/18> for the REST bindings used by Postorius and <https://gitlab.com/mailman/postorius/merge_requests/186> to be able to set an alias_domain via Postorius.
That's not all implemented at mail.python.org. What's there is the basic Postfix config, a bash script the generate the new mappings from the old and a simple patch to mailman/runners/lmtp.py.
So, the bottom line is it can be done and it's in process, but it won't really be supported until Mailman 3.2. In the mean time, you just need to have a separate domain for your lists that isn't a virtual_*_domain.
Ok thanks. At least I have a clear answer now. Any ETA on 3.2 in mind yet?
Thanks,
Fabian S.
OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC
On October 25, 2017 9:17:33 PM EDT, "Fabian A. Santiago" <fsantiago@garbage-juice.com> wrote:
On October 25, 2017 9:13:20 PM EDT, Mark Sapiro <mark@msapiro.net> wrote:
On 10/25/2017 05:41 PM, Fabian A. Santiago wrote:
No to the domains part and I think virtual alias maps is needed:
mail postfix/trivial-rewrite[19445]: warning: do not list domain xxx
Oct 25 20:39:19 mail postfix/trivial-rewrite[19445]: warning: do not
Oct 25 20:39:19 mail postfix/submission/smtpd[19441]: NOQUEUE: reject: RCPT from
in BOTH virtual_mailbox_domains and relay_domains list domain xxx in BOTH virtual_mailbox_domains and relay_domains pool-108-53-239-102.nwrknj.fios.verizon.net[108.53.239.102]: 550 5.1.1 <test123@xxx>: Recipient address rejected: User unknown in virtual mailbox table; from=<fsantiago@xxx> to=<test123@xxx> proto=ESMTP helo=<[10.0.0.29]>
(above slightly sanitized for return to the list)
The issue here is your list domain cannot be a virtual_mailbox_domain or a virtual_alias_domain.
I have the same issue on mail.python.org where we have both Mailman 2 and Mailman 3 lists @python.org. and python.org is a virtual_alias_domain.
I have a group of MRs for a branch that implements "alias_domains" to deal with this.
Basically it works by creating another (virtual_alias_maps) postfix_vmap mapping to map list addresses @python.org to addresses @x.python.org. Then the postfix_domains and postfix_lmtp maps have the x.python.org domain and there is a patch to mailman/runners/lmtp.py to map the x.python.org domain back to python.org.
The various MRs are <https://gitlab.com/mailman/mailman/merge_requests/202> for the core, <https://gitlab.com/mailman/mailmanclient/merge_requests/18> for the REST bindings used by Postorius and <https://gitlab.com/mailman/postorius/merge_requests/186> to be able to set an alias_domain via Postorius.
That's not all implemented at mail.python.org. What's there is the basic Postfix config, a bash script the generate the new mappings from the old and a simple patch to mailman/runners/lmtp.py.
So, the bottom line is it can be done and it's in process, but it won't really be supported until Mailman 3.2. In the mean time, you just need to have a separate domain for your lists that isn't a virtual_*_domain.
Ok thanks. At least I have a clear answer now. Any ETA on 3.2 in mind yet?
Thanks,
Fabian S.
OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC
Mailman-users mailing list mailman-users@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
Mark,
Ok I have it almost perfectly working now having taken your direction and configuring a unique domain not in my email system already.
But in my testing, I replied to a subscription confirmation message and received back an undeliverable looping email error message from postfix. Any clues there you can offer? I can post to the list from any email added via the admin console. The test subscriber address was local to my server. From an outside address, same error.
Once I registered the new email domain, I reverted my postfix config back to the default suggested by maxking's docker instructions.
https://github.com/maxking/docker-mailman
Thanks.
--
Thanks,
Fabian S.
OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC
On 10/26/2017 06:16 PM, Fabian A. Santiago wrote:
But in my testing, I replied to a subscription confirmation message and received back an undeliverable looping email error message from postfix. Any clues there you can offer? I can post to the list from any email added via the admin console. The test subscriber address was local to my server. From an outside address, same error.
This usually means that postfic is trying to deliver to an address and the message already has a Delivered-To: header with that address.
What are the headers of the "looping" message in the report? What are the Postfix log messages related to that message?
Once I registered the new email domain, I reverted my postfix config back to the default suggested by maxking's docker instructions.
I have essentially no knowledge of the docker container images, so I can't be much help with issues specific to them.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Thu, Oct 26, 2017, at 06:39 PM, Mark Sapiro wrote:
On 10/26/2017 06:16 PM, Fabian A. Santiago wrote:
But in my testing, I replied to a subscription confirmation message and received back an undeliverable looping email error message from postfix. Any clues there you can offer? I can post to the list from any email added via the admin console. The test subscriber address was local to my server. From an outside address, same error.
This usually means that postfic is trying to deliver to an address and the message already has a Delivered-To: header with that address.
What are the headers of the "looping" message in the report? What are the Postfix log messages related to that message?
Once I registered the new email domain, I reverted my postfix config back to the default suggested by maxking's docker instructions.
I have essentially no knowledge of the docker container images, so I can't be much help with issues specific to them.
The Postfix integration in container images is basically just using regex instead of hash maps and everything else is same.
I do remember atleast one other person facing a similar issue where Postfix wouldn't accept listname+token@domain addresses with our regex. I am thinking this is the same issue.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-users mailing list mailman-users@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
-- Abhilash Raj maxking@asynchronous.in
On 10/26/2017 06:44 PM, Abhilash Raj wrote:
I do remember atleast one other person facing a similar issue where Postfix wouldn't accept listname+token@domain addresses with our regex. I am thinking this is the same issue.
If that's the issue, it's <https://gitlab.com/mailman/mailman/issues/401> and the fix is in this MR <https://gitlab.com/mailman/mailman/merge_requests/323>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On October 26, 2017 9:39:06 PM EDT, Mark Sapiro <mark@msapiro.net> wrote:
On 10/26/2017 06:16 PM, Fabian A. Santiago wrote:
But in my testing, I replied to a subscription confirmation message
and received back an undeliverable looping email error message from postfix. Any clues there you can offer? I can post to the list from any email added via the admin console. The test subscriber address was local to my server. From an outside address, same error.
This usually means that postfic is trying to deliver to an address and the message already has a Delivered-To: header with that address.
What are the headers of the "looping" message in the report? What are the Postfix log messages related to that message?
Once I registered the new email domain, I reverted my postfix config back to the default suggested by maxking's docker instructions.
I have essentially no knowledge of the docker container images, so I can't be much help with issues specific to them.
Return-Path: <MAILER-DAEMON> Delivered-To: turtl@deviltracks.net Received: by mail.garden-life.org (Postfix) id 39F6C2055; Thu, 26 Oct 2017 21:02:17 -0400 (EDT) Date: Thu, 26 Oct 2017 21:02:17 -0400 (EDT) From: MAILER-DAEMON@mail.garden-life.org (Mail Delivery System) Subject: Undelivered Mail Returned to Sender To: turtl@deviltracks.net Auto-Submitted: auto-replied MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="2D7231948.1509066137/mail.garden-life.org" Content-Transfer-Encoding: 7bit Message-Id: <20171027010217.39F6C2055@mail.garden-life.org>
This is a MIME-encapsulated message.
--2D7231948.1509066137/mail.garden-life.org Content-Description: Notification Content-Type: text/plain; charset=us-ascii
This is the mail system at host mail.garden-life.org.
I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can delete your own text from the attached returned message.
The mail system<test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685@gjb-online.com>: mail for gjb-online.com loops back to myself
--2D7231948.1509066137/mail.garden-life.org Content-Description: Delivery report Content-Type: message/delivery-status
Reporting-MTA: dns; mail.garden-life.org X-Postfix-Queue-ID: 2D7231948 X-Postfix-Sender: rfc822; turtl@deviltracks.net Arrival-Date: Thu, 26 Oct 2017 21:02:17 -0400 (EDT)
Final-Recipient: rfc822; test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685@gjb-online.com Original-Recipient: rfc822;test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685@gjb-online.com Action: failed Status: 5.4.6 Diagnostic-Code: X-Postfix; mail for gjb-online.com loops back to myself
--2D7231948.1509066137/mail.garden-life.org Content-Description: Undelivered Message Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit
Return-Path: <turtl@deviltracks.net> Received: from mail.garden-life.org (localhost [127.0.0.1]) by mail.garden-life.org (Postfix) with ESMTP id 2D7231948 for <test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685@gjb-online.com>; Thu, 26 Oct 2017 21:02:17 -0400 (EDT) Authentication-Results: mail.garden-life.org (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=garden-life.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garden-life.org; h=references:in-reply-to:to:subject:subject:message-id:from :from:x-mailer:content-transfer-encoding:content-type :content-type:date:date:mime-version; s=dkim; t=1509066135; x= 1509930136; bh=k85upIKMt3yA1zcaSrQxE349DcmKTq86MMRdi7hh2yw=; b=X 2phB5a1/LGy0J5YIHZTnbXOeoJ55wkcBrFax3cTvvXAAbfZEBsV3BLZ9Z25GdncT CK7b3FU8He/70UAKZtcjreE1AP/hB89yX63xNSqFu2iULKIYMOhWaE/eWl897VhN NIR1mONlrQxOUf5+o16As9WPdbAiEO/TKNMUpuyk+A= X-Virus-Scanned: amavisd-new at mail.garden-life.org X-Spam-Flag: NO X-Spam-Score: 6.117 X-Spam-Level: ****** X-Spam-Status: No, score=6.117 tagged_above=2 required=6.2 tests=[RCVD_IN_PBL=3.558, RCVD_IN_RP_RNBL=1.284, RCVD_IN_SORBS_DUL=0.001, RDNS_NONE=1.274] autolearn=no autolearn_force=no Received: from mail.garden-life.org ([127.0.0.1]) by mail.garden-life.org (mail.garden-life.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3zCxRxppUkZt for <test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685@gjb-online.com>; Thu, 26 Oct 2017 21:02:15 -0400 (EDT) Received: from rainmail.deviltracks.net (keys.fspproductions.biz [IPv6:2600:3c03::f03c:91ff:fe24:1eeb]) by mail.garden-life.org (Postfix) with ESMTPSA id 1116A2F1 for <test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685@gjb-online.com>; Thu, 26 Oct 2017 21:02:15 -0400 (EDT) Mime-Version: 1.0 Date: Fri, 27 Oct 2017 01:02:14 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: RainLoop/1.11.3 From: turtl@deviltracks.net Message-ID: <4e5829300419cfb7bf13d5a0d9ebebd1@deviltracks.net> Subject: Re: confirm b7322edad83ae7ec99cfc5100161c7062d2c7685 To: test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685@gjb-online.com In-Reply-To: <150906420646.31.12186705534373041145@mailman-core> References: <150906420646.31.12186705534373041145@mailman-core> X-Originating-IP: 108.53.239.102
October 26, 2017 8:30 PM, test123-confirm+b7322edad83ae7ec99cfc5100161c70= 62d2c7685@gjb-online.com=0Awrote:=0A=0A> Email Address Registration Confi= rmation=0A> =0A> Hello, this is the GNU Mailman server at gjb-online.com.= =0A> =0A> We have received a registration request for the email address= =0A> =0A> turtl@deviltracks.net=0A> =0A> Before you can start using GNU M= ailman at this site, you must first confirm=0A> that this is your email a= ddress. You can do this by replying to this message,=0A> keeping the Subj= ect header intact.=0A> =0A> If you do not wish to register this email add= ress, simply disregard this=0A> message. If you think you are being malic= iously subscribed to the list, or=0A> have any other questions, you may c= ontact=0A> =0A> test123-owner@gjb-online.com
--2D7231948.1509066137/mail.garden-life.org--
Logs:
mail amavis[1576]: (01576-09) Passed CLEAN {RelayedInternal}, ORIGINATING LOCAL [2600:3c03::f03c:91ff:fe24:1eeb]:33512 [2600:3c03::f03c:91ff:fe24:1eeb] <turtl@deviltracks.net> -> <test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685@gjb-online.com>, Queue-ID: 15BD218EE, Message-ID: <09b6ea7c3203e7357e4e996c352223d0@deviltracks.net>, mail_id: UgTlYoHupO-Z, Hits: 6.117, size: 1663, queued_as: 928292055, dkim_new=dkim:garden-life.org, 451 ms, Tests: [RCVD_IN_PBL=3.558,RCVD_IN_RP_RNBL=1.284,RCVD_IN_SORBS_DUL=0.001,RDNS_NONE=1.274] Oct 26 21:47:44 mail postfix/smtp-amavis/smtp[19971]: 15BD218EE: to=<test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685@gjb-online.com>, relay=127.0.0.1[127.0.0.1]:10026, delay=0.64, delays=0.18/0/0/0.46, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 928292055) Oct 26 21:47:44 mail postfix/qmgr[1240]: 15BD218EE: removed Oct 26 21:47:44 mail postfix/smtp[20025]: 928292055: to=<test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685@gjb-online.com>, relay=none, delay=0.04, delays=0.01/0.02/0/0, dsn=5.4.6, status=bounced (mail for gjb-online.com loops back to myself) Oct 26 21:47:44 mail postfix/cleanup[19953]: 9E63E18EE: message-id=<20171027014744.9E63E18EE@mail.garden-life.org> Oct 26 21:47:44 mail postfix/qmgr[1240]: 9E63E18EE: from=<>, size=5273, nrcpt=1 (queue active) Oct 26 21:47:44 mail postfix/bounce[20027]: 928292055: sender non-delivery notification: 9E63E18EE Oct 26 21:47:44 mail postfix/qmgr[1240]: 928292055: removed Oct 26 21:47:44 mail postfix/pipe[19986]: 9E63E18EE: to=<turtl@deviltracks.net>, relay=dovecot, delay=0.03, delays=0/0/0/0.03, dsn=2.0.0, status=sent (delivered via dovecot service) Oct 26 21:47:44 mail postfix/qmgr[1240]: 9E63E18EE: removed [root@mail ~]#
--
Thanks,
Fabian S.
OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC
On 10/26/2017 06:49 PM, Fabian A. Santiago wrote: ...
To: test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685@gjb-online.com
There is an issue in Mailman 3.1 with regexp tables not working for addresses of this form. As I posted at <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...>, see <https://gitlab.com/mailman/mailman/issues/401> and <https://gitlab.com/mailman/mailman/merge_requests/323>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On October 26, 2017 10:05:11 PM EDT, Mark Sapiro <mark@msapiro.net> wrote:
On 10/26/2017 06:49 PM, Fabian A. Santiago wrote: ...
To: test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685@gjb-online.com
There is an issue in Mailman 3.1 with regexp tables not working for addresses of this form. As I posted at <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...>, see <https://gitlab.com/mailman/mailman/issues/401> and <https://gitlab.com/mailman/mailman/merge_requests/323>.
That was it. Perfect. I manually modified my regexp map and it works now. Excellent and Thank you. You're the man. Does mm3 ever refresh those maps or only as I add new domains / lists?
--
Thanks,
Fabian S.
OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC
On October 26, 2017 7:30:35 PM PDT, "Fabian A. Santiago" <fsantiago@garbage-juice.com> wrote:
That was it. Perfect. I manually modified my regexp map and it works now. Excellent and Thank you. You're the man. Does mm3 ever refresh those maps or only as I add new domains / lists?
Only when you make changes to domains or lists.
-- Mark Sapiro <mark@msapiro.net> Sent from my Not_an_iThing with standards compliant, open source software.
October 26, 2017 11:07 PM, "Mark Sapiro" <mark@msapiro.net> wrote:
On October 26, 2017 7:30:35 PM PDT, "Fabian A. Santiago" <fsantiago@garbage-juice.com> wrote:
That was it. Perfect. I manually modified my regexp map and it works now. Excellent and Thank you. You're the man. Does mm3 ever refresh those maps or only as I add new domains / lists?
Only when you make changes to domains or lists.
-- Mark Sapiro <mark@msapiro.net> Sent from my Not_an_iThing with standards compliant, open source software.
Mark,
I've noticed that even simply restarting the mm3 components those alias maps get rewritten and the problem returns until I can manually edit it.
--
Thanks,
Fabian S.
OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC
On 11/03/2017 08:29 AM, Fabian A. Santiago wrote:
I've noticed that even simply restarting the mm3 components those alias maps get rewritten and the problem returns until I can manually edit it.
I don't know how this works in the docker container or what you mean by "restarting the mm3 components". I do know that
bin/mailman {stop|start|restart|reopen}
does not rebuild the postfix maps. Only
bin/mailman aliases
or creating|deleting a list does that.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Fri, Nov 3, 2017, at 08:29 AM, Fabian A. Santiago wrote:
October 26, 2017 11:07 PM, "Mark Sapiro" <mark@msapiro.net> wrote:
On October 26, 2017 7:30:35 PM PDT, "Fabian A. Santiago" <fsantiago@garbage-juice.com> wrote:
That was it. Perfect. I manually modified my regexp map and it works now. Excellent and Thank you. You're the man. Does mm3 ever refresh those maps or only as I add new domains / lists?
Only when you make changes to domains or lists.
-- Mark Sapiro <mark@msapiro.net> Sent from my Not_an_iThing with standards compliant, open source software.
Mark,
I've noticed that even simply restarting the mm3 components those alias maps get rewritten and the problem returns until I can manually edit it.
Yeah, that is true. Transport maps are re-generated everytime the container restarts.
I don't think think there is any way around this right now :(
--
Thanks,
Fabian S.
OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC
Mailman-users mailing list mailman-users@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
-- Abhilash Raj maxking@asynchronous.in
There is a way around it!
I have had two issues with the the maxking docker image. One is that the regexp is not working properly. I reported that, and it has been fixed in newer code. My other problem is that the docker image creates a user, mailman, that receives uid 103. Well, uid 103 on my system is already taken by systemd-bus-proxy (grep 103 /etc/passwd returns "systemd-bus-proxy:x:103:105:systemd Bus Proxy,,,:/run/systemd:/bin/false").
My solution includes downloading the corrected postfix.py, and replacing the Dockerfile. I put the postfix.py in <docker-mailman>/core/assets/.
My Dockerfile: FROM maxking/mailman-core
RUN grep mailman /etc/passwd && grep mailman /etc/group
&& deluser mailman
&& addgroup -S -g900 mailman
&& adduser -S -u900 mailman mailman
&& grep mailman /etc/passwd && grep mailman /etc/group
COPY assets/postfix.py
/usr/local/lib/python3.6/site-packages/mailman/mta/postfix.py
I then run docker build (with -t parameter, you must look up that yourself). I use a different name for my images, so I end up with (note, there are two tags per image): root@mailer:/home/mailman/docker/docker-mailman_mods/core# docker images REPOSITORY TAG IMAGE ID CREATED SIZE local/mailman_core_900 20171110_2 9649e84767e1 2 days ago 176MB local/mailman_core_900 latest 9649e84767e1 2 days ago 176MB local/mailman_web_900 20171110_2 07a9b3d7ddd6 2 days ago 247MB local/mailman_web_900 latest 07a9b3d7ddd6 2 days ago 247MB
I do the same with the web image, as I need to change the user there, too.
Then, in docker-compose.yaml, I change the line(s) referring to the image name(s):
services: mailman-core: image: local/mailman_core_900 container_name: mailman-core hostname: mailman-core
mailman-web: image: local/mailman_web_900 container_name: mailman-web hostname: mailman-web
I don't know if this is a good solution, but at least it fixes some serious issues with the 3.1's postfix integration that wouldn't otherwise be fixed until the 3.2 release. The bottom line is that it works for me, but it adds an additional layer of complication.
2017-11-03 19:40 GMT+01:00 Abhilash Raj <maxking@asynchronous.in>:
On Fri, Nov 3, 2017, at 08:29 AM, Fabian A. Santiago wrote:
October 26, 2017 11:07 PM, "Mark Sapiro" <mark@msapiro.net> wrote:
On October 26, 2017 7:30:35 PM PDT, "Fabian A. Santiago" < fsantiago@garbage-juice.com> wrote:
That was it. Perfect. I manually modified my regexp map and it works now. Excellent and Thank you. You're the man. Does mm3 ever refresh those maps or only as I add new domains / lists?
Only when you make changes to domains or lists.
-- Mark Sapiro <mark@msapiro.net> Sent from my Not_an_iThing with standards compliant, open source software.
Mark,
I've noticed that even simply restarting the mm3 components those alias maps get rewritten and the problem returns until I can manually edit it.
Yeah, that is true. Transport maps are re-generated everytime the container restarts.
I don't think think there is any way around this right now :(
-- Abhilash Raj maxking@asynchronous.in
Mailman-users mailing list mailman-users@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
On Nov 13 2017, at 1:34 am, Thor Atle Rustad <thor.rustad@gmail.com> wrote:
There is a way around it!
I have had two issues with the the maxking docker image. One is that the regexp is not working properly. I reported that, and it has been fixed in newer code. My other problem is that the docker image creates a user, mailman, that receives uid 103. Well, uid 103 on my system is already taken by systemd-bus-proxy (grep 103 /etc/passwd returns "systemd-bus-proxy:x:103:105:systemd Bus Proxy,,,:/run/systemd:/bin/false").
Containers usually run with uid namespace, so it doesn't really matter what uid is used outside of container.
Unless, you mount /etc/shadow from host in to the container, which isn't really needed for the images.
My solution includes downloading the corrected postfix.py, and replacing the Dockerfile. I put the postfix.py in <docker-mailman>/core/assets/.
My Dockerfile: FROM maxking/mailman-core
RUN grep mailman /etc/passwd && grep mailman /etc/group
&& deluser mailman
&& addgroup -S -g900 mailman
&& adduser -S -u900 mailman mailman
&& grep mailman /etc/passwd && grep mailman /etc/group COPY assets/postfix.py /usr/local/lib/python3.6/site-packages/mailman/mta/postfix.pyI then run docker build (with -t parameter, you must look up that yourself). I use a different name for my images, so I end up with (note, there are two tags per image): root@mailer:/home/mailman/docker/docker-mailman_mods/core# docker images REPOSITORY TAG IMAGE ID CREATED SIZE local/mailman_core_900 20171110_2 9649e84767e1 2 days ago 176MB local/mailman_core_900 latest 9649e84767e1 2 days ago 176MB local/mailman_web_900 20171110_2 07a9b3d7ddd6 2 days ago 247MB local/mailman_web_900 latest 07a9b3d7ddd6 2 days ago 247MB
I do the same with the web image, as I need to change the user there, too.
Then, in docker-compose.yaml, I change the line(s) referring to the image name(s):
services: mailman-core: image: local/mailman_core_900 container_name: mailman-core hostname: mailman-core
mailman-web: image: local/mailman_web_900 container_name: mailman-web hostname: mailman-web
I don't know if this is a good solution, but at least it fixes some serious issues with the 3.1's postfix integration that wouldn't otherwise be fixed until the 3.2 release. The bottom line is that it works for me, but it adds an additional layer of complication.
2017-11-03 19:40 GMT+01:00 Abhilash Raj <maxking@asynchronous.in (mailto:maxking@asynchronous.in)>:
On Fri, Nov 3, 2017, at 08:29 AM, Fabian A. Santiago wrote:
October 26, 2017 11:07 PM, "Mark Sapiro" <mark@msapiro.net (mailto:mark@msapiro.net)> wrote:
On October 26, 2017 7:30:35 PM PDT, "Fabian A. Santiago" <fsantiago@garbage-juice.com (mailto:fsantiago@garbage-juice.com)> wrote:
That was it. Perfect. I manually modified my regexp map and it works now. Excellent and Thank you. You're the man. Does mm3 ever refresh those maps or only as I add new domains / lists?
Only when you make changes to domains or lists.
-- Mark Sapiro <mark@msapiro.net (mailto:mark@msapiro.net)> Sent from my Not_an_iThing with standards compliant, open source software.
Mark,
I've noticed that even simply restarting the mm3 components those alias maps get rewritten and the problem returns until I can manually edit it.
Yeah, that is true. Transport maps are re-generated everytime the container restarts.
I don't think think there is any way around this right now :(
-- Abhilash Raj maxking@asynchronous.in (mailto:maxking@asynchronous.in)
Mailman-users mailing list mailman-users@mailman3.org (mailto:mailman-users@mailman3.org) https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
I will try to get a grip on uid namespaces then...
2017-11-13 10:49 GMT+01:00 Abhilash Raj <maxking@asynchronous.in>:
On Nov 13 2017, at 1:34 am, Thor Atle Rustad <thor.rustad@gmail.com> wrote:
There is a way around it!
I have had two issues with the the maxking docker image. One is that the regexp is not working properly. I reported that, and it has been fixed in newer code. My other problem is that the docker image creates a user, mailman, that receives uid 103. Well, uid 103 on my system is already taken by systemd-bus-proxy (grep 103 /etc/passwd returns "systemd-bus-proxy:x:103:105:systemd Bus Proxy,,,:/run/systemd:/bin/ false").
Containers usually run with uid namespace, so it doesn't really matter what uid is used outside of container.
Unless, you mount /etc/shadow from host in to the container, which isn't really needed for the images.
My solution includes downloading the corrected postfix.py, and replacing the Dockerfile. I put the postfix.py in <docker-mailman>/core/assets/.
My Dockerfile: FROM maxking/mailman-core
RUN grep mailman /etc/passwd && grep mailman /etc/group
&& deluser mailman
&& addgroup -S -g900 mailman
&& adduser -S -u900 mailman mailman
&& grep mailman /etc/passwd && grep mailman /etc/group COPY assets/postfix.py /usr/local/lib/python3.6/site- packages/mailman/mta/postfix.pyI then run docker build (with -t parameter, you must look up that yourself). I use a different name for my images, so I end up with (note, there are two tags per image): root@mailer:/home/mailman/docker/docker-mailman_mods/core# docker images REPOSITORY TAG IMAGE ID CREATED SIZE local/mailman_core_900 20171110_2 9649e84767e1 2 days ago 176MB local/mailman_core_900 latest 9649e84767e1 2 days ago 176MB local/mailman_web_900 20171110_2 07a9b3d7ddd6 2 days ago 247MB local/mailman_web_900 latest 07a9b3d7ddd6 2 days ago 247MB
I do the same with the web image, as I need to change the user there, too.
Then, in docker-compose.yaml, I change the line(s) referring to the image name(s):
services: mailman-core: image: local/mailman_core_900 container_name: mailman-core hostname: mailman-core
mailman-web: image: local/mailman_web_900 container_name: mailman-web hostname: mailman-web
I don't know if this is a good solution, but at least it fixes some serious issues with the 3.1's postfix integration that wouldn't otherwise be fixed until the 3.2 release. The bottom line is that it works for me, but it adds an additional layer of complication.
2017-11-03 19:40 GMT+01:00 Abhilash Raj <maxking@asynchronous.in>:
On Fri, Nov 3, 2017, at 08:29 AM, Fabian A. Santiago wrote:
October 26, 2017 11:07 PM, "Mark Sapiro" <mark@msapiro.net> wrote:
On October 26, 2017 7:30:35 PM PDT, "Fabian A. Santiago" < fsantiago@garbage-juice.com> wrote:
That was it. Perfect. I manually modified my regexp map and it works now. Excellent and Thank you. You're the man. Does mm3 ever refresh those maps or only as I add new domains / lists?
Only when you make changes to domains or lists.
-- Mark Sapiro <mark@msapiro.net> Sent from my Not_an_iThing with standards compliant, open source software.
Mark,
I've noticed that even simply restarting the mm3 components those alias maps get rewritten and the problem returns until I can manually edit it.
Yeah, that is true. Transport maps are re-generated everytime the container restarts.
I don't think think there is any way around this right now :(
-- Abhilash Raj maxking@asynchronous.in
Mailman-users mailing list mailman-users@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
participants (4)
-
Abhilash Raj -
Fabian A. Santiago -
Mark Sapiro -
Thor Atle Rustad