corymckee,

Are you sure those connections are not some kind of "probe" by the "trusteddomain.com" mail server that is checking to see if the user "email@ourdomain.com" is valid?
The entry:
Bypassed all rules for: email@ourdomain.com from email@trusteddomain.com ( Whitelisted Email From Domain)

should indicate that SpamFilter has accepted both the MAIL FROM and the RCPT TO addresses. I say "should" as without seing the previous log entries we can't be 100%. The log entries related to this SMTP transaction will all have the same "thread ID", which is (7412).

From the log we see that the remote server simply disconnected after sending the RCPT TO command, which is indicative of a test of some sort from them.

This is very strange indeed. Probably the best way to find out what is happening is to perform a trace of the SMTP session with the remote host, if possible, under the two conditions (whitelisted / not whitelisted).

SpamFilter can do that by going to the "Settings - Debug View" tab. In there, if you enter the IP of the remote host and check the "Enable Debug Monitor" box, SpamFilter will show a trace of the SMTP traffic on the next connections.

If you could either post or email us those results we can try to figure ourt what is happening.

It turns out that this is still a problem. It has nothing to do with the vendor being whitelisted. It continues to happen regardless.

I ran a debug and I will email you the results. I am trying to collect more as well.

Was the mailguard located on the senders side or the recipients side? 

I have a very similar situation where mail from one domain disconnects before finishing the message.  The senders get a delivery failure report stating that the server lost connection while sending end of data.  In troubleshooting the issue, I have found that the senders have recently added a Tumbleweed MailGate to their environment. 

I'm running the current version of spamfilter and have tested it with the last 2.x version, as well as moving the spamfilter to an alternate machine.  Debug shows this:

>>EHLO plamg01.senderdomain.com
<<250-8BITMIME
<<250-SIZE 12800000
<<250 HELP
>>MAIL FROM:<Bill_Miller@senderdomain.Com> SIZE=4424
<<250  Address Okay
>>RCPT TO:<cdaunis@ourdomain.com>
<<250 cdaunis@ourdomain.com Address Okay
>>DATA
<<354 Start mail input; end with <CRLF>.<CRLF>
>>EHLO plamg01.senderdomain.com
<<250-8BITMIME
<<250-SIZE 12800000
<<250 HELP
>>MAIL FROM:<Bill_Miller@senderdomain.Com> SIZE=4424
<<250  Address Okay
>>RCPT TO:<cdaunis@ourdomain.com>
<<250 cdaunis@ourdomain.com Address Okay
>>DATA
<<354 Start mail input; end with <CRLF>.<CRLF>

Any help would be appreciated.
Richard


Edited by BigTex71

Thank you Roberto, but it doesn't appear to be a timeout issue.  I'm seeing this in the activity log and it shows disconnect about a second after the last command.

06/26/07 12:24:16:960 -- (1816) Connection from: 12.13.14.15  -  Originating country : United States
06/26/07 12:24:17:195 -- (1816) Mail from: Lonnie_Leger@senderdomain.Com
06/26/07 12:24:17:867 -- (1816) - MAPS search done...
06/26/07 12:24:17:867 -- (1816) RCPT TO: cdaunis@ourdomain.com accepted
06/26/07 12:24:18:914 -- (1816) Disconnect

I just tried editing the .ini file to disable EHLO extensions, but ended up with the same disconnect result. 

I'm not 100% sure, but I think I was able to receive the whole message properly once when I accidentally had their mail going to quarantine.  I'll manually blacklist them again and see if the messages actually do get completed and sent to quarantine.

No, I have a Sonicwall in front of my spamfilter box.  Its port forwarding SMTP traffic through to the NAT IP address of spamfilter.  No other sending domains have this issue and mail works flawlessly otherwise. I'll take another look through the sonicwall, but I know there isn't any mail filtering enabled directly on it.

Thanks for the reply.