Hi please help me out!

When someone sends a e-mail to me and the message exceeds the limit no NDR is generated. So the senders server keeps tryieng to send the message to my spamfilter server. Is this new? I think i remember that if a message is too big SF sends a NDR?

This is my settings in sf ini.

MaxIncomingMsgSize=50000

DoNotSendNDROnQuarantine=1

I understand it this way. SF should not send NDR if the mail is put in the QDB. (So no ndr on spam). But mail exceeding max message size isn't put in the QDB, so SF should send a NDR to the sending server, so that it would not try to resend it?

My prolem is that SF doesen't send a NDR if the message exceeds max limit. So sending servers are trying to resend the message again and again (as they are supposed to) because they don't get a NDR.

Please ask me if there's something im uncleaer about, or if You don't understand my problem.

BTW: Running SF 2.6.3.483 registered on a Windows 2003 server.

Best regards...

Torsten Christiansen aka. SirRar

Edited by sirrar

yes! i notice also in my mrtg,
using SpamFilter ISP v2.5.2.458 (registered)

Hi again

 

Thanks for the quick response.

Just impelmented 485.  Within a few hours I will se if it has helped. And report back.

Thanks in advance.

 

Torsten,

We double-checked internally and on our own ISP, and so far the fix appears to work fine. We'll be testing your install remotely shortly.


Edited by LogSat

As You can se on my MRTG several prople has since tuesday been tryieng to send me some large e-mails (all exceeding 50 MB).

And they keep tryeing (not the user, but the sending server)

The sending server is one of Denmarks most respected ISP's. Teledanmark (TDC). I'm quite confident that they'r servers are OK.

Also don't see anything in my mail logs that indicates that SF is sending something to the seing server.

I could reply on your test message and attach my mail log

then You could se for yourself?

 

Best regards...

Torsten

Torsten,

We duplicated the problem remotely on your install. You're correct, it's still not fixed. We'll need to troubleshoot this a bit further, as right now I really can't tell what the problem is .

We'll post a fix as soon as we find it.

Torsten,

The issue was the following. Prior to build 485, SpamFilter was continuosly monitoring the size of the incoming emails. As soon as the limit was reached, SpamFilter was sending the remote server an error message notifying of the size restriction, then was immediately disconnecting them as to avoid the unnecessary reception of the remainder of the email. If the max msg size was 10MB for example, and the email size was 200MB, this resulted in great savings of resources and bandwidth.

However you poointed out a problem we were not aware of. Under certain cirumstances, the remote server would not "listen" for SpamFilter's error message, and would continue sending the email body uninterrupted. When SpamFilter forced a disconnect, without receiving the error message, the sender assumed there was a connection problem and retried to send it.

With build 485 we thus increased greatly the time delay between when SpamFilter sent the error message and the time at which SpamFilter disconnected the sender. However again you (and we duplicated it) found circumstances in which the sender was being very *hardhead* and would not listen for a return code until it had completely finished sending the *whole* email.

Unfortunately the only solution in this case has been for SpamFilter to completely receive the *whole* email, as only then would the stubborn sender listen and look for an error response. We tried to make the receiving piece as less resource-intensive as possible, eliminating all (now unnecessary as the email will be discarded) decoding and RFC processing, but again have been forced to receive the full email before disconnecting the sender. This will result in a waste of bandwidth and (limited) resources, but so far appears to be the only fully reliable way to prevent the sender to keep retrying to send the message.

The build with this fix is 487, now avail in the registered user area.