'temporary error condition' overrides of unknown_client_reject_code 450?

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

'temporary error condition' overrides of unknown_client_reject_code 450?

PGNet Dev
my postfix config includes

        unknown_client_reject_code = 550

per docs, I understand

        The SMTP server always replies with 450 when the mapping failed due to a temporary error condition.

generally, does what I want.

a legit sender, sending from their provider, accidentally typo'd their own sender address

        [hidden email]

instead of, correctly,

        [hidden email]

my postfix instance does what I intend, and 'rejects' ...

        2020-10-28T13:15:23.753811-07:00 svr017 postfix/postscreen-internal/smtpd[24098]: NOQUEUE: reject: RCPT from smtp.clearbearing.net[64.25.214.9]: 450 4.1.8 <[hidden email]>: Sender address rejected: Domain not found; from=<[hidden email]> to=<[hidden email]> proto=ESMTP helo=<obermeyer.clearbearing.net>

but, I note, only with the temporary '450' -- not my intended '550'.

the issue i'm trying to solve is that the server on their end keeps resending the reject-ed msg every 5 mins.
been going on for days.

the sender themselves can't cure it.

their provider, 'clearbearing' has been repeatedly notified @support, asking for them to clear their queue of this message, and to fix their resend timings; so far no response/action.
i'll deal with them separately.

i _do_ need to keep receiving mail from the legit sender, from this^ provider's server; so can't simply block it outright.

questions:

        (1) _is_ unknown_client_reject_code the relevant code here?
        (2) if so, what are the specific conditions for a 450 override due to "a temporary error condition"?
        (3) what's the mechanism in postfix to force the 550, under this^ condition, for just this one send?

my inclination is to say the heck with it, let it spew endlessly, and let postscreen do its job ...

but I am interested in the narrow-case exception handling.

Reply | Threaded
Open this post in threaded view
|

Re: 'temporary error condition' overrides of unknown_client_reject_code 450?

Viktor Dukhovni
On Thu, Oct 29, 2020 at 05:44:55PM -0700, PGNet Dev wrote:

> my postfix config includes
>
> unknown_client_reject_code = 550
                ------

> a legit sender, sending from their provider, accidentally typo'd their own sender address
          ------
> 2020-10-28T13:15:23.753811-07:00 svr017
> postfix/postscreen-internal/smtpd[24098]: NOQUEUE: reject: RCPT
> from smtp.clearbearing.net[64.25.214.9]: 450 4.1.8
> <[hidden email]>: Sender address rejected: Domain not
                                   --------------
> found; from=<[hidden email]> to=<[hidden email]>
> proto=ESMTP helo=<obermeyer.clearbearing.net>

    $ postconf -d | grep '_reject_code'
    access_map_reject_code = 554
    invalid_hostname_reject_code = 501
    maps_rbl_reject_code = 554
    multi_recipient_bounce_reject_code = 550
    non_fqdn_reject_code = 504
    plaintext_reject_code = 450
    relay_domains_reject_code = 554
    unknown_address_reject_code = 450
    unknown_client_reject_code = 450
    unknown_hostname_reject_code = 450
    unknown_local_recipient_reject_code = 550
    unknown_relay_recipient_reject_code = 550
    unknown_virtual_alias_reject_code = 550
    unknown_virtual_mailbox_reject_code = 550
    unverified_recipient_reject_code = 450
    unverified_sender_reject_code = 450

Any questions?

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: 'temporary error condition' overrides of unknown_client_reject_code 450?

PGNet Dev
On 10/29/20 5:48 PM, Viktor Dukhovni wrote:

