[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