On 4 Dec 2015, at 13:57, sb wrote:
On 12/4/15 7:08 PM, Noel Jones wrote:
[...]
I had eject_unknown_sender_domain in smtpd_sender_restrictions, and it
did not work.
It is now in smtpd_client_restrictions.
Which is wrong. See 'man 5 postconf' and the file SMTPD_ACCESS_README in
the Postfix documentation.
-o syslog_name=postfix/port-25
-o smtpd_tls_security_level=may
-o smtpd_sasl_auth_enable=no
-o smtpd_delay_reject=no
generally unwise to disable smtpd_delay_reject, except maybe as a
$stress mitigation during an overload/attack.
I am running a sensitive site, and need it to be responsive and
resilient.
Yet you have chosen an unwise configuration that CANNOT work and is
clearly documented as being non-working. It makes your site LESS
resilient.
Rapid rejection is necessary, albeit not sufficient.
That isn't a meaningful reason to use "smtpd_delay_reject=no"
The "delay" is operationally trivial: at most ~8x the RTT between you
and the client, for a rejection that could be done by
smtpd_client_restrictions. Unlikely to be more than a second. More
importantly, rejecting before the RCPT phase will cause some rejected
clients using shoddy spamware to retry sending, in some cases at high
frequency for extended periods. In addition, if you are concerned about
information leakage, rejecting before RCPT informs a rejected sender
that pays attention to their rejections that you are rejecting based
solely on the basis of information you have at that point of rejection.
Turning that around, using the smtpd_delay_reject=yes default allows you
to make more complex decisions about accepting and rejecting messages
which need not be made entirely clear to untrusted senders.
