<<When an email is release and delivered out of quarantine, doesn't the receiving SMTP then send the 250 OK code?>>

When a remote server sends an email to the receiving SMTP server (SpamFilter in this case), the transmission will either succeed (the receiver sends a 250 OK code) or fail (the receiver sends an error code). If it fails, the remote server is disconnected, the SMTP session is terminated, and unfortunately there is no way for the receiver server to contact the sender's server back with an "oops, we made a mistake, here's the email".

Please note that an email can stay in the quarantine for days, and there is no way that a remote SMTP server can stay connected to SpamFilter for days waiting for either a final positive or negative response.

One could then say "Well, then if you accept email and quarantine it, the email has actually been received successfully, so you must send a 250 OK code to the sender to let them know". In theory it would be fairly simple to add such an option. It is very dangerous however. Let me explain why. Say that SpamFilter was to accept all emails and quarantine them without reporting any errors. There are many, many automated servers out there that do nothing all day long but to scan for smtp ports, and then test them to check if they can relay email to third parties. Usually they do so by using your server as a relay trying to send an email out. If they succeed, two things can happen. (1) they are spammers, in which case your server will appear on list of open relays spammers will try to use. You'll then be flooded by spam email relay attempts. (2) they are anti-spam organizations, in which case your site will be listed as an open relay and will appear on black-lists!

Please note that it is good that SpamFilter works as it does, as if senders were not notified of non-deliveries, they would never know that their email was rejected.... Only a fraction of the users actually checks their quarantine routinely and force delivery of valid emails. All the others would thus simply "vanish" without senders knowing they were not delivered and recipients not knowing they were sent. These notifications help in avoiding these situations.

Again one may argue "ok then, why don't you then accept all emails, and then only send a NDR when the quarantined email has reached the expiration period and has been deleted from the database?"

Suppose things worked like that, rejection notices sent only after an item has been deleted from the quarantine.
Joe sends an email to you. It gets blocked and quarantine. Joe is not notified yet that his email was blocked. Your quarantine is configured to hold mail for 2 weeks.  During these two weeks either you do not check your quarantine (which is usually the case for most users), or you miss seeing his email amid the dozens of other emails in there. Joe is wondering why you do not reply to him... After two weeks the email is deleted from the quarantine. Joe is now notified, two weeks later, that his email was rejected. But it was too late since not hearing from you he assumed you were not interested in his email.

Email occurs more or less in real time. Users need to know as soon as possible of any problems that occur with their emails. When an email is quarantined, it must be considered, effectively, as the email was not delivered. The fact that it is instead temporarily stored in a quarantine are must be thought of as a convenience for the receiving user, allowing him/her to check if any emails were blocked by mistake, and if so, recover them.

As for Joe having to resend an email, that's actually much better than Joe not knowing his email was blocked! If he receives an error immediately, he will then email you or your admin or his admin asking what the problem is. This will at least tell him there was a delivery problem *immediately*, and won't have to wait two weeks to find out about it. You may check your quarantine often, but others won't. And even if you check it daily, what if the blocked email was time-sensitive? You and him would only find out later when you check your quarantine.

Hope all this helps in understanding why we designed SpamFilter like this.

Roberto F.
LogSat Software

Roberto, If I understand what you said correctly, then the NDR's are handled between the receiving SMTP server and the remote (sender) SMTP server.  But by design the Spamfilter has to sit in front of the receiving SMTP.  So apparently when an email is sent and it gets caught in Spamfilter's quarantine, that causes the 250 OK code to not be generated and so the remote (sender) SMTP server will send an NDR to the sender.  That means that senders are getting NDR's for email that has not truly failed - the failure does not occur until it is deleted out of quarantine.  I don't know about your other users, but we use quarantine extensively and check it several times a day.  Every email we deliver out of quarantine still has an NDR sent to the sender, even though the email was actually delivered.  We get numerous multiple resends, emails and phone calls because of this.  I've had some senders (morons) resend messages dozens of times because they keep getting an NDR saying their email didn't go through.  Short of not quarantining, what is the answer to this?  When an email is release and delivered out of quarantine, doesn't the receiving SMTP then send the 250 OK code?

