[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SMTP policy and DNS temporary unavailability
Hello.
On 22 Feb 00 at 17:26, Alexey Lobanov wrote:
> Subject: Re: No A, no MX... but still retrying.
> One of my REAL problems is false smtp-policy
> rejections for my direct clients at RCPT TO: stage because of
> temporary complete DNS unavailability. Happily, most of this Zmailer
> host senders use UUCP now.
Well, now I'll try to describe it in details.
I use the following ruleset from default template:
======
# -- 2nd alternate: No MX target usage, DNS existence verify
. relaycustomer - relaytarget - senderokwithdns +
[0.0.0.0]/0 relaycustomer - relaytarget - senderokwithdns +
========
It satisfies me in all cases except one. When my direct client sends
mail for relaying AND destination domain cannot be resolved because
of DNS timeout, the mail is rejected with diagnostics:
#remote from [195.208.114.60]:772
rHELO ip-0.wplus.net
w250 atrium.cor.neva.ru expected "HELO ppp2.cor.neva.ru"
rMAIL FROM:<*****@ric.cor.neva.ru>
w250 2.1.0 Sender syntax Ok
rRCPT TO:<*****@LILLY.COM>
# -- policy result=-104, msg: <NONE!>
w 453-4.4.3 Policy analysis reports temporary DNS error
w 453-4.4.3 with this target domain. Retrying may help,
w 453-4.4.3 or if the condition persists, some further
w 453-4.4.3 work may be in need with the target domain
w 453 4.4.3 DNS servers.
r QUIT
But I do not want to check recipient DNS at this stage! "RCPT TO:"
must be checked for formal correctness ("where is @ in that?") in all
cases, then for Relaytarget - if sender is not my direct client, and
that's all. Checking DNS for "RCPT TO:" invokes nothing but false
rejections and useless dial-in time wasting. Also, offering "retry:"
to dialup client is not a good idea. It must have either 5xx final
rejection or immediate acception with further diagnostic upon next
call.
What should I change to avoid this behavior? Note that all the other
stages are perfect. DNS check for "MAIL FROM" is good feature even
for direct clients, as far as nobody should send mail originated from
non-existing domain.
Regards,
Alexey