> > > > Sending a 5xx error only makes sense if a message is > quarantined due to policy reasons (by perl_scanner) since > that is usually where you have false positives. Otherwise > 99.9% of messages that have detectable viruses have fake > senders and therefore it would be meaningless to send a 5xx. > Perhaps it makes sense to only send 5xx if caught by perl_scanner. >
I'm not sure where you are getting all these ideas that 550'ing a virus will cause a non-deliverable to the return-path? The only situation where this could occur is when a virus uses a smtp gateway (ie does not contain its own smtp engine which is rare in itself) that does not have anti-virus and passes the mail onto the next mail server, which does have anti-virus and it 550's the mail... This causes the first SMTP server to generate the non-deliverable message to the return path... Now, who do you think is going to get the phone call??? The server that 550'd the mail, or the server without AV that's sending bogus non-deliverables? Ya, you guessed it. :) If you are running the server that 550's the viruses, it is NOT your responsibility to make sure the smtp server for the previous hop is secure (as long as that hop is not on your network)! Here are the 2 scenarios that we see... (using smtp rejections). Scenario 1) 1) windows end user gets a virus/worm 2) virus on end users computer fires up its own smtp engine, harvests the addresses from whatever address book it can find, and starts to send infected email to people in the address book, with a return path of some other entry in the address book. 3) my server receives a connection from the IP address of the infected client. 4) my server sends a 550 saying 'this has a virus' 5) STMP engine on the virus sees the 550 and moves on... It does not generate a non-deliverable to the return-path (which it spoofed in the first place). Scenario 2) 1) Lets say a legit sender on my network has a virus in a file they are trying to send via our SMTP gateway. 2) mail sent to smtp gateway, mail gateway 550's the mail 3) sender intantly knows the mail was rejected ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ Qmail-scanner-general mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/qmail-scanner-general
