Here's another clue Mark... I had noticed that on some mailing lists I was subscribed as [email protected], and on some others as [email protected]. The former are failing as per my origilam problem, but the latter are sent successfully.
So I tried: telnet localhost 25 Trying ::1... telnet: connect to address ::1: Connection refused Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 tunedinweb.com ESMTP Postfix EHLO tunedinweb.com 250-tunedinweb.com 250-PIPELINING 250-SIZE 68157440 250-VRFY 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN MAIL FROM: <[email protected]> 250 2.1.0 Ok RCPT TO: <[email protected]> 250 2.1.5 Ok quit 221 2.0.0 Bye Connection closed by foreign host. This works! Why?? Both [email protected] and [email protected] are defined exactly the same in /etc/postfix/transport. _____________________ Steve Wehr Tunedin Web Design 845-246-9643 -----Original Message----- From: Mark Sapiro [mailto:[email protected]] Sent: Friday, September 09, 2016 1:38 PM To: Steve Wehr Cc: [email protected] Subject: Re: [Mailman-Users] mailman not respecting /etc/postfix/transport ??? On 09/09/2016 07:33 AM, Steve Wehr wrote: > Thanks Mark, Here are the results of the tests you suggested. Both > attempts at telnet failed. > > Tried your experiment: > > /etc/postfix>telnet localhost 25 > Trying ::1... > telnet: connect to address ::1: Connection refused Trying 127.0.0.1... > Connected to localhost. Interesting. I suggest you put SMTPHOST = '127.0.0.1' in mm_cfg.py since 'localhost' seems to resolve at least first to an IPv6 address on which Postfix isn't listening. I don't see exactly how this will help, but it might. Now, given that Postfix doesn't like [email protected], the question is what are the PHP scripts that mail to this address doing. Are they connecting to this Postfix differently or even at all (maybe they connect to mx.emailsrvr.com). > /etc/postfix/transport: > [email protected] smtp:mx.emailsrvr.com > [email protected] smtp:mx.emailsrvr.com > [email protected] smtp:mx.emailsrvr.com > [email protected] smtp:mx.emailsrvr.com > [email protected] smtp:mx.emailsrvr.com > [email protected] smtp:mx.emailsrvr.com > [email protected] smtp:mx.emailsrvr.com > [email protected] smtp:mx.emailsrvr.com > [email protected] smtp:mx.emailsrvr.com > [email protected] smtp:mx.emailsrvr.com > [email protected] smtp:mx.emailsrvr.com > [email protected] smtp:mx.emailsrvr.com > [email protected] smtp:mx.emailsrvr.com > [email protected] smtp:mx.emailsrvr.com > [email protected] smtp:mx.emailsrvr.com > [email protected] smtp:mx.emailsrvr.com > [email protected] smtp:mx.emailsrvr.com > [email protected] smtp:mx.emailsrvr.com > [email protected] smtp:mx.emailsrvr.com > [email protected] smtp:mx.emailsrvr.com > [email protected] smtp:mx.emailsrvr.com > [email protected] smtp:mx.emailsrvr.com > [email protected] smtp:mx.emailsrvr.com If you add local_recipient_maps = proxy:unix:passwd.byname $alias_maps $transport_maps to Postfix main.cf, I think that will work. This is actually only adding $transport_maps as proxy:unix:passwd.byname and $alias_maps are the defaults. This will ensure that none of the addresses in transport_maps (/etc/postfix/transport) is rejected as an unknown local recipient. It appears that Postfix is doing the local recipient check before consulting transport_maps for a transport. I'm not that knowledgeable about the details of Postfix to fully understand this, but I think adding $transport_maps to local_recipient_maps in this case will solve your issue without causing other problems, but I suggest you test and be prepared to reverse when you do this. -- Mark Sapiro <[email protected]> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan ------------------------------------------------------ Mailman-Users mailing list [email protected] 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/archive%40jab.org
