ANNOUNCE: BarricadeMX is released
steve.freegard at fsl.com
Thu Jun 14 23:21:33 IST 2007
--[ UxBoD ]-- wrote:
> As MailScanner parses the message then it should be fairly easy to write
> the to_address to a file, or even hold it as a global hash shared between
> the perl processes. When the recipient replies, if they do, then the hash
> could be checked and allow the message through without any checks. Or if
> using a file the whitelisted entry can be looked up.
> A hash value could be created for the time the message was sent including
> the to_address, and then reversed on its way back in. If within a
> pre-determined time it passes through okay, or it has the normal checks
This sort of thing could easily be written as a Custom Function applied
to the 'Is Definitely Not Spam' option - but there are definitely a few
issues to consider when using a method like this as this was something
we considered when we were developing BarricadeMX.
It requires some sort of backing store to be effective as you need to
keep the data around for a while for it to be effective (BarricadeMX
allows for auto-whitelisting for 7 days by default and this is
adjustable), this data also needs to be shared amongst multiple gateways
if you have them (which would then require a proper database). Things
like BATV, SRS, VERP, Out-of-Office replies and autoreponders also cause
issues when you are attempting to auto-whitelist anyone that your users
have sent mail to and you leave yourself open to sender address spoofing
during the auto-whitelist period.
In BarricadeMX we came up with a very clever way to handle this and
backscatter prevention at the same time without the need for a database
or the tracking of senders/recipients and is one of the things we
decided to patent so our competitors couldn't steal the idea. Because
of this we can't offer this functionality natively for MailScanner (as
Julian already said on the -beta list).
Fort Systems Ltd.
More information about the MailScanner