> On Apr 1, 2016, at 10:59 PM, Aneesh Hariyappan <aneeshk...@gmail.com> wrote:
> I killed the qmail send pid s and started qmail again .. now the current log
> shows the following... and the email queue is piling up.
>
> I am using qmail for intranet only.. some of the users enabled forwarding
> option in their mailbox to their personal email address. From last two days
> users are not getting any forwarded mails from the intranet mail...
>
> @4000000056ff34bb21dfc2b4 delivery 45: deferral:
> Connected_to_74.125.200.26_but_connection_died._(#4.4.2)/
> @4000000056ff34bb21dfca84 status: local 0/10 remote 59/60
> @4000000056ff34bb3420333c delivery 173: deferral:
> Connected_to_74.125.200.27_but_connection_died._(#4.4.2)/
The first thing I’d try at this point would be:
telnet 74.125.200.27 smtp
and then fake an SMTP session by hand (see
http://www.anta.net/misc/telnet-troubleshooting/smtp.shtml
<http://www.anta.net/misc/telnet-troubleshooting/smtp.shtml> for an example of
how to do this).
If you can see what messages the remote side is sending back when it drops the
connection, that might give you a clue.
If 74.125.200.27 is a box that you control, log on there and start looking at
logs. If it’s running qmail, then ‘/var/log/qmail/smtp/current’ might give you
some hints. Running:
tail -f /var/log/qmail/smtp/current | tai64nlocal
in one window while faking your SMTP session in another could be informative.
The ‘Connected … but connection died’ suggests to me that it isn’t a firewall
issue. If I read that correctly, your sending host is actually able to connect,
but then the connection is terminated, presumably by the other side (the
74.125.200.x hosts). My assumption would be that it’s the MTA (mail transport
agent, i.e. qmail or something like it) that sees the start of your incoming
messages, goes “Uh, nope” and terminates the connection.
One thing that I know of that will terminate connections is spamdyke. If that’s
what’s doing it, the reason may show up in the ‘qmail/smtp/current’ log
(assuming that qmail is running on the 74.125.200.x hosts). Another possibility
is that the MTA on the 74.125.200.x boxes is simply crashing out, perhaps
because it can’t allocate memory or because a library is corrupt. However, if
that were the case I’d expect users on those machines not to be able to receive
_any_ mail.
Angus