> On Thu, Oct 29, 2020 at 05:44:55PM -0700, PGNet Dev wrote:
>
>> my postfix config includes
>>
>> unknown_client_reject_code = 550
>                  ------
>
>> a legit sender, sending from their provider, accidentally typo'd their own sender address
>            ------
>> 2020-10-28T13:15:23.753811-07:00 svr017
>> postfix/postscreen-internal/smtpd[24098]: NOQUEUE: reject: RCPT
>> from smtp.clearbearing.net[64.25.214.9]: 450 4.1.8
>> <[hidden email]>: Sender address rejected: Domain not
>                                     --------------
>> found; from=<[hidden email]> to=<[hidden email]>
>> proto=ESMTP helo=<obermeyer.clearbearing.net>
>
>      $ postconf -d | grep '_reject_code'
>      access_map_reject_code = 554
>      invalid_hostname_reject_code = 501
>      maps_rbl_reject_code = 554
>      multi_recipient_bounce_reject_code = 550
>      non_fqdn_reject_code = 504
>      plaintext_reject_code = 450
>      relay_domains_reject_code = 554
>      unknown_address_reject_code = 450
>      unknown_client_reject_code = 450
>      unknown_hostname_reject_code = 450
>      unknown_local_recipient_reject_code = 550
>      unknown_relay_recipient_reject_code = 550
>      unknown_virtual_alias_reject_code = 550
>      unknown_virtual_mailbox_reject_code = 550
>      unverified_recipient_reject_code = 450
>      unverified_sender_reject_code = 450

> Any questions?

"A less patronising tone would be welcome ..."

Reply | Threaded
Open this post in threaded view
|

Re: 'temporary error condition' overrides of unknown_client_reject_code 450?

Bob Proulx
In reply to this post by PGNet Dev
PGNet Dev wrote:
> [hidden email]
>
> my postfix instance does what I intend, and 'rejects' ...

I assume this is due to use of reject_unknown_sender_domain in which
case unknown_address_reject_code applies.

    http://www.postfix.org/postconf.5.html#unknown_address_reject_code

> 2020-10-28T13:15:23.753811-07:00 svr017 postfix/postscreen-internal/smtpd[24098]: NOQUEUE: reject: RCPT from smtp.clearbearing.net[64.25.214.9]: 450 4.1.8 <[hidden email]>: Sender address rejected: Domain not found; from=<[hidden email]> to=<[hidden email]> proto=ESMTP helo=<obermeyer.clearbearing.net>

Looks perfectly normal.  This is not a problem.  This is the normal
way things are supposed to work.  It will retry for 3-5 days and then
expire the message.  It's normal.

> the issue i'm trying to solve is that the server on their end keeps
> resending the reject-ed msg every 5 mins.  been going on for days.

Usually this will go on for 3-5 days as that is the normal amount of
time for sending MTAs to keep retrying undeliverable mail.  That's the
normal behavior.  At least 3 days to bridge over a weekend until
someone can return to fix a problem.  Because failures always happen
late Friday night after the admin has already gone home for the
weekend.  And 5 days because sometimes Monday is a holiday and Tuesday
is so overworked that things don't get fixed until Wednesday.  I
shorten the time to 3 days but 5 has been a traditional retry
expiration setting.

The reason why it needs to retry is that this relies upon DNS to
resolve the sender domain.  And DNS may have a variety of temporary
failures.  Something as simple as a backbone router being overloaded
might cause a transient glitch.  Therefore at any given moment a
single failure should not cause the message to be hard rejected.
Doing so will lead to loss of mail.

> the sender themselves can't cure it.

Most users could not do anything about it.  The sending site admins
could manually review all mail that is queued and retrying and
manually delete messages that can't ever be delivered.  But there is
no good way to automatically do this.  And no one is going to manually
review all of this mail.

Instead we all let the standard control flow operate as it was
designed to operate, let it retry for 3-5 days, let it generate a
bounce message back to the sender when it expires.  And if it can't
return it to the sender then the MAILER-DAEMON will discard it at that
time.

> their provider, 'clearbearing' has been repeatedly notified
> @support, asking for them to clear their queue of this message, and
> to fix their resend timings; so far no response/action.  i'll deal
> with them separately.

I don't understand why this is a problem for you?  Since this is the
way things have been designed to work?

> my inclination is to say the heck with it, let it spew endlessly,
> and let postscreen do its job ...

That is the right answer.  Let the machine do the work.

> but I am interested in the narrow-case exception handling.

