On 22 Oct 2016, at 18:50, Noel Jones wrote:
On 10/22/2016 5:36 PM, Paul van der Vlis wrote:
The "Authenticated sender" does not excist as a user account. It is
an
correct e-mail address, but not an user account with what you can
authenticate.
And yet that's the username postfix provides to the backend. The
only mystery here is why the backend accepts it. This is almost
certainly due to some unintentional configuration rather than a bug
or exploit.
You should concentrate your efforts on the backend. All you'll get
out of postfix is that some username and password was passed to the
backend, and the backend replied they were valid.
This makes me ponder a question:
What does Postfix show in the Received header if authentication is
attempted and fails but the sender keeps going and is is not rejected by
a later restriction?
Further debugging in postfix is pointless.
If the answer to the above question is "it records the attempted
authentication identity" then this is not so. We already know that the
submission service is grossly misconfigured, as it has no overrides of
any settings for the port 25 smtpd.
The OP has ignored repeated requests for postconf -nf output and
comprehensive relevant log extracts but any logging is likely to be
unclear in any case because of his failure to configure submission
wisely. We KNOW submission is using an inherently insecure config and he
asserts that this is coming though the submission service. It couldn't
hurt to fix the glaring problem with submission config, since it
provides a theoretical path for mail to be relayed without even an
attempt to authenticate: just fail to be rejected by his complex
smtp_relay_restrictions. That list ends in 'permit' and includes a very
suspicious (especially for submission) 'check_sender_access
hash:/etc/postfix/whitelist' which presumably has 'permit' entries for
sender addresses which are not subject to any sort of authentication.
