On 29 April 2018 at 17:51, Wietse Venema <wie...@porcupine.org> wrote:
> Dominic Raferd:
>> On 29 April 2018 at 17:16, Wietse Venema <wie...@porcupine.org> wrote:
>> > Dominic Raferd:
>> >> Checking my logs I see that some senders are trying to fake our domain
>> >> and use our server to send mails to third parties masquerading as one
>> >> of our own domains (without authenticating first).
>> >>
>> >> They are stopped by smtpd with response 'Relay access denied', but
>> >> instead of 5xx permanent rejection smtpd gives 454 4.7.1 temporary
>> >> rejection, which surely encourages them to keep trying. Why is this,
>> >> and can I change it?
>> >
>> > postconf -x smtpd_relay_restrictions
>> >
>> > As a safety for sites migrating from Postfix 2.x, the default
>> > is to defer instead of reject.
>>
>> Thanks Wietse. I was not defining smtpd_relay_restrictions and relying
>> instead on smtpd_recipient_restrictions (which contained
>> reject_unauth_destination), but presumably this was never activated
>> because the default defer_unauth_destination in
>> smtpd_relay_restrictions took precedence.
>
> I have to contradict you: smtpd_recipient_restrictions is evaluated
> BEFORE smtpd_relay_restrictions. And smtpd_relay_restrictions is
> evaluated only if the recipient was not already blocked.
>
> restrctions[0] = rcpt_restrctions;
> restrctions[1] = warn_compat_break_relay_restrictions ?
> fake_relay_restrctions : relay_restrctions;
> for (n = 0; n < 2; n++) {
> enforce restrctions[n]
> }
>
> The newer smtpd_relay_restrictions activated later, to avoid
> unnecessary WTF experiences.
>
>> Have now explicitly defined:
>>
>> smtpd_relay_restrictions = permit_mynetworks,
>> permit_sasl_authenticated, reject_unauth_destination
>
> Fine. Just so you know, your smtpd_recipient_restrictions was not
> blocking a recipient that you are now happy to block with
> smtpd_relay_restrictions. The feature is working as intended:
> block mail that has slipped past smtpd_recipient_restrictions.
Thanks for the correction. Not sure how they were slipping past -
maybe it was one of my permit_dnswl_client lines in
smtpd_recipient_restrictions (which came before
reject_unauth_destination), but am pleased that I am now stopping
them.
Do you publish the order in which smtpd restriction lists are
processed? I thought I knew it but evidently not.
