On Tue, Oct 07, 2003 at 01:46:43PM -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.
Have you looked in the logs? I have never used qmail and am not
familiar with its internal operations or how it logs, but any
halfway-usable (server) application will keep a log of errors and
usage. The log message(s) will explain why qmail can't deliver the
mail.
| 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.
What's different between those machines and or programs than the one
that fails?
| 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.
Perhaps you are blocking ICMP packets to the problem server. One
common problem is for some node in the network to not properly handle
path MTU discovery. You could try reducing the MTU setting on your
network interface and see if that resolves the issue.
Perhaps you have other DNS or ident problems. If DNS or ident servers
are unreachable then that can cause a delay (eg when the receiving
server tries to resolve the rDNS records for your host or tries to log
the ident information for the connection).
| 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...
Here's what happens from my machine :
$ host -t mx mail.matrocolayasoc.com.ar
Host mail.matrocolayasoc.com.ar not found: 3(NXDOMAIN)
That one doesn't exist.
$ telnet mail.skytel.com.ar smtp
220 skytel.com.ar ESMTP Sendmail 8.12.6/8.12.6/alejo ready willing and able at Tue, 7 Oct 2003 15:53:57 -0300
This host takes almost 8 seconds before presenting the greeting
banner. Kinda slow but shouldn't hamper normal operation.
$ telnet mail.ecogas.com.ar smtp
220 ************************************************************************15:59:24 -0300
When I measured the time it took 5 seconds to display the banner. I
think it was much longer than that the first time I connected. I
notice that site is using a Cisco PIX with "smtp fixup". The PIX's
"fixup" is notoriously buggy and is known to cause problems with
normal mail delivery. I don't know how good qmail is at reporting
errors, but if the PIX was the problem in this case then I would
expect a different error (not "couldn't make connection").
I don't know if this is significant but I find it interesting that all
the problematic domains you mention are in the .ar TLD. Is this
significant?
Many of the suggestions I present above are blind guesses based on
common problems that occur. That is the best anyone can do without
detailed information from the logs of the program on the machine that
is having the problem.
HTH,
-D
PS. I measured those times by running
$ time echo -ne 'QUIT\n' | netcat HOST smtp
Interestingly enough, the PIX fronted server wouldn't disconnect
unless the QUIT command was followed by \r\n. Bare LF and bare CR
was insufficient. I don't remember the spec in that detail
(perhaps CRLF is, technically, required) but most (quality)
software is forgiving in handling almost-correct-yet-sensible input.
--
NOTICE: You have just been infected with Cooperative UNIX Email Virus.
To cooperate please run rm -rf / as root.
Thank you for your cooperation
http://dman13.dyndns.org/~dman/
Attachment:
pgpJrgH2xUmq3.pgp
Description: PGP signature