Communication problem between TrendMicro IMSS 7.0 and SendMail

We are using an Trendmicro IMSS 7.0 server to send & receive emails.
Ever since we have upgraded from version 6.0 we experience problems in sending out emails to "SendMail" mailservers. Apparently their is a new feature in these mailservers (Sendmail) that detects Ghost (Spamsending) computers according to the amount of mail that is send from a server and a specific communication speed. Trendmicro's IMSS 7.0 system is automatticaly seen as on of these Ghostmachines.
This means that if someone tries to send to a Sendmail server, this mailserver will reject the connection and after 8 hours, IMSS will generate an "Relay time-out" error message.
Does anyone have any idea in how to resolve this issue?
Who is Participating?
saphicoAuthor Commented:
I've received the following feedback from TrendMicro:

 Change the IdleWaitingSecond as follows:
- Go to &Program Files\Trend Micro\IMSS\ config folder.
- Open the tsmtpd.ini file with notepad.
- Search "IdleWaitingSecond=30" and change it to 60. Remove the "#" sign to enable it.
- Save the file and restart the IMSS SMTP/Scanner services.

I've already changed the IdleWaitingSecond into 90, but still no good communication.
What is de default setting for a SendMail?
Jan SpringerCommented:
Can you post your (this is used to create
saphicoAuthor Commented:
We don't have a Sendmail, but an Interscan Messeging Security (IMSS) of Trendmicro
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

Jan SpringerCommented:
There are several features in sendmail used to reduce spam.  None of them are new to my knowledge.

I'm curious as to this statement, "Trendmicro's IMSS 7.0 system is automatticaly seen as on of these Ghostmachines."

Why would TrendMicro be singled out?
IMSS 7.0 has very low timeouts during the HELO/MAIL FROM/RCPT phase. If the sendmail server doesn't respond within 30 seconds, IMSS terminates the connection. This can easily happen if sendmail is configured with blacklists or an anti-spam solution.

All timeouts in IMSS should be changed to at least 5 minutes to comply with the SMTP RFC.
saphicoAuthor Commented:
so they are timeout to 5 min
Sorry, are you saying that you changed the setting or that they already were set to 5 minutes ?

Make sure you also check all postfix timeouts.
saphicoAuthor Commented:
It already was on 5 minutes
saphicoAuthor Commented:
I contacted Trend Micro about this matter and they said that the solution is not on the IMSS side, but only on the side of SendMail. Apparrently when the SendMail adds the IMSS to the Whitelist, the problem is solved.
Does anyone have any experience with this?
Good luck convincing the entire world to add your domain to their whitelists :-)

Anyway, Trend Micro is wrong, the problem is on the IMSS side. This can be proved by this network trace (names are changed to protect the innocent):

  1   0.00000 -> SMTP C port=3345
  2   0.00009 -> SMTP R port=3345
  3   0.00252 -> SMTP C port=3345
  4   0.30081 -> AUTH C port=55281
  5   0.00042 -> AUTH R port=55281
  6   2.01409 -> SMTP R port=3345 220 sendmail ESMTP ready
  7   0.00245 -> SMTP C port=3345 EHLO
  8   0.00004 -> SMTP R port=3345
  9   0.00044 -> SMTP R port=3345
 10   0.00261 -> SMTP C port=3345 MAIL FROM:<Steven.Mu
 11   0.00003 -> SMTP R port=3345
 12   0.00978 -> SMTP R port=3345 250 2.1.0 <Steven.Mu
 13   0.00254 -> SMTP C port=3345 RCPT TO:<
 14   0.04168 -> SMTP R port=3345
 15  29.94610 -> SMTP C port=3345 QUIT\r\n
 16   0.04399 -> SMTP R port=3345
 17   5.01141 -> SMTP R port=3345 250 2.1.5 <stephan.r
 18   0.00011 -> SMTP R port=3345
 19   0.00462 -> SMTP C port=3345
 20   0.00005 -> SMTP C port=3345
 21   0.00031 -> SMTP R port=3345

Notice line 15: after 29.9 seconds, the IMSS server sends a quit before the recipients are accepted (or rejected). This is the IMSS timeout and is always 30 secs. Sendmail does NOT terminate the connection.

Line 17 is the sendmail server accepting (code 250)  the recipients (after about 35 secs), but this is too late for IMSS.

Ask Trend Micro where exactly the 30 secs timeout can be changed and your problem will be solved.

Can you check the postfix config on the IMSS server with these commands:

postconf smtp_rcpt_timeout
postconf  smtp_mail_timeout
postconf smtp_data_init_timeout
postconf smtp_data_xfer_timeout
postconf  smtp_data_done_timeout
postconf smtp_quit_timeout
postconf smtp_connect_timeout
postconf smtp_helo_timeout
Sendmail has many timeout settings ranging from 300 secs to 1 hour.

For IMSS for Linux, the appropriate timeout seems to be the "smtp_rcpt_timeout" parameter. I don't know how this translates into IMSS for Windows, that uses an internal MTA.

I found a different support document that seems to closely related:

Try setting the IdleWaitingSecond  timeout to at least 300 secs.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.