Spam Filter ISP Support Forum

  New Posts New Posts RSS Feed - new bug? or bad header info?
  FAQ FAQ  Forum Search   Register Register  Login Login

new bug? or bad header info?

 Post Reply Post Reply
Author
anonymouse View Drop Down
Guest Group
Guest Group
Post Options Post Options   Thanks (0) Thanks(0)   Quote anonymouse Quote  Post ReplyReply Direct Link To This Post Topic: new bug? or bad header info?
    Posted: 09 June 2006 at 4:40pm

I have one SF (called SF1) in DMZ doing only IP/DNS tests. It forwards to another SF (called SF2) that runs other content tests as needed. SF1 has a white list and uses Auth-TO list. SF2 does not have a whitelist and uses identical Auth-To list.

99% of time this config works without issues.

 

Once in a while there is a huge lock up (100% CPU usage) caused by very specific bug in SF program? or sender’s email heather perhaps? or ?

 

In same specific Unknown scenario, SF1 receives email correctly and sends it to SF2, but SF2 reports that “no relaying is permitted and % found in from address” and rejects email, both unfound.

 

SF2 waits until read-timeout has reached to do this Error reporting. When SF2 does so, it shows "from" address field is empty and reports what was originally in “From” field (in SF1) as “To” address instead!!! This perhaps explains relay error as “To” user in this case is no longer “From” rcpt to user which obviously also is not in expected Auth_to list. And message should be rejected.

 

My question is how can I investigate this error?

In each case SF1 reports pending message in outbound queue.

When read time-out of SF2 is reached, SF1 reports “message was returned to sender - server error - Read Timeout” as well as “- forwarding to xxxx: - server error - Read Timeout

 

SF2 reports message stuck in inbound queue at “PROCESSING DATA…” state

When read timeout of SF2 is reached, SF2 reports email is rejected - no relay allowed or % found

As well as a - Notice - IdleDisconnectMinutesTimeout reached. Removing threadID.

Read timeout is rage such as 15minutes. And server is not heavily loaded. Plenty of ram and very fast 2.4GHZ CPU.

 

Obviously on big is when SF1 sends to SF2, from address in SF1 becomes “TO” address in SF2 and “from” address is reported as empty. SF2 fails to grab “From” address and eventually times out.

 

Another observation is that in all such scenario CPU usages pegs to 100%. I thing SF trying to parse something…

 

This scenario occurs once in a while... and normally occurs with inbound messages from

Mailing lists such as CNet ones. There are many others as well. Do these have special header content? Or is spamfilter problem?

 

In all cases, I noticed, SF2 has temp files generated in temp directory of SF2

And all seams to have tmp extension as expected. I opened a few, but all files are GIF98a attachments (could be co incidence). However, queue directory of SF2 remains empty.

 

Any assistance is appreciated to debug this.

Back to Top
LogSat View Drop Down
Admin Group
Admin Group
Avatar

Joined: 25 January 2005
Location: United States
Status: Offline
Points: 4105
Post Options Post Options   Thanks (0) Thanks(0)   Quote LogSat Quote  Post ReplyReply Direct Link To This Post Posted: 10 June 2006 at 12:19am
anonymouse,

We'd need to see the two SpamFilter's logfiles to see what is happening.

However probably everything can be avoided by correcting the configuration, as the "no relaying is permitted and % found in from address" from the SF2 server indicates a problem.
The error is caused because SF1 is sending SF2 an email with a recipient's domain that is not in the SF2 "Allowed Domains" list. So you need to do one of the following:

1. Add the domain for this email's recipient to the "Allowed Domains" on SF1.
2. If the domain in this emails is not yours, then SF1 should not be receiving it, so if such domain is in SF1's "Allowed Domains" it should be removed from there.
3. If SF1 is receiving such an email because the sender's IP is whitelisted, then SF1 will accept it and forward it to SF2. In this case, you must add SF1's IP address in the IP whitelist of SF2 so that SF2 can accept all emails from SF1.
Roberto Franceschetti

LogSat Software

Spam Filter ISP
Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down



This page was generated in 0.141 seconds.