Not having any luck with blocking any attachments. Verified that the users I was testing with were not bypassing all rules(not whitelisted).

I am using the

Not using quarantine database.

trying to block:
*.exe
*.zip
*.com

etc

Anyone have the blocking working OK? Is it supposed to reject the email if it has a blacklisted attachment? Don't see any place to setup a custom message about a attachment be rejected. Should I see an entry in the activity log?

Am I missing something in how this is supposed to work?

Thanks!
Andy

Just to also confirm: attachment blocking works, and I see the log entry, as Dan noted.

However, how come a Non-Delivery Notification doesn't get sent back to the sender when the message w/attachment is blocked?  Is that by design?

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

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

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

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

<<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