On 7/6/16 1:51 PM, Jérôme wrote: > > But may I have a mailbox like [email protected] and a list like > [email protected] ? > > Since the alias reads > > test: "|/var/lib/mailman/mail/mailman post test" > test-admin: "|/var/lib/mailman/mail/mailman admin test" > ... > > I assumed mailman would have everything called "test@..." be directed > to mailman.
The way Mailman-Postfix integration works the 'virtual-mailman' alias_maps will map '[email protected]' to the local name 'test' and alias maps will deliver the local 'test' to mailman. If you have an actual local user 'test' as long as Postfix delivers to that user via the 'local' transport, it will honor the alias and deliver to Mailman. > Thinking twice, this file is used for local aliases, so it would only > conflict with system users/aliases, not virtual aliases. That is correct. If domain1.tld is a virtual domain (virtual mailbox domain or virtual alias domain), it depends what transport is ultimately used to deliver the mail to [email protected]. If, for example, this is dovecot, it won't consult alias_maps and will deliver to the user's mailbox. > Or not conflict at all ? I'm not sure... > > Avoiding conflicts is the reason I'm using the 'lists' subdomain. > > > Back to the subject, I added hash:/var/lib/mailman/data/aliases to > alias_maps and I'm still getting the same error : > > <[email protected]> (expanded from > <[email protected]>): user unknown > > (I did restart Postfix, even Mailman, I even restarted the whole > server.) > > Any known potential cause for this? > > I don't think there is more to the config than what I already sent. > > > I'm not sure how it all works. AFAIU, virtual-mailman makes sure that > > [email protected] -> test > > and then, aliases makes sure that > > test -> "|/var/lib/mailman/mail/mailman post test" > > It looks like the first step succeeds, but then postfix appends > domain1.tld to test before looking up in aliases. > > Could it be related to that feature that makes postfix append $myorigin > to unqualified recipient addresses. > > (http://www.postfix.org/BASIC_CONFIGURATION_README.html#myorigin) There is a possible fix for this. Set VIRTUAL_MAILMAN_LOCAL_DOMAIN = 'localhost' in mm_cfg.py and rerun Mailman's bin/genaliases. You don't need to restart Mailman immediately, just before you create a new list, but do it anyway. This will change the virtual-mailman mappings to things like [email protected] test@localhost. > As a quick test, if I connect as local user and send a message using > > mail nobody > > here's what I get in the logs: > > postfix/pipe[2909]: 0EC5AC15D: to=<[email protected]>, > orig_to=<nobody>, relay=dovecot, delay=0.11, delays=0.04/0.01/0/0.07, > dsn=5.1.1, status=bounced (user unknown) > > This seems to indicate that the postfix configuration is wrong, > as /etc/aliases are also broken. Note 'relay=dovecot'. Dovecot does not consult aliases. If setting VIRTUAL_MAILMAN_LOCAL_DOMAIN = 'localhost' doesn't solve the issue, please post all the Postfix log entries related to the failed delivery. I think it will work, but if not, you may have to resort to the method at <https://wiki.list.org/x/10715238>. -- 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
