>-----Message d'origine-----
>De : [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] la part de Francesco Vertova
>Envoyé : lundi 22 mai 2006 13:16
>À : [email protected]
>Objet : [xmail] Re: xmail DNS problem : First sample
>
>
>
>At 12.30 22/05/06, you wrote:
>
>>First problem : Use of A domain entry (exist) even if Mx entries 
>>exist for the destination domain
>
>>[<00>] XMail bounce: [EMAIL PROTECTED];Error=3D[554
>><[EMAIL PROTECTED]>: Relay access denied]
>
>(preliminary: my nslookup reports "non-authoritative answer" for 
>ifrance.com and this might be part of the problem).

An 'non-authoritatie answer' is usual as many isp's do local 'dns caching',
and this is not a problem as long as the 'dns cache' observes the various
refresh times of the zone. But yes it could be.

Here when I do a nslookup from my xmail server, I don't get
'non-authoritative answer' and get a list of mx for ifrance.com ...
And xmail mx cache file ifrance.com contains :
86400
0:mailrecv.ifrance.com.

?!?!?!
So xmail resolver obtained the good mx response !
So why xmail try to send the A pointer ?

(If I remember correctly, I never had this type of problem with xmail <=
1.19 and the problem seemed to start when I updated directly from 1.19 to
1.21, and continue with 1.22)

The strange think is that if I stop xmail, clear xmail dns cache (even if
cache is good) and restart xmail, sending new mail to ifrance.com is then ok
.... (not sure that this will become ok in all stop/clear/start cases, but at
time I tryed this, it was ok)


>This behaviour - XMail trying A even if MX exists - has been reported 
>on this list from time to time, without a final answer. Possible 
>cause: a temporary/intermittent problem with MX - DNS timeout? - and 
>XMail falls back on A, even though MX might be available a bit later. 
>Possible solution (read: suggestion for Davide's long queue): XMail 
>should distinguish in DNS matters between a negative answer and 
>silence (timeout) and only fall back on A in the first case. The 
>contrary risks turning a delay into a permanent failure, I think ...
>

If there is a timeout when trying to resolving for the domain mx's, I think
Xmail should not fall back to A domain pointer, and retry to resolve with
same 'schedule' process timing used with 'normal' retries, and only fall
back to A pointer when a good dns response (no dns error or timeout) is
received but saying 'no mx entry found'.
In many cases, the domain A pointer don't exist at all, and if it exists, it
does not have the 'mx' role at all and its smtp configuration (if smtp port
really reachable at this ip) is usually only for 'outgoing' mails (web
server, ...) so, in many cases, use of the A pointer result in fatal error
when trying to send to them ...

To resume, I think that Xmail should use only the A pointer as a fall back
when and only when there is at least one dns successfull response saying
exactly 'no mx entry found for this domain'.
In all others cases, try to resolve the mx until a good dns response with mx
entries (if no response retry with same retry schedule used for normal mail
retry schedule, and ndr if last attempt), and then use only the mx entries.

>>Second problem : On no existing destination domains, Xmail don't 
>>return immediatly a NDR but start the 'normal' retry process
>
>My old IMS mailserver would give up immediately on a non-existing 
>domain and keep trying on a network error. XMail treats the two as 
>equivalent, and this seems to be a common design of "modern" 
>mailservers (I'm told that M$ SMTPSVC behaves exactly likes XMail). 
>Sincerely, I preferred the old-fashion way, since 99% of 
>"non-existing domains" are typos or parsing errors on the client 
>side. But you know ...

IMHO, it's not because some other mail servers do like this on 'no existing
domains', that it is the good way to do the job ;)
And yes, I preferre too the 'old-fashion' way, and imho, that's the good
('rfc compliant' ?) way.

Francis

>
>Ciao, Francesco
>
>-

-
To unsubscribe from this list: send the line "unsubscribe xmail" in
the body of a message to [EMAIL PROTECTED]
For general help: send the line "help" in the body of a message to
[EMAIL PROTECTED]

Reply via email to