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]
