mailman on google comput engine
i just did make one vm instance Ubuntu 18.04 on google compute engine. barely i did install postfix at there. hmm if possible, i wish to run mailing service for my family and me -- it needs a little bit some comunication plus some records about family history. yes i want GNU Mailman very much!!! google compute engine blocked port 25 by default. in this case i can run mailman with other port (example 625)? again question, Mailman can act with 625 or 1625 or 2625, ...?
Sincerely, Byung-Hee from South Korea.
-- ^고맙습니다 _地平天成_ 감사합니다_^))//
On 3/21/19 12:40 AM, 황병희 wrote:
in this case i can run mailman with other port (example 625)? again question, Mailman can act with 625 or 1625 or 2625, ...?
No. Not directly.
Mailman is not a mail server. You must have a mail server (daemon) sit in front of Mailman.
You can make that mail server listen on a different port. However only the other servers you modify to communicate with that alternate port will be able to send email.
You really want port 25. Or you need something else, likely specialized, to make things work.
(It's likely possible that something can fetch email from elsewhere and feed it into Mailman, but that's something specialized.)
-- Grant. . . . unix || die
On 3/20/19 11:40 PM, 황병희 wrote:
i just did make one vm instance Ubuntu 18.04 on google compute engine. barely i did install postfix at there. hmm if possible, i wish to run mailing service for my family and me -- it needs a little bit some comunication plus some records about family history. yes i want GNU Mailman very much!!! google compute engine blocked port 25 by default. in this case i can run mailman with other port (example 625)? again question, Mailman can act with 625 or 1625 or 2625, ...?
Are you talking incoming or outgoing mail. There are multiple pieces involved. If incoming port 25 is blocked, Postfix won't be able to receive incoming mail to the list and you're dead at that point.
Presumably, it is only outgoing port 25 that is blocked. By default Mailman delivers to the local MTA at localhost:25 which may or may not be blocked but probably isn't. You can change these by setting SMTPHOST and SMTPPORT in mm_cfg.py, but if you are going to deliver via the local Postfix, Postfix will relay the outgoing mail to port 25 at the recipient MXs. You can't really change that because you can't tell the recipient MXs to listen on other ports.
You can get Postfix to relay via another MTA, e.g. at your ISP, and authenticate to it.
If your Mailman is 2.1.23 or later (the Ubuntu 18.04 package is 2.1.26) you can get Mailman to relay directly to an outside MTA with authentication via the mm_cfg.py settings SMTP_AUTH, SMTP_USER, SMTP_PASSWD and SMTP_USE_TLS in addition to SMTPHOST and SMTPPORT.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
A consumer internet connection frequently has incoming port 25 simply blocked, and outgoing port 25 either blocked entirely or blocked for all but the ISP’s outgoing mail server.
There are ways around this. Consider duocircle.com “backup mx” service.
On Mar 21, 2019, at 1:44 PM, Mark Sapiro <mark@msapiro.net> wrote:
On 3/20/19 11:40 PM, 황병희 wrote:
i just did make one vm instance Ubuntu 18.04 on google compute engine. barely i did install postfix at there. hmm if possible, i wish to run mailing service for my family and me -- it needs a little bit some comunication plus some records about family history. yes i want GNU Mailman very much!!! google compute engine blocked port 25 by default. in this case i can run mailman with other port (example 625)? again question, Mailman can act with 625 or 1625 or 2625, ...?
Are you talking incoming or outgoing mail. There are multiple pieces involved. If incoming port 25 is blocked, Postfix won't be able to receive incoming mail to the list and you're dead at that point.
Presumably, it is only outgoing port 25 that is blocked. By default Mailman delivers to the local MTA at localhost:25 which may or may not be blocked but probably isn't. You can change these by setting SMTPHOST and SMTPPORT in mm_cfg.py, but if you are going to deliver via the local Postfix, Postfix will relay the outgoing mail to port 25 at the recipient MXs. You can't really change that because you can't tell the recipient MXs to listen on other ports.
You can get Postfix to relay via another MTA, e.g. at your ISP, and authenticate to it.
If your Mailman is 2.1.23 or later (the Ubuntu 18.04 package is 2.1.26) you can get Mailman to relay directly to an outside MTA with authentication via the mm_cfg.py settings SMTP_AUTH, SMTP_USER, SMTP_PASSWD and SMTP_USE_TLS in addition to SMTPHOST and SMTPPORT.
-- 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@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/adam%40agp-llc.com
On 3/21/19 11:58 AM, Adam Goldberg wrote:
There are ways around this.
I see no technical reason why Mailman couldn't function via something like fetchmail from a POP3 mailbox and SMTP Authentication to send.
Fetchmail would pull the messages from an external 3rd party email server, do a little processing on them to determine the command and list name before pipeing them into Mailman with said command and list name. Mailman would do it's thing, and then send the emails out using SMTP Authentication with the external 3rd party email server.
It would be quite atypical. But I think it should work.
This might work for the OP.
-- Grant. . . . unix || die
On 3/21/19 11:29 AM, Grant Taylor via Mailman-Users wrote:
I see no technical reason why Mailman couldn't function via something like fetchmail from a POP3 mailbox and SMTP Authentication to send.
Fetchmail would pull the messages from an external 3rd party email server, do a little processing on them to determine the command and list name before pipeing them into Mailman with said command and list name. Mailman would do it's thing, and then send the emails out using SMTP Authentication with the external 3rd party email server.
It would be quite atypical. But I think it should work.
It's not as atypical as you think. See, e.g., <https://www.mail-archive.com/search?q=fetchmail&l=mailman-users%40python.org>.
Also, since Mailman 2.1.23, batteries are included for sending to a remote MTA with SMTP Authentication.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 3/21/19 1:56 PM, Mark Sapiro wrote:
On 3/21/19 11:29 AM, Grant Taylor via Mailman-Users wrote:
I see no technical reason why Mailman couldn't function via something like fetchmail from a POP3 mailbox and SMTP Authentication to send.
...
It would be quite atypical. But I think it should work.
It's not as atypical as you think. See, e.g., <https://www.mail-archive.com/search?q=fetchmail&l=mailman-users%40python.org>.
IST vaguely R firing up fetchmail from a dip script to inject messages from my school mailbox into my local qmail... Plenty typical at the time.
-- Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
On 3/21/19 2:05 PM, Dimitri Maziuk via Mailman-Users wrote:
IST vaguely R firing up fetchmail from a dip script to inject messages from my school mailbox into my local qmail... Plenty typical at the time.
Fetchmail itself is plenty common. I had no idea that it was as common with Mailman. 209 hits on the link that Mark shared.
The 45 messages mentioning UUCP surprises me more.
-- Grant. . . . unix || die
On 3/21/19 3:57 PM, Grant Taylor via Mailman-Users wrote:
Fetchmail itself is plenty common. I had no idea that it was as common with Mailman. 209 hits on the link that Mark shared.
I honestly don't remember the details but if I was passing mail to local MTA configured as my home MX, I don't see why mailman wouldn't work behind that.
The 45 messages mentioning UUCP surprises me more. :)
-- Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
On 3/21/19 4:04 PM, Dimitri Maziuk via Mailman-Users wrote:
I honestly don't remember the details but if I was passing mail to local MTA configured as my home MX, I don't see why mailman wouldn't work behind that.
I think that it should.
I'm talking about bypassing the local MTA all together. Pipe fetcmail's STDOUT to a wrapper script to extract the command and mailing list before piping it into the mailman executable with said command and mailing list. Then have Mailman act as an SMTP client directly to an external MTA. No local MTA period.
-- Grant. . . . unix || die
Grant Taylor via Mailman-Users writes:
I'm talking about bypassing the local MTA all together. Pipe fetcmail's STDOUT to a wrapper script to extract the command and mailing list before piping it into the mailman executable with said command and mailing list.
This should work in Mailman 2, but won't in Mailman 3 (which expects incoming posts via LMTP).
Steve
On 3/24/19 11:50 PM, Stephen J. Turnbull wrote:
This should work in Mailman 2, but won't in Mailman 3 (which expects incoming posts via LMTP).
Noted. I think it would be possible to interject a shim between fetchmail that would extract what's necessary to speak LMTP to Mailman.
Is the LMTP still STDIN / STDOUT or something else (possibly a Unix socket)?
I'm trying to understand if I could drive Mailman 3 via Expect. Not that I would. I'm just wondering if I could.
-- Grant. . . . unix || die
On 3/25/19 8:21 AM, Grant Taylor via Mailman-Users wrote:
Noted. I think it would be possible to interject a shim between fetchmail that would extract what's necessary to speak LMTP to Mailman.
Yes, it would be possible.
Is the LMTP still STDIN / STDOUT or something else (possibly a Unix socket)?
The shim could receive a message on stdin from fetchmail, but it would have to deliver the message via LMTP (a subset of SMTP) to Mailman's lmtp runner which listens on a tcp socket, typically localhost:8024.
I'm trying to understand if I could drive Mailman 3 via Expect. Not that I would. I'm just wondering if I could.
You probably could if you created an Expect script to speak LMTP. I think the major issue in this is that fetchmail does not provide the envelope, so you don't know the actual envelope sender to use in the LMTP MAIL FROM command. If the MDA that delivered the mail to the remote mailbox was compliant, it will be in a Return-Path: header in the message, but otherwise you'd have to fake it by using a Sender: or From: header. Also, you don't directly know the original recipient, although you can infer it based on the mailbox you fetched from.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
FetchMail injects messages into the local mail system via SMTP. I see it also supports LMTP. So I guess you would not need a local mail system with Mailman3. But why not setup standard Mailman under your favorite mail system and let FetchMail do what it does best? It is a widely supported configuration.
Your favorite mail system would handle queues for you as well as support all the tools (milters, etc) surrounding your mailman deployment. Reliably handling the queue is important. You won't know how important until you start getting duplicate messages like RFC 1047 <https://tools.ietf.org/html/rfc1047>.
Just checking... when using fetchmail (for example "testlist" on Gmail) then you'd be fetching mail for: testlist@gmail.com as well as
testlist-admin@gmail.com testlist-bounces@gmail.com testlist-confirm@gmail.com testlist-join@gmail.com testlist-leave@gmail.com testlist-owner@gmail.com testlist-request@gmail.com testlist-subscribe@gmail.com testlist-unsubscribe@gmail.com owner-testlist@gmail.com
My fetchmail test is giving me reasonable Sender info.
Ciao, //Z\\
On 3/25/2019 12:45 PM, Mark Sapiro wrote:
On 3/25/19 8:21 AM, Grant Taylor via Mailman-Users wrote:
Noted. I think it would be possible to interject a shim between fetchmail that would extract what's necessary to speak LMTP to Mailman.
Yes, it would be possible.
Is the LMTP still STDIN / STDOUT or something else (possibly a Unix socket)?
The shim could receive a message on stdin from fetchmail, but it would have to deliver the message via LMTP (a subset of SMTP) to Mailman's lmtp runner which listens on a tcp socket, typically localhost:8024.
I'm trying to understand if I could drive Mailman 3 via Expect. Not that I would. I'm just wondering if I could.
You probably could if you created an Expect script to speak LMTP. I think the major issue in this is that fetchmail does not provide the envelope, so you don't know the actual envelope sender to use in the LMTP MAIL FROM command. If the MDA that delivered the mail to the remote mailbox was compliant, it will be in a Return-Path: header in the message, but otherwise you'd have to fake it by using a Sender: or From: header. Also, you don't directly know the original recipient, although you can infer it based on the mailbox you fetched from.
On 3/26/19 12:36 AM, Jim Ziobro wrote:
why not setup standard Mailman under your favorite mail system and let FetchMail do what it does best?
The unneeded complexity of a local mail system.
FetchMail & SMTP Auth would work against an ISP's email server over dynamic / dial up connections.
Sure, FetchMail can pull email from the ISP and inject it into the local server. But what advantage does that gain you? Is said advantage worth the complexity?
Especially if the ISP aliases testlist & testlist-* into one mailbox.
-- Grant. . . . unix || die
On 3/26/19 4:12 PM, Grant Taylor via Mailman-Users wrote:
Sure, FetchMail can pull email from the ISP and inject it into the local server. But what advantage does that gain you? Is said advantage worth the complexity?
Apparently lennartwware-infested linux distros no longer require MTA, presumably because smtp is implemented inside systemd now. I'm not sure the "extra complexity" argument holds, though.
Before this, cron needed an MTA and stock maintenance stuff like log rotation ran from crontab. So there was more complexity in getting one set up without a local MTA, than in setting up postfix.
-- Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
On 3/26/19 12:36 AM, Jim Ziobro wrote:
You won't know how important until you start getting duplicate messages like RFC 1047 <https://tools.ietf.org/html/rfc1047>.
How would having a local MTA change the behavior in the face of a duplicate message?
I've seen symptoms of duplicate messages where multiple servers up stream are the source of duplication.
Are you implying that local MTA alters this behavior? Or that it provides additional tracing / diagnostic information?
I'm not aware of Mailman having any Message-ID deduplication functionality. Nor have I really seen it as a need.
-- Grant. . . . unix || die
Sorry for late, i need to time think about that. Thanks you for *everyone* for me to feedback, indeed...
Sincerely,
-- ^고맙습니다 _地平天成_ 감사합니다_^))//
participants (7)
-
Adam Goldberg -
Dimitri Maziuk -
Grant Taylor -
Jim Ziobro -
Mark Sapiro -
Stephen J. Turnbull -
황병희