*(1)*
On 4/17/19 12:02 AM, Viktor Dukhovni wrote:
On Tue, Apr 16, 2019 at 06:22:12PM -0700, ecsd wrote:
(1) the control "check_relay_domains" is not documented.
It is obsolete, and should no longer be used.
(1) postfix itself says to use it, and (2) it was the only option
offered that did not appear intended to accept or reject the mail.
That is, if you use it, it solves the problem that provokes the message
that offers it as one of the solutions.
I showed the example. If I had smtpd_relay_restrictions = permit (3
kinds) but no "reject", smtpd quit with the error message
in question, complaining that there was no "reject" and offering symbols
that could be used to correct the unhappiness.
"check_relay_domains" is one of those offered. So postfix itself is
still telling people about that symbol (and endorsing its use.)
The documentation should list the parameter as long as it exists
(supported by the code, which it is) and say it is deprecated
and not to be used.
This *breaks* it: (the italicized text, if italics can be seen in the
mailing list, is the culprit whereby postfix told me to use that parameter.)
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
permit_auth_destination
Apr 17 20:43:09 transbay postfix/postfix-script[72934]: refreshing the
Postfix mail system
Apr 17 20:43:09 transbay postfix/master[19336]: reload -- version 3.3.3,
configuration /usr/local/etc/postfix
Apr 17 20:43:24 transbay postfix/smtpd[72940]: /fatal: in parameter
smtpd_relay_restrictions or smtpd_recipient_restrictions, specify at
least one working instance of: reject_unauth_destination,
defer_unauth_destination, reject, defer, defer_if_permit or
//*check_relay_domains*/
Apr 17 20:43:25 transbay postfix/master[19336]: warning: process
/usr/local/libexec/postfix/smtpd pid 72940 exit status 1
Apr 17 20:43:25 transbay postfix/master[19336]: warning:
/usr/local/libexec/postfix/smtpd: *bad command startup -- throttling*
This *fixes* it:
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
permit_auth_destination *check_relay_domains
*(no log complaints)
This is what I am using:
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
reject_unauth_destination permit_auth_destination
And I will remove the last parameter based on your remark that it is
redundant.
*(2)*
It seems that if an email is sent to a Bcc: list, postfix resends the
email to /all/ the recipients again, each time it tries to flush
any deferred Bcc list recipient emails that did not go out first try.
Each time the queue is retried !! {ouch.}
No, that's not the case, and has nothing to do with "Bcc" as such.
What is true is that delivery to local aliases(5) is retried when
any local recipient that the alias expands to fails. The solution
is to use virtual aliases whenever possible, leaving local aliases
for just pipes, and special lists (:include: and lists with owner
aliases).
This says I should *not* use the standard system aliases file, on
FreeBSD that is /etc/mail/aliases.
I can if needed pull everything from that to put into another file I
created containing all my local
users as defined in /etc/passwd so that I did not have to worry whether
postfix could read /etc/passwd,
which I suspected might be the case. If I have to create a file that
lists all local recipients by user name
or alias name, so be it.
I always make sure that "myorigin" is not listed in $mydestination,
so that unqualified addresses never inadvertently resolve to the
local(8) transport, mail only reaches local(8) when explicitly
aliased to "localhost" in virtual aliases.
I don't see how that can work. "mydestination" is transbay.net because
that is the server's public name. "myorigin" supplies the domain to be
appended if there is none. If a domainless sender "fred" from my machine
sends, he has to be rewritten as "f...@transbay.net", which is what I
assume "myorigin" does. So how can it make sense in my case that
"mydestination" != "myorigin"? What else could "myorigin" be on the
server "transbay.net"? I hoped I was solving a problem by setting
"myorigin", do I get better results to leave it blank?
documentation says:
mydestination (default: $myhostname, localhost.$mydomain, localhost)
The list of domains that are delivered via the $local_transport
mail delivery transport. By default this is the Postfix local(8)
delivery agent which looks up all recipients in /etc/passwd and
/etc/aliases. The SMTP server validates recipient addresses with
$local_recipient_maps and rejects non-existent recipients. See also
the local domain class in the ADDRESS_CLASS_README file.
The default mydestination value specifies names for the *local
machine* only. On a mail domain gateway, you should also include
$mydomain.
myorigin (default: $myhostname)
The *domain name that* locally-posted *mail appears to come
from*, and that *locally posted mail is delivered to*. The default,
$myhostname, is adequate for small sites.
I don't see how "myorigin" could differ from what's in "mydestination".
I don't want my plain user "fred" to be rewritten as
"f...@mail.transbay.net" besides which mail.transbay.net is again in
"mydestination". It makes no sense to try to use some other domain,
because that's not true. When fred sends, to reply to him it would be
"f...@transbay.net" and so that's how his outbound email has to be marked.
Would I get better results just leaving "myorigin" blank?
??
But even beyond that, I have a file that actually lists every user from
/etc/passwd as "username@localhost" on the LHS to validate the user
and say where to deliver, and it still will not work for me as a user:
email to "ecsd" or "ecsd@localhost" is ALWAYS deferred.
I have a cheat in place that aliases says "ecsd: ecsdx" and somehow
postfix has no problem delivering to "ecsdx" (a real user.)
That user's .forward file uses a program I wrote that concats the stdin
input to the desired spool file (ecsd in this case.) That is working
to let me think I'm actually getting email, but it's an absurd band-aid.
I have three local users fixed up that way.
I have tried the best I can to insure that no map file that I have, ever
confuses postfix about what CLASS a user is in, but I only have two
classes, LOCAL and VIRTUAL HOST. And the system keeps behaving as if it
is confused about users, that it cannot tell their class.
The system keeps rejecting email to VIRTUAL HOST users with "relaying
denied" messages, but they are NOT anywhere described as relay
domains and the postfix documentation makes it clear that using a
"domains we host" file and a virtual user mapping table, postfix will
deliver to the local users defined to receive email for the domains.
It's not doing that.
Here are all the entries from my main.cf that reference maps:
relocated_maps = hash:/etc/mail/postfix.user-has-moved
smtp_sasl_password_maps = hash:/usr/local/etc/sasldb2.db
local_recipient_maps = proxy:unix:passwd.byname
hash:/usr/local/etc/postfix/postfix.users $alias_maps
relay_recipient_maps =
virtual_alias_maps = hash:/etc/mail/virtusers
alias_maps = hash:/etc/mail/aliases
virtusers has the format
LHS RHS
postfix.users has the format
LHS ignored
postfix.users contains everyone listed in /etc/passwd, so
"proxy:unix:passwd.byname" should be able to be removed.
if postfix cannot read the passwd file, it can still read
"postfix.users", and so no local user should fail to be recognized as local;
the file is verified complete and correct.
*(3)*
error_notice_recipient has the bug that if it is specified explicitly to
be blank
error_notice_recipient =
This parameter is required to be non-empty. When Postfix is
misconfigured, services log fatal errors and exit. This is
recorded in logs.
with
error_notice_recipient =
Apr 17 20:34:44 transbay postfix/postfix-script[72843]: refreshing the
Postfix mail system
Apr 17 20:34:44 transbay postfix/master[19336]: reload -- version 3.3.3,
configuration /usr/local/etc/postfix
Apr 17 20:34:44 transbay postfix/anvil[72685]: statistics: max
connection rate 1/60s for (smtp:192.34.60.31) at Apr 17 20:23:48
Apr 17 20:34:44 transbay postfix/anvil[72685]: statistics: max
connection count 1 for (smtp:192.34.60.31) at Apr 17 20:23:48
Apr 17 20:34:44 transbay postfix/anvil[72685]: statistics: max cache
size 2 at Apr 17 20:24:32
Apr 17 20:34:44 transbay postfix/qmgr[72848]: 505A126F54AF:
from=<notificat...@facebookmail.com>, size=18332, nrcpt=1 (queue active)
Apr 17 20:34:44 transbay postfix/smtp[72850]: *fatal: bad string length
0 < 1: error_notice_recipient =*
Apr 17 20:34:45 transbay postfix/master[19336]: warning: process
/usr/local/libexec/postfix/smtp pid 72850 exit status 1
Apr 17 20:34:45 transbay postfix/master[19336]: warning:
/usr/local/libexec/postfix/smtp: *bad command startup -- throttling*
If I am writing production software (i.e. the end users have a very
vested interest in it working properly),
then if I see the user attempt to give me "empty" for a symbol required
to be nonblank and for which I
otherwise have a default value in hand, I would syslog that I had
refused to accept the invalid value,
that I was using the default instead, and the program would continue.
The behavior may not be what the user "wanted", but the user could not
"want" that the program could not
operate, and so better that the program continue (having logged that
parameter value was unacceptable)
than refuse to operate at all.
People go through this when installing postfix. They try certain
settings and watch the logs, find anomalies
versus what they wanted, correct the config, and try again.
If smtpd had bitched at the blank value, used the default
(postmaster@localhost) and continued, maybe
the program would be delivering to a user the admins did not want mail
sent to, but that would be logged
and smtpd could continue to function. The admins would figure out the
correct way to do what they intended.
See below (*). All of this mess is generally confined to the initial
installation.
You object to my use of the word "crash", okay. Yes, it was not a
SIGSEGV or a divide by zero. But if it is a
production program and is exiting (1) every time it runs, it is
"crashing" in my world of discourse. Point taken,
I will say "unexpectedly exited."
(*) Apache has a companion program "apachectl" and one of the things it
does is inspects the config file -
a "sanity check." You issue "apachectl configtest" and it will tell you
about any errors in the config. It is
also used before running the program, if you say "apachectl start" it
runs "apachectl configtest" first and
only runs apache if the syntax was okay.
If there were such a thing for postfix, it could catch those errors
before the user would run the program
only to get unexpected exits.
