Link to home
Start Free TrialLog in
Avatar of saphico
saphico

asked on

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?
Avatar of Jan Bacher
Jan Bacher
Flag of United States of America image

Can you post your sendmail.mc (this is used to create sendmail.cf)?
Avatar of saphico
saphico

ASKER

We don't have a Sendmail, but an Interscan Messeging Security (IMSS) of Trendmicro
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.
Avatar of saphico

ASKER

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.
Avatar of saphico

ASKER

It already was on 5 minutes
Avatar of saphico

ASKER

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

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
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:

http://esupport.trendmicro.com/support/viewxml.do?ContentID=EN-1035149&id=EN-1035149

Try setting the IdleWaitingSecond  timeout to at least 300 secs.