> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of John > P Verel > Sent: Tuesday, August 19, 2003 6:43 AM > To: spamassassin list > Subject: [SAtalk] Re: How To Change Recipient In User Unknown Message? > > > > On 08/19/03 07:06 +0100, Yorkshire Dave wrote: > > > > There needs to be a page somewhere to explain why bouncing spam is > > bad. > Based on this thread and the reference to the notes on linux.org, I'm > persuaded that attempting to bounce spam is not the right way to go > about this and have amended my procmail recipe accordingly . Thanks to > all for the feedback.
A good plan. Although this issue has been discussed exhaustively already, I thought this post to the procmail list, lays out the issues well. The author of the note, David Tamkin, is a principal contributor to procmail. http://info.ccone.at/INFO/Mail-Archives/procmail/Apr-2002/msg00292.html To: <[EMAIL PROTECTED]> Subject: Re: EXITCODES, bounce, might be off topic From: "David W. Tamkin" <[EMAIL PROTECTED]> Date: Fri, 19 Apr 2002 17:23:56 -0500 Rui Pires asked, | What is the exact path the bounce follows? Does it look to the | Return-Path: field (often inexistent or as much crap as the From:)? Does | it try to follow the path it took to reach my server, contacting the | same servers for mail transfer?... It goes to the envelope sender address as provided to the MTA in the MAIL FROM: line of the SMTP dialogue. That address might be in Return-Path:; it might be nowhere in the visible headers at all. Procmail generally does not know it. Bouncing spam from the LDA after the SMTP dialogue is over is a bad idea, and you should remove those recipes. The envelope sender address on a piece of spam falls into one of three categories: 1. It's a nonexistent, perhaps syntactically invalid, address. Your bounce will go nowhere and your system's attempt to consult a nameserver and transmit the bounce notice somewhere will just be a waste of cycles and bandwidth. 2. It's the real address of someone other than the spammer, someone whom the spammer is trying to harass by having the bounces go to that person for all the copies of the spam sent to invalid addresses. By sending yet another bounce notice to the victim, you're making it worse on an innocent person who is already suffering more than you from that piece of spam. 3. It's an address that goes back to the spammer -- but chances are 98% or greater that the spammer couldn't care less and absolutely will not remove your address from future mailings. Chances are 100% that whoever sold your address to the spammer is not going to remove it. Rejecting spam during the SMTP dialogue is a different matter: that kind of bounce will go to the system that initiated the connection [greatly reducing the likelihoods of #1 and #2 above], it will keep the item out of your mailbox, and it will save the trouble of running the LDA on that piece. But once the message gets into procmail's hands, that opportunity has passed, even more so because the Return-Path: header might be forged and you'll have even less chance of sending it to the party that deserves it. Bouncing spam from procmail can be pointless or mean, but it can never help. Don't do it. ------------------------------------------------------- This SF.net email is sponsored by Dice.com. Did you know that Dice has over 25,000 tech jobs available today? From careers in IT to Engineering to Tech Sales, Dice has tech jobs from the best hiring companies. http://www.dice.com/index.epl?rel_code=104 _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
