That's purely a policy issue, and has nothing to do with performing the spamExcept if you want to notify the user somehow rather than /dev/nulling the mail you have the options:
and virus detection during or after the SMTP conversation. Mail policy tools
such as Amavis and PureMessage would not be doing their jobs if they did not
include configurable notification!
* accepting the mail, then bouncing it back ( and if this was faked, you might get an automated response, which you don't want )
* reject the mail, you don't have to think about doing anything after this, and you won't get bouned-bounced messages
Accept then bounce:
Host A sends an email to host B, host B accepts it and sends a bounce to that email, which was faked, so a bounce is sent to host C.. Host C doesn't have a place for this email to go, so C sends the email back to B saying "no such user" or something ( or "your email contained a virus" if it had the virus/email attached ). So, in this case, host B and C have caused un-needed traffic, for the sole purpose of notifying the user :-)
Reject at SMTP DATA:
Host A sends an email to host B, host B notices a virus/spam, host B sends reject instead of OK. Host A, because here I'm assuming this is a malicious SMTP server, will have already closed the connection, so no bounces are sent.
Of course, for _real_ mail ( a user sending eicar or something ;-) ) either method would be equal - it's when you're dealing with a malicios user that the bounce idea has a problem.
Honestly, the only 2 good options are SMTP DATA reject or not sending bounces at all. ;-)
FYI on the post-DATA scanning - the message is placed into a temp directory ( much like Amavis does ) where the virus scanner then scans it and returns a code to the mailserver.
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
