I have three bugs to report, two utility programs to share I wrote for
quick'n'dirty backend fixup for when the postfix config misbehaves, and
a postfix installation that's giving me fits. I will submit that as
three posts.
This is the "issues" post.
I keep converging on getting postfix's config right, but have a handful
of anomalies with no apparent cause. I am using the workaround programs
at the moment.
I have a site X and host virtual domains V = { ... }. I do not forward
email for other hosts, only serve as a backup MX for a host or two
(which I'm ignoring for the moment), and all the rest are forwards of
localuser@virtualhost -> either local users, or direct forwards offsite
(e.g. foo@gmail) via a virtual users table and the aliases file.
(1)
I keep seeing email denied with "relaying denied" when addressed to
users in virtual domains. I insured the "domains_we_host" file was
complete; some of the domains having issues hadn't been listed. But even
after insuring all domains were listed, the same users kept having their
mail from external users denied with "relaying denied".
Technically in "external user -> X ->
localuser@virtualdomain_hosted_by(X)", the external user is relaying
through X, but the postfix documentation distinguishes this scenario
specifically as "hosted domains". So why are domains I've declared as
hosted having inbound email faulted for relaying?
I don't know what postfix does when it reads various tables, so for
example if I give it a virtual user mapping file, does it examine the
domains on the LHS and add them to the list of domains it considers
hosted? Or what I suspect, that the "domains_we_host" file solely
controls it, and then non-matching entries in the virtual users table
are just junk (but there should be at least the catch-all entry for each
domain in "domains_we_host", I assume.). I am not relaying (yet) by
handing off to any other MX host, so I have "relay_maps=".
(2)
Certain specific users (including some being served by virtual host
addresses) can't receive email. Issue (1) is email for
localuser@my_virtual_host is being rejected for attempted relaying;
issue (2) is that email refuses to deliver after being received, instead
being "deferred" for no discernable cause, and never released from the
queue (despite retries.) The first utility I wrote was a program to grab
the deferred mail and deliver it, removing it from the postfix queue.
I found that I could create other users who could receive email, so I
wrote a second utility ("slidemail") that just appends stdin to the
given user's spool file. If email to "jones" is busted,
aliases:
jones: jonesx
jonesx/.forward
"|/usr/local/bin/slidemail jones"
This makes the postfix glitch transparent for jones, but these band-aids
should be disposed of.
I finally suspected that somewhere in the murk of postfix was the
decision that delivering to users with uid < 1000 was uncool. If the
documentation said anything about that, I missed it. root on my system
was always aliased to a plain user. I can't get mail. I had and a couple
other affected users had a userid less than 1000. I fixed that, and no
change. So that wasn't the issue. I can see nothing to distinguish the
accounts that can receive email from those for whom the email is always
deferred. I can't get email at my own account even as a user in the
system's identity domain (username@realdomain)!!
I have run trivial-rewrite and smtpd both with "-v -v" and the decision
to defer is being made in smtpd, but the output does not acknowledge any
event to trigger it nor even when the decision is made, all one sees is
the sudden change to "defer". The postqueue -p error messages seem quite
bereft of detail (I'm used to sendmail.) I can see no reason why the
system picks on a few userids this way.
==
Info, logs, on request.
