[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