AJ,

Can you please zip us the following files to support@logsat.com:

• SpamFilter.ini
• ALL you white/blacklist text files and keyword file
• the to and from email addresses for a case in which a blcoked attachment was instead delivered.
• the SpamFilter activity log for that above day (if possible and you could trim out the relevant section showing only the section that contains those log entries it will save some bandwidth)

so we can replicate you problem.

Roberto F.
LogSat Software

Thomas,

The attachment filter is an extensin of the existing keyword filter. This means that the Custom Response will be the same as the "Response if keywords found in content" response:

557 This email is rejected. It contains keywords rejected by the antispam content filter.

Please make sure that your custom response begins with a 3 digit code, the 1st two being 55x in that case.

If the error reponse is correct, the sender SMTP server MUST send an NDR back to the sender. If not, it's possible the remote server is not behaving properly.

If you can send us at support@logsat.com your email domain and one of the attachment extensions that you're using, we can try to verify remotely if your setup is working as it should.

Roberto F.
LogSat Software

Hi roberto,

Thanks for the explanation of NDR handling by SpamFilter.

I perhaps didn't make myself clear: I was referring to the Custom Responses that are sent out by SpamFilter when an Email is blocked.  These responses then intiate an NDR from the sender's mail server.

However, through my testing with blocking attachments, I've never received an NDR when my Email was blocked.  Should there be a Custom Response for blocked attachments?

Thanks

Andy,

We just discovered a bug, thanks for the report. The attachment filter is not working if there is not at least one entry in the keyword filter as well. We'll have this fixed shortly and will release a patch. In the meantime, if you can please create at least one keyword filter, with anything in there, even random text, that will enable the attachment filter as well.

Roberto F.
LogSat Software

AJ,

We just discovered a bug. The attachment filter is not working if there is not at least one entry in the keyword filter as well. We'll have this fixed shortly and will release a patch. In the meantime, if you can please create at least one keyword filter, with anything in there, even random text, that will enable the attachment filter as well.

Roberto F.
LogSat Software

Thomas,

SpamFilter ISP hardly ever sends out Non Delivery Notification, thanks to the way it's designed. When an incoming SMTP connection is established and the remote server sends an email, the receiving SMTP server must send an "250 OK" code back to the sender. Please note that this "SMTP chatter" is always occurring between the two SMTP servers, not at the clients. Only if the sender SMTP server receives an "250 OK" code at the end of the transmission the email will be delivered.

If the "250 OK" code is not received, it is the sender SMTP server who takes care of notifying the sender by sending them a NDR, not SpamFilter. This is a good thing, you do not want to waste your resources in emailing back spammers for NDR's and you most certainly don't want to bother with bounces sent to spammers, and so on.

SpamFilter ISP will always perform its anti-spam checks before sending the "250 OK" code, so if there's any kind of filter that triggers a match, SpamFilter ISP sends an error code to the sender's SMTP server rather than the "250 OK", and then the remote server will notify their sender. No NDR's are sent by SpamFilter.

So when are NDR's sent by SpamFilter? Assume that an incoming email arrives to joe@yourdomain.com. It's legitimate, but you cancelled joe's account yesterday, or joe's mailbox is full. SpamFilter will accept the email since it's good, and will send the "250 OK" code to the remote server. SpamFilter then forwards the email to your destination SMTP server. But the latter responds with an error code since the account no longer exists for example, or the mailbox is full. In this case, SpamFilter must email the sender with a NDR to notify them of the problem.

This applies to all filter rules, including attachment blocking. If anyone notices a different behavior, however, please report it since it would be a bug...

Roberto F.
LogSat Software

My understanding is that when a banned attachment is detected, the connection is simply dropped and not time or resources are wasted trying to send a no-delivery to the most likely forged return address.

Dan