Mail Gateway/Direct Processing
From Halon Security
Contents |
Direct Processing
A new feature as of H/OS 2.0.8 is the support of Direct Processing (Before-Queue) scanning. This gives you the possibility to reject SPAM-message without accepting the message (and take over the responsibility for that message). Today's only options instead of delivery are to delete the message silently or divert it to a quarantine (well it's possible to generate a DSN, but not for the right reason). Both approaches have pros and cons, but what speaks for
Direct Processing Off (After-Queue scanning)
+ Performance under heavy load (burst protection) - Bad error reporting for false-posivies
Direct Processing On (Before-Queue scanning)
+ Good error reporting for false-posivies - Performance under heavy load
Our Implementation
This new mode introduces a new Mail Flow function called Reject(). This function will notify the sender, using different techniques depending on Processing mode. Reject() also takes a string argument, which can be the reason for rejecting, eg. "Spam" or "Virus Detected".
| Direct Processing | On | Off |
|---|---|---|
| Delete() | Delete the mail silently | Delete the mail silently |
| Reject() | Reject the message | Warning! Generates a DSN |
A code example using anti-virus scanning.
if (count($viruslist=ScanKAV()))
{
if ($directprocessing){
Reject("Virus Detected! "+implode(",", $viruslist));
} else {
Delete();
}
}
How to activate this feature
It should be fairly simple to convert a running configuration to use Direct Processing. Direct Processing mode can be activated for a Mail Listener under (Mail Gateway -> Incoming), but before doing so, finish reading this document.
The simple flow module "Delete", has been renamed to "Delete or Reject", and what is does is that if your using Direct Processing it will call "Reject()" else it will fall back to its old behaviour and call "Delete()".
If you don't use the simple flow blocks, you are very likely to use Delete(), this function call can be replaced with the function Reject(), but if you want to be able to disable the Direct Processing mode in the future (or share the Mail Flow among multiple Incoming Listeners with different Processing modes) without sending out DSN-messages for each SPAM-message (which you probably don't want to), you should instead replace it with
if ($directprocessing) Reject(); else Delete();
This gives you the same behaviour as the "Delete or Reject" module.
Also make sure your Incoming Queue is empty, since once Direct Processing is activated, no mail will not be processed from that queue.
Q&A
Is this feature something for me?
Yes, but the limitation of Direct Processing is a combination of the concurrent connection and the time it takes to scan a message. Most systems have 30 or more concurrent receiving slots (dynamically depending on hardware setup) and since it takes more time to scan a message than just accept the message and put it in the Incoming Queue for later scanning, it may be a limitation.
But most environments do not peek at even close to 30 concurrent connections, so you should at least give it a try and if it turns out to be a limitation the behavior will be bad responsiveness.
But will it reduce SPAM messages?
Well, sort-of, but you should be aware of...
If you activate Direct Processing with rejection and lowering the SPAM threshold in confidence, all mail you do not accept (Deliver) will be rejected. A legitimate sender will be notified within minutes (by his own mail-server), which will make him aware that his message was rejected so he may correct the problem and try again, but for auto-generated messages that get caught (eg. password reminders, order confirmations and newsletters) for those, delivery failures may not be humanly reviewed and therefore lost.
That said, you should leave the threshold as is today and use this feature to try to eliminate that false-positive messages get lost (as they do with Delete).
