[xmail] xmail DNS problem : First sample
Hello Davide I restart here the various 'dns problems' for smtp delivery from xmail since I have more and more complains about users saying our server is 'bad' Configuration used : Xmail 1.22 Win32 on Windows 2000 SP4 Xmail configured to directly resolve mx queries (no smartdnshost) Local win32 Ip stack normaly configured to use a Microsoft DNS Server on another Windows 2000 SP4 (I put this info here in case this could impact xmail internal resolver...) First problem : Use of A domain entry (exist) even if Mx entries exist for the destination domain === Below is the xmail error report (relay denied but this is not the real problem) when sending mail to a account at ifrance.com [00] XMail bounce: [EMAIL PROTECTED];Error=[554 [EMAIL PROTECTED]: Relay access denied] [01] Error sending message [1119891256115.696.887d.mail0] from [groupeab.com]. ID:S30313 Mail From: [EMAIL PROTECTED] Rcpt To: [EMAIL PROTECTED] Server:ifrance.com [ifrance.com] [02] The reason of the delivery failure was: 554 [EMAIL PROTECTED]: Relay access denied [04] Here is listed the message log file: [PeekTime] 1119890607 : Mon, 20 May 2005 18:43:27 +0200 ErrCode = -82 ErrString = [RCPT TO:] not permitted by remote SMTP server ErrInfo = 554 [EMAIL PROTECTED]: Relay access denied SMAIL SMTP-Send FF = ifrance.com SMTP = mx.groupeab.com From = [EMAIL PROTECTED] To = [EMAIL PROTECTED] Failed ! SMTP-Error = 554 [EMAIL PROTECTED]: Relay access denied SMTP-Server = ifrance.com [05] Here is listed the initial part of the message: .. .. NSLookup reports from the xmail server and from the Microsoft DNS server used by xmail server ip stack : Query for MX records on ifrance.com : ifrance.com MX preference = 0, mail exchanger = mailrecv.ifrance.com ifrance.com nameserver = dns1.ifrance.com ifrance.com nameserver = dns2.ifrance.com mailrecv.ifrance.cominternet address = 82.196.5.133 mailrecv.ifrance.cominternet address = 82.196.5.132 mailrecv.ifrance.cominternet address = 82.196.5.131 mailrecv.ifrance.cominternet address = 82.196.5.130 mailrecv.ifrance.cominternet address = 82.196.5.134 dns1.ifrance.cominternet address = 82.196.5.2 dns2.ifrance.cominternet address = 82.196.5.3 Query for A record on ifrance.com : Nom :ifrance.com Addresses: 82.196.5.22, 82.196.5.20, 82.196.5.21 And a dnsreport http://www.dnsreport.com/tools/dnsreport.ch?domain=ifrance.com returnes exactly the same thing. Note that none of the Ip returned by the A record is used by any MX ... so the server at 'A' record even if accepting smtp is not responsible for ifrance.com delivery (this is not a invalid configuration). Xmail server try to connect to server 'ifrance.com' (A record) NOT on any ifrance MX ! When changing xmail config to relay ALL mail to another server (using smtpgw.tab with a *[tab]) all work fine !!! Mail is delivered by the gateway to ifrance.com without problem (to one of the various mx) !!! And the gateway is a 'simple' Microsoft SMTP service on Windows 2000 SP4 that uses the same Microsoft dns server to resolve IPs/Mxs ... Second problem : On no existing destination domains, Xmail don't return immediatly a NDR but start the 'normal' retry process === Below is the xmail file report when sending mail to a account at 'no existing' domain 'apem.gr' [PeekTime] 1147966006 : Thu, 18 May 2006 17:26:46 +0200 ErrCode = -40 ErrString = Invalid server address ErrInfo = apem.gr SMAIL SMTP-Send FF = apem.gr SMTP = mx.groupeab.com From = [EMAIL PROTECTED] To = [EMAIL PROTECTED] Failed ! SMTP-Error = 417 Temporary delivery error SMTP-Server = apem.gr [PeekTime] 1147990673 : Fri, 19 May 2006 00:17:53 +0200 ErrCode = -40 ErrString = Invalid server address ErrInfo = apem.gr SMAIL SMTP-Send FF = apem.gr SMTP = mx.groupeab.com From = [EMAIL PROTECTED] To = [EMAIL PROTECTED] Failed ! SMTP-Error = 417 Temporary delivery error SMTP-Server = apem.gr [PeekTime] 1147998436 : Fri, 19 May 2006 02:27:16 +0200 [PeekTime] 1148015781 : Fri, 19 May 2006 07:16:21 +0200 ErrCode = -40 ErrString = Invalid server address ErrInfo = apem.gr SMAIL SMTP-Send FF = apem.gr SMTP = mx.groupeab.com From = [EMAIL PROTECTED] To = [EMAIL PROTECTED] Failed ! SMTP-Error = 417 Temporary delivery error SMTP-Server = apem.gr .. .. (same til last retry then ndr send to sender). Dns lookup for agem.gr returns 'No existing domain' (from xmail server or microsoft dns server), as dnsreport too (http://www.dnsreport.com/tools/dnsreport.ch?domain=apem.gr) Xmail try to send and retries, retries, until the final retry. So the Ndr is received only one or two days (depending of the retry parameter) after the initial sending (many customers send and resend the mail during this retry period because the receiver tell them no mail coming ! so the queue generaly have multiple times the same
[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]
[xmail] Mail is triggered by CustMapsList in server.tab
I've moved my mail-server to another server, and I'm starting to get problems with the... CustMapsList list.dsbl.org:1,relays.ordb.org:1,sbl.spamhaus.org:1 in server.tab. No matter what IP is trying to deliver a mail this is what ends up in the logs: 193.10.166.xxx 2006-05-22 11:20:31 SNDRIP=EIPMAP (list.dsbl.org) And this error is returned to sender: 550 Relay denied. Your IP is a known spam relay (list.dsbl.org) The IP is NOT listed in the list.dbsl.org and just to be on the safe side, I've sent mail from all over the place, all resulting in the same error. If I remove list.dsbl.org from the list, the next server (relays.ordb.org) triggers the same error. Indeed, If I put some bogus blahablaha.org server in CustMapsList that server also triggers the same error. If I remove the CustMapsList from server.tab, the mail is delivered normally. This is a vanilla debian installation, running XMail v1.22. Help? :o) - 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]
[xmail] Re: xmail DNS problem : First sample
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.
[xmail] Re: Mail is triggered by CustMapsList in server.tab
Andréas, first I'd suggest proving your DNS is good. Please try a few DIGs (127.0.0.2 should return true as a test for most BLs) Obviously change localhost for your DNS server if it is not localhost. dig @localhost 2.0.0.127.list.dsbl.org. a dig @localhost 2.0.0.127.relays.ordb.org. a dig @localhost 2.0.0.127.sbl.spamhaus.org. a Then start changing address for those you have problems with - remember to reverse it like PTR records. See that you get what you expect - no record returned means - not Blocked. Double check that you *know* which DNS server xmail is using, then test. Perhaps even try SmartDnsHost in server.tab Rob :-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andréas Bratell Sent: Monday, 22 May 2006 9:32 PM To: xmail@xmailserver.org Subject: [xmail] Mail is triggered by CustMapsList in server.tab I've moved my mail-server to another server, and I'm starting to get problems with the... CustMapsList list.dsbl.org:1,relays.ordb.org:1,sbl.spamhaus.org:1 .in server.tab. No matter what IP is trying to deliver a mail this is what ends up in the logs: 193.10.166.xxx 2006-05-22 11:20:31 SNDRIP=EIPMAP (list.dsbl.org) And this error is returned to sender: 550 Relay denied. Your IP is a known spam relay (list.dsbl.org) The IP is NOT listed in the list.dbsl.org and just to be on the safe side, I've sent mail from all over the place, all resulting in the same error. If I remove list.dsbl.org from the list, the next server (relays.ordb.org) triggers the same error. Indeed, If I put some bogus blahablaha.org server in CustMapsList that server also triggers the same error. If I remove the CustMapsList from server.tab, the mail is delivered normally. This is a vanilla debian installation, running XMail v1.22. Help? :o) - 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]
[xmail] Re: xmail DNS problem : First sample
Hi All... Ok, DNS is a strange beast at best. One of the main problems I have found, is people having TTLs of 0 seconds. Effectively the query has timed out before it has returned. This does not seem to be the case in the mentioned domains, i.e. ifrance.com etc. It does make sense about what Rob said, about the DNS being slow, and it ending up with an A record. Our DNSCaches are actually configured to do minimal answers, which would trigger such a problem. I have however not see that yet. What you want is to have your dnscache returns as much data on the same as possible. However, I am not sure how XMail will deal with that. Being a legacy definition, new mail servers should actually never look up the A record. This is so by the way a huge favourite of spammers. Our domain used to have an a record, and I had a server sitting on it, accepting ALL mail for our domain, and basically it was 99.999% spam. The 1 in 1 that was valid can kiss my backside... We therefore removed the A record. Normally it would be better to ensure that the server the a record points to, does not answer on SMTP, or rejects connections. (Network error, forcing retry...) Again, I am not sure if XMail actually re-looks at the DNS before sending email, or does it look at it's own records, i.e. the A-record. In practicality, the MTA should re-query the DNS every time it tries to send it. Therefore, fancy nice to have feature would actually be a server config, which specifies if the server should fall back to A record delivery, or not. However, this might be counter-RFC's for all I know... I do believe to put a local DNS caching program on our mail servers, to alleviate issues like over-expiry etc. Your server's cache would be more specific to it's own environment, as well as the Hosts connecting to it, and being connected to. (Streamline cache content.) You could possibly also tweak the local DN server to your needs, i.e. lengthen/shorten negative expiry, and possibly even tell it to not lookup A records on domains... (Might be tricky, as you need to look up the A record for the mail server...) The one I like to use is PDNSD, which I am not sure if there is one for the windows platform. The beauty about this one is the fact that it saves its cache to disk on shutdown, and reloads it again on startup, allowing for quick startup times. Homepage for PDNSD: http://www.phys.uu.nl/~rombouts/pdnsd.html -- Best regards, Jornmailto:[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]
[xmail] Re: xmail DNS problem : First sample
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] la part de Francesco Vertova
Envoyé : lundi 22 mai 2006 13:16
À : xmail@xmailserver.org
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]
[xmail] Re: Mail is triggered by CustMapsList in server.tab
I've done the digs Rob suggested and it reports as it should, ie 127.0.0.2
(2.0.0.127) is a positive, almost all others (collected with a cat
smtp-20060522 | grep EIPMAP | awk '{print $3}' ) were negatives.
You might also want to check what dns queries your machine
generates by looking at them with a TCP Dump, which will tell
you where it might actually get a false positive, i.e.:
tcpdump -n -i interface port 53
Yep, it just doesn't tell me much. :P
15:47:31.807840 IP 81.171.111.61.4215 81.171.111.156.53: 33139+ A?
13.166.10.193.relays.ordb.org. (47)
15:47:31.949345 IP 81.171.111.156.53 81.171.111.61.4215: 33139 NXDomain*
0/0/0 (47)
15:47:31.949573 IP 81.171.111.61.4215 81.171.111.156.53: 33140+ A?
13.166.10.193.relays.ordb.org.com. (51)
15:47:31.949850 IP 81.171.111.156.53 81.171.111.61.4215: 33140
4/0/0[|domain]
[...]
My list looks as follows:
CustMapsList
relays.ordb.org.:1,rhsbl.sorbs.net.:1,zombie.dnsbl.sorbs.net.:1,
dnsbl.sorbs.net.:0,bl.spamcop.net.:0
And it works without a problem.
Mine also worked without a problem until I put my xmail on another server.
Funny thing - with your CustMapsList and after initial tesing - it works.
So, somehow it's that tiny dot that makes all the difference. So, I must
ask, what do you mean by the dot fully qualify the domain? Does this
DNS-server work differently than the one I used to use? :P
Maybe I should take the course DNS 101 to figure this out. :o)
Thanks for the help Jorn and Rob!
Regards
Andréas Bratell
-
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]
[xmail] Re: xmail DNS problem : First sample
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Rob Arends Envoyé : lundi 22 mai 2006 14:35 À : xmail@xmailserver.org Objet : [xmail] Re: xmail DNS problem : First sample 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. Notice that I sayed that I don't use anymore smartdnshost : In my previous configuration xmail 1.19 + smartdnshost pointing to the local Microsoft DNS I never had this problem. When I updated xmail to 1.21, with smartdnshost intact, I got the problem. After first discussion for this problem on the list, some suggested to not use smartdnshost to avoid use of the local Microsoft dns that could be the problem. So, I removed 'smartdnshost', and now (normally ?) xmail only use its own internal resolver, not the local resolver (yes ? no ?) nor the local microsoft Dns (yes ? no ?) and I have the problem too ... I'm disappointed ... I will try to use 'Bind named', thanks Rob for your tip 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. That a good question ;) 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. IMHO, it is simply not the 'job' of a mail server program to 'resolve, cache, ...' dns queries ;) and it should let the local os resolver do the job. At least, I don't think caching the resulting dns query for future use really 'enhance' the response time for 'delivery' as in many cases the responding dns server (in most cases local or isp dns) do some cache by itself (especially true when using 'smartdnshost'). --- 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) Thanks again Rob, I will reduce too the -Q parameters on my xmail server. (but this do not resolve the problem, just reduce the ndr timing ...) I hope that helps someone. Rob :-) Yes, it does :) Francis - 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]
[xmail] Re: Mail is triggered by CustMapsList in server.tab
Andréas, that's great news.
Re:
So, I must ask, what do you mean by the dot fully qualify the domain?
It's like the difference between var/mailroot and /var/mailroot
Because dns is reversed in it's structure the root is on the right.
Eg:
Folders = /1/2/3/4/5
DNS = 5.4.3.2.1.
What actually happens when you DIG without a root dot, is that it tries the
concatenating the local domain of your pc/server as a suffix to your
request. When that fails it tries one domain higher, etc until the local
domain is just a dot, then it will find the domain as it should. So you dns
queries should be marginally faster with a root dot.
EG. Local domain is mydomain.com.
Lookup FQ host, host.onedomain.com
Resolves as host.onedomain.com.mydomain.com.
This fails and tries host.onedomain.com.com.
This fails and tries host.onedomain.com.
Tada, resolved.
Interesting to note I also have root dots on my CustMapsList.
Rob :-)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Andréas Bratell
Sent: Tuesday, 23 May 2006 12:43 AM
To: xmail@xmailserver.org
Subject: [xmail] Re: Mail is triggered by CustMapsList in server.tab
I've done the digs Rob suggested and it reports as it should, ie 127.0.0.2
(2.0.0.127) is a positive, almost all others (collected with a cat
smtp-20060522 | grep EIPMAP | awk '{print $3}' ) were negatives.
You might also want to check what dns queries your machine generates by
looking at them with a TCP Dump, which will tell you where it might
actually get a false positive, i.e.:
tcpdump -n -i interface port 53
Yep, it just doesn't tell me much. :P
15:47:31.807840 IP 81.171.111.61.4215 81.171.111.156.53: 33139+ A?
13.166.10.193.relays.ordb.org. (47)
15:47:31.949345 IP 81.171.111.156.53 81.171.111.61.4215: 33139 NXDomain*
0/0/0 (47)
15:47:31.949573 IP 81.171.111.61.4215 81.171.111.156.53: 33140+ A?
13.166.10.193.relays.ordb.org.com. (51)
15:47:31.949850 IP 81.171.111.156.53 81.171.111.61.4215: 33140
4/0/0[|domain]
[...]
My list looks as follows:
CustMapsList
relays.ordb.org.:1,rhsbl.sorbs.net.:1,zombie.dnsbl.sorbs.net.:1,
dnsbl.sorbs.net.:0,bl.spamcop.net.:0
And it works without a problem.
Mine also worked without a problem until I put my xmail on another server.
Funny thing - with your CustMapsList and after initial tesing - it works.
So, somehow it's that tiny dot that makes all the difference. So, I must
ask, what do you mean by the dot fully qualify the domain? Does this
DNS-server work differently than the one I used to use? :P
Maybe I should take the course DNS 101 to figure this out. :o)
Thanks for the help Jorn and Rob!
Regards
Andréas Bratell
-
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]
[xmail] Re: xmail DNS problem : First sample
See inline. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of CLEMENT Francis Sent: Tuesday, 23 May 2006 2:26 AM To: 'xmail@xmailserver.org' Subject: [xmail] Re: xmail DNS problem : First sample -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Rob Arends Envoyé : lundi 22 mai 2006 14:35 À : xmail@xmailserver.org Objet : [xmail] Re: xmail DNS problem : First sample Notice that I sayed that I don't use anymore smartdnshost : I hadn't. But all that means is that the local DNS is not at fault -and- that there lies something to be tweaked in the Xmail dns resolver / cache / resend logic. 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 tried this, it was ok) I have seen this (was a couple of versions ago), and in fact just stop/start xmail was enough to allow delivery. IMHO, it is simply not the 'job' of a mail server program to 'resolve, cache, ...' dns queries ;) and it should let the local os resolver do the job. At least, I don't think caching the resulting dns query for future use really 'enhance' the response time for 'delivery' as in many cases the responding dns server (in most cases local or isp dns) do some cache by itself (especially true when using 'smartdnshost'). I agree, on failure, the xmail dns cache must be ignored. The reason xmail cannot connect to remote server could be a problem with dns. And when using 'smartdnshost', there is less reason to have an xmail dns cache altogether. Note that on xmail servers that don't have dns timeout issues (assuming this is the cause) then they would never see the problem, because xmail always gets the MX records first time. In summary of this thread, I believe: 1. The cause of Xmail getting an A record when MX records exist is due to dns timeouts 2. The cause of Xmail not being able to send on next attempt is due to xmail using its dns cache regardless of previous send failure. 3. The local Xmail dns caching is still used when using 'smartdnshost'. 4. Possibility of xmail needing restart to clear some internal memory of previous mx lookups. I would like to ask for the following bug-fixes: 1. Xmail should ignore it's dns cache re-resolve the domain, if this is not the first try to send this email. 2. Either have an option to disable the xmail dns cache, or disable it automatically when 'smartdnshost' used. This could be a tri-state switch 0,1,2. or off,on,auto - auto being off when smartdnshost=true, and on when smartdnshost=false. Rob :-) - 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]
