On Tue, Jun 25, 2013 at 02:53:47PM +0100, Craig R. Skinner wrote:
> > And hence, it is processed by the local(8) delivery agent, which
> > normally handles domains listed in mydestination.
> >
>
> Well, that's the theory - but I don't see that happening when adhering
> to the suggestions provided in this thread:
No it is a fact, but you're seem too disorganized to follow directions
exactly as specified. :-(
> myorigin = $mydomain
> mydestination = localhost, localhost.$mydomain
> virtual_alias_domains = example.com
> mailbox_transport = lmtp:unix:private/dovecot-lmtp
> Various combinations of these with the above don't trigger aliases
> expansion:
> append_dot_mydomain = no
Don't do that.
> local_transport = local:localhost
Unnecessary, don't do that.
> If local(8) was handling domains listed in mydesti[nation] (localhost) then
> aliases should be parsed, but nope.
What evidence do you have that aliases are not expanded for mail handled
by local?
> Jun 25 14:04:08 server1 postfix/pickup[29023]: 51B8367E0: uid=7432
> from=<admin-acct>
> Jun 25 14:04:08 server1 postfix/cleanup[154]: 51B8367E0:
> message-id=<20130625130408.51b836...@server1.example.com>
> Jun 25 14:04:08 server1 postfix/qmgr[6613]: 51B8367E0:
> from=<server.ad...@example.com>, size=389, nrcpt=1 (queue active)
> Jun 25 14:04:08 server1 postfix/trivial-rewrite[2958]: warning: do not list
> domain example.com in BOTH mydestination and virtual_alias_domains
This configuration is not what you claim above, stop wasting the list's
time with misleading reports.
> Jun 25 14:04:08 server1 postfix/lmtp[30743]: 51B8367E0:
> to=<admin-a...@example.com>, orig_to=<daemon>,
> relay=server1.example.com[private/dovecot-lmtp], delay=0.07,
> delays=0.02/0/0.01/0.03, dsn=2.0.0, status=sent (250 2.0.0
> <admin-a...@example.com> wCqpOjmVyVF/agAANm01jw Saved)
Were example.com in virtual_alias_domains, this message would have bounced.
> Comments?
Do get your act together and try exactly the configuration suggested,
without any tweaks.
0. All address -> address mappings in virtual(5).
1. No address-> address mappings in aliases(5).
2. localhost and localhost.$mydomain only in mydestionation.
3. Your domain in virtual_alias_domains and myorigin.
4. In virtual(5) the LHS and RHS of all lookup keys include @domain:
al...@example.com u...@example.com, otheru...@example.com
u...@example.com useracct@localhost
otheru...@example.com otheracct@localhost
5. Nothing in aliases(5) except aliases whose RHS is a ":include:" file
if you need that feature (mailing list manager integration).
6. Handle "| command" aliases via .forward files of a designated
account, rather than in the system aliases file.
7. Did I mention no address to address (or if you like account to
account, address to account, account to address, ...) mappings in
aliases(5)? Plase all of these in virtual(5).
8. When testing, stop Postfix, check the configuration is what you want
to test and save "postconf -n" output. Start Postfix and run your
tests. Then report log entries that postdate the most recent Postfix
stop/start.
9. Don't tinker with the configuration mid-test and report logs that
don't match the reported configuration.
11. Yes local aliases(5) will still work when useracct@localhost is
processed by local(8), but best practice is to avoid user accounts as
lookup keys in /etc/aliases.
12. Local aliases(5) are not consulted when an address is missing
from virtual(5). If you send email to "miss...@example.com" with
miss...@example.com not listed in virtual(5), then having an entry of
the form "missing: user" in aliases(5) will not help. You must
include:
miss...@example.com missing@localhost
for missing to then be looked up in aliases(5), but if
missing needs to be sent to a different user, you should
use virtual(5) for that! See 1 and 7 above. Basically,
in most cases aliases(5) can and should be empty.
13. You can even set:
alias_database =
alias_maps =
and the question of whether aliases(5) lookups works becomes moot.
You'll only need aliases(5) for mailing list manager support, with
aliases(5) files that belong to the list manager account, so that
pipe commands there run under the correct account.
--
Viktor.
