On Tue, Jul 29, 2014 at 04:05:51PM +0200, Atze Zitman wrote:
My final response in this thread:
> It is true that I have "smtpd_delay_reject = no". I have done this, so
> the sender restrictions would not be evaluated for each recipient address,
> but for the sender address only (tested long time ago, hope I'm not wrong).
If this is what you inadvisably decide to do, then indeed client
and helo restrictions are too early for check_ccert_access, but
you can still use smtpd_{sender,relay,recipient}_restrictions which
evaluate after STARTTLS (the "smtpd_relay_restrictions" feature is
Postfix >= 2.10).
> When the policyd rejects a sender address (smtpd_sender_restrictions),
> the reject is given after each "RCPT TO" with a clear message that the
> sender address is rejected.
Only with "smtpd_delay_reject = yes", but if the client employs
ESMTP PIPELINING, any RCPT TO commands sent with "MAIL FROM" will
also be rejected for the same reason (provided the MAIL FROM reject
is not a 421 or 521).
> The postfix logging and policyd logging contain
> both sender & recipient address. I am missing something else about this
> property, why I really should change it back to the default?
This is not the case with "smtpd_delay_reject = no" except by accident
due to pipelining.
> I can understand that it is strongly undesirable to return any 5XX before
> the "MAIL FROM" as you describe the behavior of most mail servers.
That should be sufficient to avoid the mistake.
> However, don't you have the same problem for SASL authentication?
SASL authentication is on the MSA port (587). MTA to MTA traffic does
not employ SASL authentication.
More critically, you're confusing authentication with authorization.
When SASL auth fails it is similar to the TLS client failing to
complete the TLS handshake correctly (private key mismatch with
public key, ...). The actual authorization check is
"permit_sasl_authenticated", which is used in:
smtpd_relay_restrictions, or
smtpd_recipient_restrictions
just like "check_ccert_access".
> When the SASL
> authentication fails, Postfix returns 535 prior to the MAIL FROM. Why not
> have the same behavior for a different kind of authentication
> (client-certificate)?
The TLS client auth fails, the connection fails. You're talking about
authorization checks.
> I understand why and how authentication failures can be rejected after
> the "RCPT TO". But for now, I see this more as a workaround, instead of
> preferred behavior. Or at the very least, inconsistent between SASL &
> client-certificate authentication.
No, *authorization failures* can and should be rejected at RCPT TO.
And there is no inconsistency, apart from trivial details due to
protocol differences.
--
Viktor.
