Derrick 'dman' Hudson wrote:I agree and have been using this successfully for some time now: I have those bounces blocked with Postfix.
If a message is either rejected (during the SMTP dialog) or bounced (after accepting and queueing the message) then the same innocent third party receives some junk mail.[1] The difference is only in which server is sending the bounce message.
The presumption being, of course, that the other side is a real MTA and not the virus/worm itself. Rejecting is acceptable as the onus is on the other side on what to do. You're not generating the bounce. If it is a virus/worm then it isn't likely to generate a bounce. If it is an MTA then they had best get their act together and not propigate viruses.
http://www.t29.dk/antiantivirus.txt
# t29.dk postfix header_checks regexp file, rev. 8 (2004-02-07) # conversion by Niels Callesøe (dk pfy) [EMAIL PROTECTED] # usage (main.cf): # header_checks = regexp:/etc/postfix/header_checks # # original compilation by Tim Jackson for SpamAssassin # http://www.timj.co.uk/linux/bogus-virus-warnings.cf # # conversion for procmail by Peter Jensen can be found at # http://pekaje.homeip.net/antiantivirus_procmail.txt # # Note: Some people have suggested using DISCARD rather than REJECT. This is a bad idea. # REJECT'ing these will not bounce to an innocent user, unless the antivirus program # forges the return address. Most antivirus programs insert their own, and so the only # one who will see the bounce is the admin who needs to fix his broken AV software. # In the event of a false positive, REJECT'ing will make sure the sender knows about it.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
