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 <legitsen...@example.con>: Sender 
address rejected: Domain not found; from=<legitsen...@example.con> to=<m...@mydomain.com> 
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.

Reply via email to