>> By default, local_recipient_maps includes $alias_maps, and I *think* it
should in your case.
>> Why this lack would cause Postfix to use the virtual_transport rather
than local in just this
>> one case is really a question for postfix-us...@postfix.org or some other
Postfix resource,
>> but you might try local_recipient_maps = unix:passwd.byname $alias_maps
Very well spotted ! This is indeed the source of the mail rejection behavior
that I have reported on when using a locally-hosted mail accounts on the
same VPS which also hosts Mailman.
The 'postconf -d' command output shows the following default setting :
alias_maps = hash:/etc/aliases, nis:mail.aliases
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
The 'postconf -n' command output shows the following (re)specified setting :
alias_maps = hash:/etc/aliases, hash:/etc/mailman/aliases
local_recipient_maps = unix:passwd.byname
For some unclear reason, in the distribution we are using the '$allias_maps'
parameter had been removed from the 'local_recipient_maps' setting in the
Postfix 'main.cf' configuration file.
After redefining the line as "local_recipient_maps = unix:passwd.byname
$alias_maps" and doing a few test, it appears that we can now successfully
use local mail accounts in relation with Mailman.
>> or simply removing that line from main.cf and see if that helps.
No need to do that as the above corrective action did fully resolve the
problem.
Many thanks, Mark, for your very effective guidance on this issue !
- - -
Jacques Setton
jset...@waycast.com
-----Message d'origine-----
De : Mark Sapiro [mailto:m...@msapiro.net]
Envoyé : vendredi 25 avril 2014 20:40
À : Jacques Setton
Cc : mailman-users@python.org
Objet : Re: [Mailman-Users] 'Undelivered Mail Returned to Sender' error when
using an e-mail from a domain co-hosted with the one used for Mailman lists
On 04/25/2014 03:25 AM, Jacques Setton wrote:
>
> 1) Selected Sequence from /var/log/maillog
...
> Apr 21 02:49:56 vps12345 postfix/smtp[9414]: F030911C008:
> to=<mailman-requ...@domain.org>, relay=127.0.0.1[127.0.0.1]:10024,
> delay=0.73, delays=0.26/0.01/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 9F72D11C00A) Apr
> 21 02:49:56 vps12345 postfix/smtpd[9419]: disconnect from
> localhost.localdomain[127.0.0.1] Apr 21 02:49:56 vps12345 dovecot:
> auth: sql(mailman-requ...@domain.org):
> Unknown user
> Apr 21 02:49:56 vps12345 postfix/pipe[9420]: 9F72D11C00A:
> to=<mailman-requ...@domain.org>, relay=dovecot, delay=0.04,
> delays=0.01/0.01/0/0.02, dsn=5.1.1, status=bounced (user unknown)
Delivery to Mailman is via aliases. The dovecot LDA does not use your
aliases. Delivery to Mailman must be via the local LDA.
Something in your Postfix configuration is telling it to relay this
particular mail via the dovecot transport rather than the local transport.
That's why it bounces. The question is what's causing it.
I suspect it has to do with two things in your Postfix configuration:
local_recipient_maps = unix:passwd.byname
and
virtual_transport = dovecot
By default, local_recipient_maps includes $alias_maps, and I *think* it
should in your case. Why this lack would cause Postfix to use the
virtual_transport rather than local in just this one case is really a
question for postfix-us...@postfix.org or some other Postfix resource, but
you might try
local_recipient_maps = unix:passwd.byname $alias_maps
or simply removing that line from main.cf and see if that helps.
--
Mark Sapiro <m...@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/archive%40jab.org
