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.

> I had this:
> 
> smtpd_relay_restrictions =
>   permit_mynetworks
>   permit_sasl_authenticated 
>   reject_unauth_destination
>   permit_auth_destination

This is correct for most sites, likely including yours, except that
the last check is redundant and can be dropped (doing nothing is
a faster NOOP).

> If I remove "reject_unauth_destination" to see if it would fix a problem:

You still have not posted the details of your problem (with related logs,
and pertinent table entries):

    http://www.postfix.org/DEBUG_README.html#mail

> smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated 
> permit_auth_destination

No that's a mistake, don't do that.

> What does "*check_relay_domains*" do?

It has long been obsolete, use "reject_unauth_destination" instead.

> (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).

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.

> The system keeps sending the same message to people who have already 
> received it, and it seems it would just keep on doing so
> until all the deferred Bcc messages are delivered or expire,

This is only an issue with local aliases and over-quota users or
misconfigured lists.  Avoid local aliases, and maintain goog alias
list hygiene.

> (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.

> smtpd crashes (dies) and horribly enough that the mail being processed 
> is forgotten.

That's not a crash.  Postfix is telling you that your configuration is
invalid.  Also, Postfix does not discard mail until it has been in the
queue for more than the configured retry limit.

> If you don't want it to be blank, you can tell the user it's mandatory 
> and what default was forced because it was blank,
> rather than dying with "error_notice_recipient: string length 0 < 1 
> *crash*".

That's telling you it is mandatory, but for some reason you insist
on calling the error message a "crash".

> The user should not be able to crash postfix with simple config mistakes 
> that are detectable (missing parameter value, for example.)

It is not a crash, the software is logging a configuration error.

-- 
        Viktor.

Reply via email to