Forward with attachments
Printed From: LogSat Software
Category: Spam Filter ISP
Forum Name: Spam Filter ISP Support
Forum Description: General support for Spam Filter ISP
URL: https://www.logsat.com/spamfilter/forums/forum_posts.asp?TID=6776
Printed Date: 05 February 2025 at 5:57pm
Topic: Forward with attachments
Posted By: Wayne
Subject: Forward with attachments
Date Posted: 17 November 2009 at 4:03am
|
Hi We have a little problem with emails and SF won't them forward to our internal mailserver. First I think we had a timeout problem and I saw this in the logs: 11.16.09 15:31:40:658 -- (184) Connection from: 212.40.5.52 - Originating country : Switzerland 11.16.09 15:31:40:705 -- (184) Received MAIL FROM: <sender@domain1.ch> 11.16.09 15:31:40:721 -- (184) Received RCPT TO: me@mydomain.ch 11.16.09 15:31:40:721 -- (184) Bypassed all rules for: me@mydomain.ch from sender@domain1.ch ( Whitelisted EMail Address From) 11.16.09 15:31:51:752 -- (184) Disconnect 11.16.09 15:31:57:189 -- (820) Connection from: 212.40.5.82 - Originating country : Switzerland 11.16.09 15:31:57:252 -- (820) Received MAIL FROM: <sender@domain1.ch> 11.16.09 15:31:57:268 -- (820) Received RCPT TO: me@mydomain.ch 11.16.09 15:31:57:268 -- (820) Bypassed all rules for: me@mydomain.ch from sender@domain1.ch ( Whitelisted EMail Address From) 11.16.09 15:32:06:736 -- (1020) Running TTerminateIdleThreads - SFTC=1 - SFFC=1 11.16.09 15:32:06:736 -- (1020) Running TTerminateIdleThreads SSL - SFTC=0 - SFFC=1 11.16.09 15:32:06:736 -- (1712) Blacklist cache - starting cleanup 11.16.09 15:32:08:314 -- (820) Disconnect I know the antivirus scan our fortigate firewall caused the problem because if I disable the antivir scan on this policy everything runs like a charm. So I increased the ReadTimeout to 300 and ReadTimeoutOutgoing to 360 in the spamfilter.ini but the problem still exists. The attachement is only a 7MB zip file so I think this time should be more than enough to scan. 11.17.09 09:00:59:205 -- (1424) Connection from: 213.165.64.20 - Originating country : Germany 11.17.09 09:00:59:252 -- (1424) Received MAIL FROM: <sender@domain1.ch> 11.17.09 09:00:59:283 -- (1424) Received RCPT TO: me@mydomain.ch 11.17.09 09:00:59:283 -- (1424) Bypassed all rules for: me@mydomain.ch from sender@domain1.ch ( Whitelisted EMail Address From) 11.17.09 09:01:11:299 -- (1424) Disconnect 11.17.09 09:01:28:721 -- (384) Running TTerminateIdleThreads - SFTC=0 - SFFC=0 11.17.09 09:01:28:721 -- (384) Running TTerminateIdleThreads SSL - SFTC=0 - SFFC=0 Any suggestions? I opened also a Ticket on the Firewall vendor Fortinet. Regards Wayne ------------- SF4.5.0.1-beta |
Replies:
Posted By: Wayne
Date Posted: 17 November 2009 at 12:24pm
|
I believe the change of the timeout-settings will not saved and don't work. Because I have changed the two settings ReadTimeout = 300 ReadTimeoutOutgoing = 360 But SF disconnects still after 60 seconds. 11.17.09 18:16:01:158 -- (384) Connection from: 213.165.64.20 - Originating country : Germany 11.17.09 18:16:01:205 -- (384) Received MAIL FROM: <sender@gmx.ch> 11.17.09 18:16:01:252 -- (384) Received RCPT TO: me@mydomain.ch 11.17.09 18:16:01:268 -- (384) Bypassed all rules for: me@mydomain.ch from sender@gmx.ch ( Whitelisted EMail Address From) 11.17.09 18:17:02:393 -- (384) Disconnect ------------- SF4.5.0.1-beta |
Posted By: LogSat
Date Posted: 17 November 2009 at 10:57pm
|
Wayne,
The issue is with the incoming emails, so the ReadTimeoutOutgoing setting won't apply here as it is relative to outgoing emails to your destination SMTP server. Going back to this issue however, the disconnect appears to be happening about after 10 seconds from the initial connection:
SpamFilter has built-in timeouts that may apply in this case. In the SpamFilter.ini file there are the following settings: ;Force disconnect of sessions after they have remained connected for this long IdleDisconnectMinutesTimeout=15 If the above setting is lower than the 15 default, this could cause SpamFilter to disconnect the remote server before the email is complete. In your case the disconnects are occurring seconds after the connection, which is even lower than the minimum of 1 minute this setting allows, but I'd like to double-check your settings on this one anyways. ;Force disconnect of sessions if a command has not been received within the last nn seconds ReadTimeout=60 You already increased this to 300, so this should not be a factor anymore. All the above settings can be changed while SpamFilter is running – they will be re-imported utomatically within a minute. If both of these settings are higher than the 10 seconds you are experiencing, I would then take a second look at the firewall to see if that is the one initiating the disconnect. Are you able to install and run WireShark (Etherreal) on the server to monitor the connection with the subnet 212.40.5.nnn, to see if we can determine who's causing the disconnect? ------------- Roberto Franceschetti http://www.logsat.com" rel="nofollow - LogSat Software http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP |
Posted By: Wayne
Date Posted: 18 November 2009 at 4:19am
|
Hi Roberto I've sent you the capture packets. I can't recognize where the problem is. For me it looks like SF gets all packets correctly and the FIN ACK close the transmission also correctly. Thx for you help! Regards Wayne ------------- SF4.5.0.1-beta |
Posted By: LogSat
Date Posted: 19 November 2009 at 6:34pm
|
Please see the screenshot attached where I tried to explain the last packets. Unfortunately the capture confirms that it is the remote server that is unexpectedly terminating the connection during the transfer. After one of the DATA packets containing the email contents (and it's not a packet containing the end of the email, as the end-of-email sequence <CR><LF>.<CR><LF> is not there), the remote server 213.165.64.20 suddenly, unexpectedly, sends a FIN packet. FIN packets are requests to close the transmission. I can't be sure if there's a firewall intercepting the packets before they get to SpamFilter or not, but if there is one, it's possible that the FIN packet is actually being generated by the firewall. Unfortunately I'm not able to determine that.  ------------- Roberto Franceschetti http://www.logsat.com" rel="nofollow - LogSat Software http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP |