On Thu, 2004-05-13 at 11:31, Jason Haar wrote: > On Wed, May 12, 2004 at 05:09:39PM -0500, Dallas L. Engelken wrote: > > Personally, I 550 for the simple fact that its less overhead than > > forking a call to qmail-queue to inject (a|several) custom crafted > > notification message. Does that make it better? Maybe.. Maybe not. > > It depends what you are comparing I guess! > > That is the only real positive argument I have ever seen for this. It is > ever-so-slightly more resource efficient. However, as I know that only 2% of > our e-mail is viruses (owch - I just looked that up - that's a lot higher > than I thought!), the "extra resource" required really is tiny. I > realise that's very site-dependent... The reality is all of our queues are > stuffed full of bounced SPAM - not virus alerts...
OK, I've kept quite while I watched this discussion to see what would pan out. Since it doesn't look like anyone has come up with a real reason yet, then I'll have to put my 2c worth in... IMHO, if you really detect a virus, then it is much better to send a 5xx result than to accept the email before bouncing it. (In reality, that is what we do now, we bounce it, but have customised the bounce message). This reduces the resource requirements on the 'smart' AV enabled server, as well as reduces the amount of non-useful "you may have a virus" cruft being bounced around and sent to people who don't have viruses, and wasting their time wandering if they do, as well as their IT person's time explaining that they should just junk it. So, the advantages of doing this (to me) are clear. It is very unlikely to cause a problem/less clear message to the recipient, and it greatly reduces the number of bounces to the faked sender. There are some dis-advantages that should be considered, which don't seem to have been noticed yet. Namely, *IF* a worm sent it's message using the configured SMTP relay, and the SMTP relay forwarded the message to a system configured to 5xx the virus, then it will correctly create a bounce message. This could in fact send a *known* virus infected email, including the attachment, to the 'supposed' sender, who may well wonder what attachment they sent to this person. So, previously we prevented the supposed sender from receiving the virus, in this case, we don't. I would claim that it is bad for the server bouncing the email to include the original email in entirety. I would also suggest that it isn't 'our' problem, the supposed sender should have their own AV software. So, trying to cut this short, I would propose that there is little overhead/negative aspects involved in incorporating a couple of extra options to the list of people to notify. ie, as well as psender, sender, admin, etc, we include bounce and extbounce. bounce = send a 5xx message (whatever the cryptic standard qmail error message is). extbounce = send a 5xx message based on the qmail patch being included. Include the qmail patch in the contrib directory. It would be valid to send a 'virus alert' to the admin, as well as bounce the email, or to send a 'virus alert' to the recipient as well as bounce the email. Of course, the default settings would be to continue as-is. IMHO, over time, we will see more and more AV enabled SMTP servers, and more and more of them will bounce emails rather than accepting them and causing just as much headache by sending out 'you might have a virus' alerts... Regards, Adam -- -- Adam Goryachev Website Managers Ph: +61 2 9345 4395 [EMAIL PROTECTED] Fax: +61 2 9345 4396 www.websitemanagers.com.au ------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click _______________________________________________ Qmail-scanner-general mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/qmail-scanner-general
