As I have had issues before with DNS & Xmail not playing correctly, I thought I'd add my $0.02.
I am currently running 1.22 on Win2kSP4 - same as Francis. I also have in SERVER.TAB "SmartDNSHost" "10.90.10.150:udp;" Previously I had the dreaded 'A' record problem, but now do not. I WAS running MS DNS, but am now running BIND NAMED in place of the MS DNS (on the same box as Xmail). There is NO absolute information that proves the move from MS DNS to NAMED was the solution, but it has offered me some enhancements, like 'views', so I'm unwilling to move back to MS DNS. I do get the DNS timeouts that Francesco describes. I notice it mostly when running DIG & looking for a domain that the server has not cached. Usually I re-run DIG immediately, and I get the records. This just means the my client gives up before the records are returned to my NAMED server, and on to the client - about 2 seconds. I had this same issue with MS DNS. This *might* be the root cause of the whole thing. How much the DNS timeouts affect Xmail I cannot say. But it would only affect the first attempt to send mail, after that the dns records would be cached locally in MS DNS / NAMED. So I kinda think that it should not create a failure to send - *Unless* xmail tries the previous record that it had retrieved. Just expanding on that ..... 1.Xmail asks dns for 'MX' on domain yy.com. 2.DNS has no info cached on yy.com, asks root servers and works it's way down to authoritative server. 3.DNS does not return records in time to xmail. 4.Xmail assumes no response and asks dns for 'A' on domain yy.com. 5.DNS returns record because it now has the NS records cached and can go direct to the source. 6.Xmail has an IP address for domain yy.com, caches the dns records and tries to send. 7.Xmail is rejected for trying to relay, etc. 8.Xmail retires, but does not re-resolve the domain. 9.email is bounced as undeliverable. Now I'm not saying THAT is EXACTLY what xmail does, but if it does, that would go a long way to resolving the "A" record syndrome. I note that even though I have "SmartDNSHost" set, xmail still populates mailroot/dnscache/mx Possibly confirming my guess work above. I'd prefer to be able to turn of xmail's dnscache when using "SmartDNSHost", as I don't see it enhances performance when "SmartDNSHost" is used. More than likely it makes debugging more difficult. Perhaps Davide could clarify if Xmail relies on it's cached dns records in case of retried sending. --------------- On Francesco's comment about the 'old-fashion way'; I agree I liked it better when you knew there was a problem (your's or network's), but there are those 'end-users' that don't care that your link is down for a short while - why should that mean they have to send the email again - can't you queue it? And we find ourselves in the situation we are in now - Damned if you do and Damned if you don't. I have tuned my retries down to about half a day over 10 retries, rather than 32 over 2 days. I find that helps put me in the middle ground between the "incorrectly typed address" and the "oops, my link is down" scenarios. These are the values I use on xmail cmd line: "-Qt 600 -Qi 2 -Qr 10" These are the retries that produces. >perl zinc.pl 600 2 10 01 send-time = 0 (00:00:00) next-try = 600 (00:10:00) 02 send-time = 600 (00:10:00) next-try = 900 (00:15:00) 03 send-time = 1500 (00:25:00) next-try = 1350 (00:22:30) 04 send-time = 2850 (00:47:30) next-try = 2025 (00:33:45) 05 send-time = 4875 (01:21:15) next-try = 3037 (00:50:37) 06 send-time = 7912 (02:11:52) next-try = 4556 (01:15:56) 07 send-time = 12468 (03:27:48) next-try = 6834 (01:53:54) 08 send-time = 19303 (05:21:43) next-try = 10251 (02:50:51) 09 send-time = 29554 (08:12:34) next-try = 15377 (04:16:17) 10 send-time = 44932 (12:28:52) next-try = 23066 (06:24:26) I hope that helps someone. Rob :-) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Francesco Vertova Sent: Monday, 22 May 2006 9:16 PM To: xmail@xmailserver.org Subject: [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). 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 ... >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 ... 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] - 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]
