Hi Agnus, Thanks for your reply..
I tried the telnet ... pl see the results.. 220 mx.google.com ESMTP n79si38654589pfi.149 - gsmtp HELO client.google.com 250 mx.google.com at your service MAIL from:<[email protected]> 555 5.5.2 Syntax error. n79si38654589pfi.149 - gsmtp MAIL from: <[email protected] 555 5.5.2 Syntax error. n79si38654589pfi.149 - gsmtp MAIL from : [email protected] 502 5.5.1 Unrecognized command. n79si38654589pfi.149 - gsmtp RCPT to: <[email protected]> 503 5.5.1 MAIL first. n79si38654589pfi.149 - gsmtp MAIL from : <[email protected]> 555 5.5.2 Syntax error. n79si38654589pfi.149 - gsmtp MAIL from: <[email protected]> 250 2.1.0 OK n79si38654589pfi.149 - gsmtp RCPT to: <[email protected]> 250 2.1.5 OK n79si38654589pfi.149 - gsmtp DATA 354 Go ahead n79si38654589pfi.149 - gsmtp From: [email protected] To: [email protected] Subject: Test message . 250 2.0.0 OK 1459742410 n79si38654589pfi.149 - gsmtp QUIT Connection to host lost. C:\Users\02602> On Sat, Apr 2, 2016 at 5:42 PM, Angus McIntyre <[email protected]> wrote: > > On Apr 1, 2016, at 10:59 PM, Aneesh Hariyappan <[email protected]> > 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 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 > > > -- Regards , Aneesh K H
