[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: No A, no MX... but still retrying.



Hi Matti,

> Date sent:      Mon, 21 Feb 2000 17:49:38 +0200
> From:           Matti Aarnio <mea@nic.funet.fi>
> Subject:        Re: No A, no MX... but still retrying.

> > It happens that my users mistype addresses like: <user.domain@de>. 
> > Domain 'de' definitely exists. And definitely receives no mail. 
> > 
> > Instead of immediate rejection,  I have normal 2-day retry process 
> > with TRUE :-) diagnostics:
 
>     It should be minimum of 3 days - to allow long weekend.
>     Two days is a bit -- shortish..

Well. But 3 days seems to be too long without any sender 
notification... Just being looking at "delay_warning_time = [hours]" 
parameter in Postfix :-). But this is other tale. Non-existing 
feature is not a bug.
 
> >     Nov 16 14:45:07 atrium smtp[23555]: smtp; 500 (nameserver data 
> >     inconsistency. No  MX, no address: 'de' (NONAME)) r=69
> > 
> > What should I do to provide immediate rejection in case of existing 
> > non-mail-capable (no A, no MX) domain?
 
>     Yes it should, however I have seen also cases of temporary
>     DNS failures yielding same result, and I am not very happy
>     about those :-/

Mmm... I am not expert in res_query() et al, but it seems me that it 
is able to return definite reply "NO_DATA", which means that the DNS 
is available but requested RR type does not exist.

 NO_DATA        4   /* Valid name, no data for requested type */

>     I really should debug that beast someday so we have reliable
>     diagnostics of that kind -- and not "sendmail like".
>     (I mean: yielding permanent errors on temporary ones..)

In my opinion, "yelding permanent on temporary" is not much worse 
than vice-versa. In the present case, the sender knows NOTHING about 
his/her mistake for 2 (you offer 3) days. If [false] permanent error 
happens, the sender will be able to fight. Either to check (and 
correct) address or to yeld postmaster about previously working 
address failure :-). So, the task is a liitle bit more simple.
 
>     Main problem, I think, is buried deep within  getaddrinfo()
>     library, and sadly if it is faulty, there is very little
>     hope...  (Local copy - fixable - is used only if system
>     libraries don't have it...)
> 
>     Open-coding the address resolver beast at  smtp.c  would
>     perhaps yield more reliable diagnostic, but it would be
>     some 300-400 lines of code very least :-/

Yes, I am just looking in it...

>     (And not using  /etc/hosts  at all, I think..)

Surely. db/routes exists instead.

Regards,
Alexey