On Tue, 07 Oct 2003 at 13:32:59 -0300, Agustín Ciciliani wrote: > Hi Everybody, > > I'm having an issue with qmail and my server to send mails to some domains. > Here is the error. This have been happening for three weeks. > > qmail says: > Sorry, I wasn't able to establish an SMTP connection. (#4.4.1) > I'm not going to try again; this message has been in the queue too long. > > If I send the e-mail with any other server (even Windows or Linux) it goes > through normally. > > I've perform all these tests, and they're all right: > > - Resolve MX of the domains. > - Traceroutes to the servers > - Pings to the servers > - Nmap found all the ports that must be open, particularly the 25. > - I've talked to the network administrators of the domains that I can't > reach and they've told me that there is no block for my IP address > (firewalls, blacklists, etc.) > > The only BIG PROBLEM is that I cannot make "telnet (mailserver) 25". It ends > in a time out after a minute. I've also talked with my ISP, and It's not a > routing problem. If it was a routing problem, I couldn't reach the domains > with any other servers of my subnet... (that already happened to me). > > These are some of the mail servers that I can't reach with my Debian: > mail.matrocolayasoc.com.ar, mail.skytel.com.ar, mail.ecogas.com.ar, and > others... > > I'm running a Linux version 2.4.20-pre8 (gcc version 2.95.4 20011002 (Debian > prerelease)) > > I appreciate any comment. > > Yours Sincerely, > > Agustín
I checked them from various machines and I can see that some firewall on the route to these servers is broken. It behaves according to RFC793, not RFC2481 (I'm not sure about these numbers at the moment). I mean that it doesn't let through TCP packets with ECN bit set (Explicit Congestion Notification), and most probably your machine sends such packets. If 'cat /proc/sys/net/ipv4/tcp_ecn' returns "1", then the machine sends such packets. You can overcome this problem by means of disabling ECN with 'echo "0" > /proc/sys/net/ipv4/tcp_ecn' if you want, but it's the remote networks' fault, not your. So your decision depends on how much you want to communicate with them :-) as not only you have this problem with them (or rather _they_ have the problem in fact!). -- Tomasz Papszun SysAdm @ TP S.A. Lodz, Poland | And it's only [EMAIL PROTECTED] http://www.lodz.tpsa.pl/ | ones and zeros. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]