Thanks a lot for your help, Mr Steinkuehler! After having followed your tips, I could fix this issue by rebuilding my mailer without ipv6 support.
Cause: ----- 1) Although the ipv6 module remains unloaded on my gentoo ws, sylpheed-claws as wheel as thunderbird have been built with ipv6 support. This follow in a first DNS request attempt for an AAAA record, which get refused by a 'server faillure' reply from the isp DNS. 2) This 'failure' reply, received by DNSCACHE on my BUC firewall get not forwarded to my workstation. 3) After timeout (5s), my workstation retry the same request, wich again receive no reply from cache. 4) After another 5s tmout, my workstation re-ask by adding my local domain suffix at the end of the mailhub FQDN it requests for. DNScache answers directly a standard 'no such name' reply 5) Finaly, my workstation re-ask for the mail hub, this time using type A, get a valid answer leting SMTP traffic begins normaly. DNScache not reporting a server failure may be an issue to correct or not, depending on what people expect for behaviour in case of malformed or wrong requests (i personaly agree completly to the current behaviour). But in any case, I will report the behaviour of my workstation to the gentoo list. Kindest regards bib On Tue, 28 Mar 2006 16:32:34 -0600 Charles Steinkuehler <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > [EMAIL PROTECTED] wrote: > > Dear all, > > I'm using buc for a while and have done a new setup of buc v3.1 few weeks > > ago. > > Since them, I observe very long delay when connecting on SMTP from LAN to > > the Internet. Waiting about 10 sec for opening SMTP (25). > > > > Furthermore I observed: > > > > 1) All other TCP services ports are working normaly. > > 2) IPTRAF on the firewall shows NEW connexion from LAN to FW and > > from FW to target SMTP server about 10 sec after having sent the message. > > 3) In the mean time, no particular traffic happens on IPTRAF screen except > > DNS > > traffic. > > 4) This is not a Auth missbehaviour (rejected with nodelay insteed of > > droped). > > 5) Connecting my workstation directly to the modem allow normal SMTP > > traffic. > > In that case, modem allow all outgoing traffic. > > 6) My WS is permanently firewalled by shorewall, allowing only few outgoing > > traffic. > > 7) I'm using following buc packages: > > LRP="root config etc local modules iptables libcrpto libm libz mawk > > shorwall ulogd dropbear ntpdate ntpsimpl dhcpd daemontl djbutils > > dnscache tinydns" > > > > My questions: > > Q1) Do anybody have made some analog experiments or > > have any idee about such a behaviour ? > > Q2) How may I refine diagnostic in order to get more acuracy in > > problem description ? > > It could be an ident timeout on the mail-server's end. Make sure you're > either rejecting ident traffic (port 113), or running a hardened identd > server on your firewall that returns generic data to all requests. > > You might also use tcpdump to watch the 3-way TCP handshake when > connecting to your mail server. I suspect the mail server is doing > something before it completes the TCP handshake, which is causing your > delay. If you can figure out what, you may be able to fix it. > > - -- > Charles Steinkuehler > [EMAIL PROTECTED] > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.0 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFEKbmCLywbqEHdNFwRApfwAJ97RD+aIY1HK6RBNl/Wur4BkOMdJQCg2K6a > U75wuyDXXvIDkTBpCW4D54c= > =ordX > -----END PGP SIGNATURE----- ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ------------------------------------------------------------------------ leaf-user mailing list: [email protected] https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
