I have an issue with some emails not getting delivered. i can see it is coming in:-

 

11/24/10 04:09:43:283 -- (7180) Connection from: 203.10.1.242  -  Originating country : Australia
11/24/10 04:09:43:908 -- (7180) Received MAIL FROM: < mailto:n@n.com.au - n@n.com.au >
11/24/10 04:09:44:127 -- (7180) Received RCPT TO: mailto:s@s.com.au - s@s.com.au
11/24/10 04:09:44:127 -- (7180) Bypassed all rules for: mailto:s@s.com.au - s@s.com.au from mailto:n@n.com.au - n@n.com.au ( Whitelisted EMail Address From)
11/24/10 04:09:45:940 -- (37536) Disconnect
11/24/10 04:09:51:643 -- (7180) Disconnect

 

(I have modified the the addresses ;)

 

I will send you the full log in an email, if you could have a look and see if i am missing something.

 

Cheers

 

From logs we see a repeat of the same unusual sequence of events - a few seconds after SpamFilter logs the fact that the email will be whitelisted, the session is disconnected. In addition to the IP 203.10.1.242, we see this happening from various IPs in the 203.10.1.nnn range, along with 202.72.128.10.

In order to troubleshoot this, I'm afraid the best way to proceed is via a packet capture, using Wireshark for example, configuring it to only capture SMTP traffic from 203.10.1.0/24 and 202.72.128.10.

The capture filter in Wireshark would thus be:

net 203.10.1.0/24 or host 202.72.128.10

Is there any chance you could run a capture and provide us with the captured file (in native wireshark / libpcap format)?

 

Will run some captures today and email to you.

 

Cheers

The server it is sitting on is a hosted Virtual server that will not allow the winpcap to run, thus cant bind to the virtual nic.

i have just changed my mx priority to start to get it to push in house. Where i can monitor it from, so may take a bit longer to get logs for you.

 

Cheers

Please take a look at line 398 in that file. Per RFC 2821 (http://www.ietf.org/rfc/rfc2821.txt) each line of text in an email should be no more than 1,000 characters. If you however look at that line, you will see that it contains 22,860 characters (or maybe more... my own text editor is having issues when viewing the file...). This is obviously waaaay more than RFC allows, and SpamFilter is dropping the connection because of this. The sender will need to fix their code and ensure they add CRLF sequences to breakup the html code in that email so as to be RFC compliant.

What is odd is that SpamFilter is able to handle line lengths of up to 16,384 characters, and in case the sender violates RFC, it should log an error, which however is not occurring in this case. We'll take a look at this last aspect (not logging), even though we are going to have some difficulties in replicating this as all our test tools (and our version of telnet) are having trouble handling this line length :-)

 

It is my code that is generating the offending emails (Doh) i will fix it and run a test, i will let you know how it goes.

 

Cheers.