Hut,
>Good Morning Everyone,
Good afternoon matey ;-)
>Have been combing through back emails trying to find ways to stop viruses,
specificly Worm_Swen.A.
> Now Serge wrote an excellent rebuttle on why we don't want to use Fast
Fail. There are
>techniques to stop viruses using Fast Fail, but I don't know what these
are. Could any one give
>me some guidance on where to learn more about them?
There's been a lot of defence of our position opposed to widespread
application of fast fail, (bear with me I'll spiral in towards the point!)
basically unfettered use of fast fail would drive a coach and horses
through our efforts to make James stable and efficient by breaking the
pattern of asynchronous analysis & processing of recieved mail.
Once you are aware of this you can investigate (intelligently) the benefits
you may gain from analysing mail as it is recieved and before it is
spooled. In other words directly in the SMTP handler.
We reckon that fast fail shouldn't be supported with a component pattern
architecture (like the mailets) in order to make it harder for people to
circumvent James design.
If you really do want to do this you will have to extend the SMTP handler
in some way so that it identifies and processes the message elements as
they are recieved and terminates the SMTP session as soon as you have a
positive match with some unacceptable condition. To benefit from fast fail
you really have to make that decision based upon the headers as using the
body means you wait until you have the whole message and the transaction is
effectively over. Therfore you may as well process this asynchronously and
not loose that benefit, you won't be saving bandwith etc (the most
eloquently championed benefit of fast fail) by placing this action "at the
front".
You would stop a lot of recently style virus related traffic with subject
pattern matching, and possibly by matching other headers.
To really apply trustworthy virus detection you will have to scan the
message content. This means that the whole thing will have been recieved
before you process it.
If you have a lot of whole messages to scan you will run a very much higher
risk of melt down and therefore be more vulnerable to DoS.
And don't forget that mail rejected by your "door policy" will never be
available to you, you won't be able to do anymore than inform your user
that a mail was rejected. OTOH using the mailet structure means that you
can impose a strict policy and quarantine borderline cases allowing you to
inform your users that "If this mail is relevant to company business call
extension xxx to have it released"
d.
Scotland
***************************************************************************
The information in this e-mail is confidential and for use by the addressee(s) only.
If you are not the intended recipient (or responsible for delivery of the message to
the intended recipient) please notify us immediately on 0141 306 2050 and delete the
message from your computer. You may not copy or forward it or use or disclose its
contents to any other person. As Internet communications are capable of data
corruption Student Loans Company Limited does not accept any responsibility for
changes made to this message after it was sent. For this reason it may be
inappropriate to rely on advice or opinions contained in an e-mail without obtaining
written confirmation of it. Neither Student Loans Company Limited or the sender
accepts any liability or responsibility for viruses as it is your responsibility to
scan attachments (if any). Opinions and views expressed in this e-mail are those of
the sender and may not reflect the opinions and views of The Student Loans Company
Limited.
This footnote also confirms that this email message has been swept for the presence of
computer viruses.
**************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
