I tried almost all the email addresses defined in /etc/postfix/transport
Many of them succeed in the telnet test below, but many of them fail. There is no pattern I can find to success or failure. I thought maybe there was some hidden characters in the file that were preventing the hashing working when the file is compiled. So I was looking to see if all the ones above a certain spot in the file failed, and all those below succeeded, but that is not the case. Ideas?
Steve Wehr Tunedin Web Design 845-246-9643
-----Original Message----- From: Steve Wehr [mailto:steve@tunedinweb.com] Sent: Saturday, September 10, 2016 10:22 AM To: 'Mark Sapiro' Cc: 'Mailman-Users@python.org' Subject: RE: [Mailman-Users] mailman not respecting /etc/postfix/transport ???
Here's another clue Mark...
I had noticed that on some mailing lists I was subscribed as steve@tunedinweb.com, and on some others as tunedin@tunedinweb.com. 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: <steve@tunedinweb.com> 250 2.1.0 Ok RCPT TO: <tunedin@tunedinweb.com> 250 2.1.5 Ok quit 221 2.0.0 Bye Connection closed by foreign host.
This works! Why??
Both steve@tunedinweb.com and tunedin@tunedinweb.com are defined exactly the same in /etc/postfix/transport.
Steve Wehr Tunedin Web Design 845-246-9643
-----Original Message----- From: Mark Sapiro [mailto:mark@msapiro.net] Sent: Friday, September 09, 2016 1:38 PM To: Steve Wehr Cc: Mailman-Users@python.org 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 steve@tunedinweb.com, 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: steve@tunedinweb.com smtp:mx.emailsrvr.com steves@tunedinweb.com smtp:mx.emailsrvr.com stevew@tunedinweb.com smtp:mx.emailsrvr.com wehr@tunedinweb.com smtp:mx.emailsrvr.com stiert@tunedinweb.com smtp:mx.emailsrvr.com admin@tunedinweb.com smtp:mx.emailsrvr.com errors@tunedinweb.com smtp:mx.emailsrvr.com events@tunedinweb.com smtp:mx.emailsrvr.com feedback@tunedinweb.com smtp:mx.emailsrvr.com email@tunedinweb.com smtp:mx.emailsrvr.com ideachamp_order@tunedinweb.com smtp:mx.emailsrvr.com inquiry@tunedinweb.com smtp:mx.emailsrvr.com mailman@tunedinweb.com smtp:mx.emailsrvr.com mailman_admin@tunedinweb.com smtp:mx.emailsrvr.com mailman-owner@tunedinweb.com smtp:mx.emailsrvr.com orders@tunedinweb.com smtp:mx.emailsrvr.com payments@tunedinweb.com smtp:mx.emailsrvr.com root@tunedinweb.com smtp:mx.emailsrvr.com security@tunedinweb.com smtp:mx.emailsrvr.com tunedin@tunedinweb.com smtp:mx.emailsrvr.com verify@tunedinweb.com smtp:mx.emailsrvr.com abuse@tunedinweb.com smtp:mx.emailsrvr.com postmaster@tunedinweb.com 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 <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan