<SNIP> >Now, from here, I can conenct to your Web home page. I can also >connect to >your SMTP server, but with a long delay: > >[EMAIL PROTECTED]:~$ telnet kroffts.com 25 >Trying [a.b.c.d - address deleted]... >Connected to dhcp024-210-193-152.woh.rr.com. >Escape character is '^]'. >[delay between 2 and 3 minutes here] >220 kroffts.dmz ESMTP >HELO comarre.com >250 kroffts.dmz >MAIL from: [EMAIL PROTECTED] >250 ok >RCPT To: [EMAIL PROTECTED] >250 ok >DATA >354 go ahead >THis is a test of my ability to send a message from an >offsite >location to the test user on the mail server. Kory -- see if >it >shows up.
The message is not present in ~home/lrpqmail/Maildir/new /var/log/qmail/smtpd/current contains: 2003-12-26 00:16:34.446332500 tcpserver: status: 1/40 2003-12-26 00:16:34.446543500 tcpserver: pid 1004 from 63.198.182.124 2003-12-26 00:18:21.622852500 tcpserver: ok 1004 :192.168.10.1:25 adsl-63-198-182-124.dsl.snfc21.pacbell.net:63.198.182.124::33141 2003-12-26 00:20:21.448853500 tcpserver: end 1004 status 0 2003-12-26 00:20:21.448865500 tcpserver: status: 0/40 2003-12-26 01:18:33.508520500 tcpserver: status: 1/40 2003-12-26 01:18:33.508731500 tcpserver: pid 27702 from 61.255.155.150 2003-12-26 01:19:56.321580500 tcpserver: ok 27702 :192.168.10.1:25 :61.255.155.150::1113 2003-12-26 01:19:56.326303500 tcpserver: end 27702 status 256 2003-12-26 01:19:56.326316500 tcpserver: status: 0/40 /var/log/qmail/qmail/current contains: 2003-12-26 09:01:07.062891500 status: local 0/10 remote 1/20 2003-12-26 09:01:07.409834500 delivery 39: deferral: Sorry,_I_wasn't_able_to_establish_an_SMTP_connection._(#4.4.1)/ 2003-12-26 09:01:07.409852500 status: local 0/10 remote 0/20 2003-12-26 09:04:08.402813500 starting delivery 40: msg 10039 to remote [EMAIL PROTECTED] 2003-12-26 09:04:08.402826500 status: local 0/10 remote 1/20 2003-12-26 09:04:08.819743500 delivery 40: deferral: Sorry,_I_wasn't_able_to_establish_an_SMTP_connection._(#4.4.1)/ 2003-12-26 09:04:08.819760500 status: local 0/10 remote 0/20 >250 ok 1072398018 qp 4166 >quit >221 kroffts.dmz >Connection closed by foreign host. > >The length of the delay still points to a DNS problem as the likely >culprit. ALthough you should check to see if the test message >reflected in >the above interaction actually reached lrpqmail's INBOX. > >To pin the problem down, you need to do some more tests. > >First, can the mail server resolve various types of FQNs? Examples >would be > >its own FQN yes, but... >a LAN client's FQN yes, but both names are in the local /etc/hosts file so it probably is not using dns. (Qmail does not use the hosts file) >an external FQN (try comarre.com) pinging comarre.com works fine. Oddly, I should not be able to actually ping it since there is no rule allowing icmp 8 packets from dmz to net but I was able to ping it. It must be included in some other rule. >The easy way to check this is by trying to ping the various FQNs >from the >mail server; ping first requests a lookup to get the relevant IP >address, >then does the ping. For example: > >[EMAIL PROTECTED]:~$ ping celine.comarre.lan >PING celine.comarre.lan (192.168.1.23): 56 data bytes >64 bytes from 192.168.1.23: icmp_seq=0 ttl=254 time=736.0 ms >[...] > >You don't care if the server can actually ping, just if it can do >the >name-to- address mapping. > >Second, can it do reverse lookups of LAN and external addresses? You >can't >use ping for this, and I don't recall what app like host or nslookup >is >available for Bering, but you'll need to find one. > >Probably you will have some trouble with this, because I see an >error in >the mail server's /etc/resolv.conf file -- > >/etc/resolv.conf >domain kroffts.dmz >nameserver 127.0.0.1 >nameserver 192.168.1.254 >nameserver 192.168.10.254 > >The first "nameserver" line points back to the mail server itself >(as >localhost), but your package list for it includes no DNS server. So >delete >that line and then try the tests. You probably do NOT need botrh >other >lines, and which you do need depends on how you have tinydns >configured (if >I remember right, tinydns only listens on one interface, not all >interfaces >.... you probably want it to listen on eth2 and leave in the last >"nameserver" line above). I fixed the resolv.conf. I then ran host on the dmz machine with the following results. # host 192.168.1.1 1.1.168.192.IN-ADDR.ARPA domain name pointer coventry.kroffts.home kroffts_web: -root- # host 192.168.1.5 Host not found. kroffts_web: -root- # host 192.168.1.254 254.1.168.192.IN-ADDR.ARPA domain name pointer markii.kroffts.home kroffts_web: -root- # host 192.168.10.1 Host not found, try again. It can resolve other machines but not itself. Should it be able to? I would think it should and that this is a big part of the problem. > >Now, it looks like you have not provided enough information to >tinydns in >the /etc/tinydns-private/root/data file. You have entries for the >mail >serve itself and for the router, but not for the LAN clients. Beause >they >have no entries, reverse lookups of their addresses will not >resolve, >retaining the same problem you had before. (At least I think this is >so. I >run BIND here, not tinydns, so I'm relying on reading the man pages >for >tinydns and tinydns-data at > >http://www.die.net/doc/linux/man/man8/tinydns.8.html ) > >As to dnscache ... you have not provided any information about its >configuration, and it (not tinydns) is what will handle reverse- >lookup >queries for off-LAN hosts (like my address when I try to telnet to >the mail >server's port 25). Although I recall someone else in this thread >saying >that dnscache and tinydns worked together well, my own recollection >(admittedly from some years back) is that they will not both listen >on the >same por on the same interface (IP address). The tutorial discussion >at >http://cr.yp.to/djbdns.html does not seem to describe any >configuration in >which dnscache and tinydns run on the same server (though I may have >missed >one). Here is the dnscache info: /etc/dnscache/env/IP 192.168.1.254 192.168.10.254 /etc/dnscache/env/IPQUERY 192.168 cachelog is on Forward only is off > >Someone who is using both on a LEAF/Bering router should step in >here to >help. Getting this right in your setting ... where you use tinydns >to >resolve LAN names, not names you are externally authoritative for >... is >just sufficiently non-standard that getting it right may be tricky >with >these two separate programs (in contrast to the more integrated >BIND, where >it is as easy as pie). > >Your problem with other users probably does derive from their having >non-standard home directory locations ... but you'll need a qmail >expert to >help you sort that one out. > >From now on, any time you test connectivity, wait 5 minutes (look at >your >watch, don't guess) before you conclude that some host cannot >connect to >the mail server (for SMTP, POP3, or anything else). If you skip this >step, >you won't be ruling out DNS problems as the cause. > Thanks, Kory ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
