On 17.04.19 21:53, ecsd wrote:
*(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.
the whole poing of smtpd_relay_restrictions is to prevent postfix from
behaving as open relay, thus it MUST contain something that rejects
(or defers) the mail unless other conditions are met.
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.
possibly yes, however better solution will be removing this option from
being mentioned.
And using unknown and undocumented option is not a wise thing to do.
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.)
it's not wise to use HTML in mailing list.
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
permit_auth_destination *check_relay_domains
*(no log complaints)
no log complaints, but no documentation telling how will your system behave.
The only problem I see is that check_relay_domains was somehow forgotten in
documentation or the code.
*(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.
The aliases file is default for sendmail, but postfix has different
architecture, where aliases are supported, but not optimal, because of the
problems noted.
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.
/etc/passwd should not be a problem. it's world-readable by default, used by
many utilities.
in your case, aliases is most probably the reason of mail duplication.
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.
So, transbay.net is considered local and if user does not appear in
virtual_alias_maps, alias_maps or local_recipient_maps, the user is refused
as non-existing.
"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?
myorigin is not your problem. If transbay.net is a virtual domain where some
of users don't exist on your system, it should not be listed in
"mydestination", but in virtual_alias_domains or virtual_mailbox_domains.
your mydestination should be then set to "mail.transpay.net" or "localhost".
The system keeps rejecting email to VIRTUAL HOST users with "relaying
denied" messages
that's apparently because the virtual host is not listed in either of those
directives above.
*(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 =
apparently you need to have documented that this parameter must not be
empty. it must be set to an user who maintains the postfix server.
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.
You apparently want postfix to work even if it's clearly misconfigured.
Well, you can patch it locally then. and then deal with consequences.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I don't have lysdexia. The Dog wouldn't allow that.
