454 4.7.1 Relay access denied

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

454 4.7.1 Relay access denied

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?
Reply | Threaded
Open this post in threaded view
|

Re: 454 4.7.1 Relay access denied

Wietse Venema
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.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: 454 4.7.1 Relay access denied

Dominic Raferd
On 29 April 2018 at 17:16, Wietse Venema <[hidden email]> 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. Have now explicitly defined:

smtpd_relay_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination
Reply | Threaded
Open this post in threaded view
|

Re: 454 4.7.1 Relay access denied

Wietse Venema
Dominic Raferd:

> On 29 April 2018 at 17:16, Wietse Venema <[hidden email]> 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.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: 454 4.7.1 Relay access denied

Dominic Raferd
On 29 April 2018 at 17:51, Wietse Venema <[hidden email]> wrote:

> Dominic Raferd:
>> On 29 April 2018 at 17:16, Wietse Venema <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: 454 4.7.1 Relay access denied

Viktor Dukhovni


> On Apr 29, 2018, at 2:03 PM, Dominic Raferd <[hidden email]> wrote:
>
> 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.

Indeed that permit SHOULD NOT precede reject_unauth_destination if
the intent is to use the recipient restrictions also for relay
control (the traditional combined role).

It is good to see relay restrictions working as intended.  The all
in one approach can be fragile.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: 454 4.7.1 Relay access denied

Wietse Venema
In reply to this post by Dominic Raferd
Dominic Raferd:
> Do you publish the order in which smtpd restriction lists are
> processed? I thought I knew it but evidently not.

http://www.postfix.org/SMTPD_ACCESS_README.html

But it lists smtpd_relay_restrictions in the wrong place (before
smtpd_recipient_restrictions). It's fixed now.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: 454 4.7.1 Relay access denied

Dominic Raferd


On 29 April 2018 at 21:46, Wietse Venema <[hidden email]> wrote:
Dominic Raferd:
> Do you publish the order in which smtpd restriction lists are
> processed? I thought I knew it but evidently not.

​​
http://www.postfix.org/SMTPD_ACCESS_README.html


But it lists smtpd_relay_restrictions in the wrong place (before
smtpd_recipient_restrictions). It's fixed now.

​Thanks, but the change in the web page isn't apparent to me.
Reply | Threaded
Open this post in threaded view
|

Re: 454 4.7.1 Relay access denied

Wietse Venema
Dominic Raferd:

> On 29 April 2018 at 21:46, Wietse Venema <[hidden email]> wrote:
>
> > Dominic Raferd:
> > > Do you publish the order in which smtpd restriction lists are
> > > processed? I thought I knew it but evidently not.
> >
> > ??
> > http://www.postfix.org/SMTPD_ACCESS_README.html
> >
> > But it lists smtpd_relay_restrictions in the wrong place (before
> > smtpd_recipient_restrictions). It's fixed now.
>
> ?Thanks, but the change in the web page isn't apparent to me.

Fixed in the source code. You may see it later today on the web.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: 454 4.7.1 Relay access denied

Viktor Dukhovni


> On Apr 30, 2018, at 6:57 AM, Wietse Venema <[hidden email]> wrote:
>
>>> http://www.postfix.org/SMTPD_ACCESS_README.html
>>>
>>> But it lists smtpd_relay_restrictions in the wrong place (before
>>> smtpd_recipient_restrictions). It's fixed now.
>>
>> ?Thanks, but the change in the web page isn't apparent to me.
>
> Fixed in the source code. You may see it later today on the web.

Looks good now.

--
        Viktor.