If this really annoys you that you really wanted to take manual action
you could temporarily configure your system to accept mail for the
mispelled example.con and then remove it after it has been accepted
and delivered.  If it were me I might add it to Postfix's /etc/hosts
in the chroot jail so that it would accept that misspelling.  Then
remove it after it had been delivered.

Bob
Reply | Threaded
Open this post in threaded view
|

Re: 'temporary error condition' overrides of unknown_client_reject_code 450?

Matus UHLAR - fantomas
In reply to this post by PGNet Dev
On 29.10.20 17:44, PGNet Dev wrote:
>Subject: 'temporary error condition' overrides of unknown_client_reject_code
> 450?
>
>my postfix config includes
>
> unknown_client_reject_code = 550

>my postfix instance does what I intend, and 'rejects' ...
>
> 2020-10-28T13:15:23.753811-07:00 svr017
> postfix/postscreen-internal/smtpd[24098]: NOQUEUE: reject: RCPT from
> smtp.clearbearing.net[64.25.214.9]: 450 4.1.8 <[hidden email]>:
> Sender address rejected: Domain not found; from=<[hidden email]>
> to=<[hidden email]> proto=ESMTP helo=<obermeyer.clearbearing.net>
>
>but, I note, only with the temporary '450' -- not my intended '550'.

unknown_client_reject_code uses client IP address<->hostname mapping
what you want here is unknown_address_reject_code


--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Save the whales. Collect the whole set.
Reply | Threaded
Open this post in threaded view
|

Re: 'temporary error condition' overrides of unknown_client_reject_code 450?

PGNet Dev
In reply to this post by Bob Proulx
On 10/30/20 5:04 AM, Matus UHLAR - fantomas wrote:
> unknown_client_reject_code uses client IP address<->hostname mapping
> what you want here is unknown_address_reject_code

i'd read refs for "unknown_client_reject_code"

        client without valid address <=> name mapping

'name mapping' seemed the valid issue here.

i do see in the _docs_ the _subsequent_ "is rejected by the reject_unknown_client_hostname restriction"

two strikes.

On 10/29/20 9:20 PM, Bob Proulx wrote:
> I assume this is due to use of reject_unknown_sender_domain in which
> case unknown_address_reject_code applies.
>
>      http://www.postfix.org/postconf.5.html#unknown_address_reject_code

yep. 'reject_unknown_sender_domain' is active.

got it. thx.


>> 2020-10-28T13:15:23.753811-07:00 svr017 postfix/postscreen-internal/smtpd[24098]: NOQUEUE: reject: RCPT from smtp.clearbearing.net[64.25.214.9]: 450 4.1.8 <[hidden email]>: Sender address rejected: Domain not found; from=<[hidden email]> to=<[hidden email]> proto=ESMTP helo=<obermeyer.clearbearing.net>
>
> Looks perfectly normal.  This is not a problem.  This is the normal
> way things are supposed to work.  It will retry for 3-5 days and then
> expire the message.  It's normal.

sure, the 3-5 days (ish) retry is typical.

the 'every 5 minutes' is what isn't.  at least in my experience.

making sure that the otherwise-legit sender/server doesn't get inadvertently blocked/blacklisted/etc was what got me started looking in the 1st place.

> Because failures always happen late Friday night after the admin has already gone home for the weekend.

heh

> I don't understand why this is a problem for you?  Since this is the
> way things have been designed to work?

the 'problem' is simply notice of very atypical behavior, here.

specifically, that every-5-mins resend, from a seemingly legit sender.

not that it hasn't happened when I wasn't looking, but i simply can't remember ever having noticed that retry rate from a non-spam source.

> If this really annoys you that you really wanted to take manual action
> you could temporarily configure your system to accept mail for the
> mispelled example.con and then remove it after it has been accepted
> and delivered.  If it were me I might add it to Postfix's /etc/hosts
> in the chroot jail so that it would accept that misspelling.  Then
> remove it after it had been delivered.

that certainly works to stop the retry.

as for the rest, 'let the machine do the work' sounds like the plan.