> -----Original Message----- > From: Danny Angus [mailto:[EMAIL PROTECTED] > Sent: 21 October 2003 10:55 > To: James Users List > Subject: Re: Virus Protection Via Fast Fail > > > > > > > > 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". Although I have promoted the use of fast-fail in James, in this case I think it is not the correct thing to do. Fast-fail is great for getting rid of spammers as quickly as possible as you can detect then through MAIL FROM: and RCPT TO: abuse. However in the case of SWEN-A you need to analyse the message first. Therefore you've already downloaded it. The only other option is to attempt to process the message on the fly and use a regex to detect subject line patterns.
I do see why you want this, though. Each virus is about 150k. Not very pleasant. A friend of mine was getting 200-300 a day ! > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
