Your right, Thomas, I forgot to add the session log.  The reason was that I couldn't find a file for any of the failed messages, only successful ones.  As you can see from my follow-up post, I may have found the problem.

GordonM

TCP/IP errors are happening on jobs which are generated when forwarding mail as a Global Filter action. When I send mail from a client machine account for which MercuryC is the SMTP client, there are no errors.  I have tried two different smart hosts for this and the same error occurs.  I have increased the TCP/IP time-out and this doesn't help.

If I enable Session Logging, the problem seems to be reduced, but doesn't disappear.  This problem happened to me some years ago and the solution then was to turn on Session Logging.  I have never understood why this should be the case.  However, this time, the same trick doesn't seem to be working.

My SMTPRelay log file had become quite large (several MBs) with 100s of entries, so I wondered whether this was an issue.  I have delated the old entries so that it is now down to a few KBs.  However, this hasn't helped either.

Can anyone offer any ideas?

Below is an expurgated version of a General Log entry, following which is a a Session Log record of one of the previously failing jobs.

Thank you

GordonM

 T 20120601 143412 fa4 Established ESMTP connection to smtp.my_isp.com

T 20120601 143412 fa4 Begin processing job MO000019 from someone@mail.com

T 20120601 143412 fa4 MAIL FROM:someone@mail.com SIZE=3479

T 20120601 143412 fa4 250 sender <someone@mail.com> ok

T 20120601 143412 fa4 RCPT TO:<my_mail@gmail.com>

T 20120601 143412 fa4 250 recipient <my_mail@gmail.com> ok

E 20120601 143442 fa4 TCP/IP error.

> Below is an expurgated version of a General Log entry, following

which is a a Session Log record
> of one of the previously failing jobs.

I see no session log at all.  

Having thought about this some more, I think that I have found the problem.  As note in the original post, messages sent from one of my client machines don't encounter the TCP/IP error, but those being forwarded by a global filtering rules script do.

In my global filtering rules, I catch any normal outgoing messages and tell them to immediately exit processing, using the From: header, which looks for "@my_domain.com".  However, in the case of forwarded messages, the From: is the header of the original message, which could be anything.  My script didn't allow for this.  I have now added a special header to forwarded messages, which is looked for when the message comes through the script on its way out.  If it is present, exit processing is executed.

It would be a lot easier if Mercury could have separate filtering for incoming and outgoing messages, but I suppose this might require separate mail queues.  I am often coming across this sort of problem.  I suspect that this would require a major design change.

GordonM