On Wed, 18 Feb 2004, Vernon Schryver wrote: > ] From: "Robert G. Brown" <[EMAIL PROTECTED]> > > ] ... > ] In the department, where we do USE spam assassin, no bounce messages are > ] generated except when mail fails for one of the standard reasons > ] unrelated to filtering of any sort. ... > > On today's Internet, innocents are almost certainly receiving bounced > spam and viruses from your system that could not be delivered for > reasons unrelated to filtering, such as bogus target addresses.
If a message comes in incorrectly addressed, yes, it will bounce. It should, shouldn't it? This has nothing to do with whether or not it is spam or a virus or any other kind of message. If it is a bad thing, it is a very fundamental bad thing... As far as spam itself and my filters are concerned, there ARE NO BOUNCES generated at any point from when the MTA accepts the message as being RFC-compliant and deliverable through my reading (or not) any message. The mail comes in (to postfix). Postfix is configured to use procmail as a mailbox delivery command. procmail pipes the mail through spamc. spamc (the spamassassin client) scores/tags it passively and delivers it, in my case to procmail again, but now in userspace. Procmail applies the rule: :0: * ^X-Spam-Level: \*\*\*\*\* SpamSpamSpam and presumptive spam is appended to the SpamSpamSpam folder. All post-MTA tools are configured to generate no bounce messages (to the extent that they are capable of such a thing, which is actually not terribly great). As far as the sender was concerned, the message was successfully delivered, and no, zero, none, ziltch email messages are generated to any human or agent as a side effect of their delivery. There may well be MUA's or post-MTA filters that generate a bounce or C/R message on "identifying" a message as spam -- I could probably write a trivial filter that would do this in a few minutes of work, and I get bounces that appear to come from them from time to time. I think that we are in complete agreement that this is a bad idea for so many reasons -- waste of system resources, annoying the innocent, and the fact that such tools tend to be written by idiots and hence use appallingly poor rules to identify "spam" (like the appearance of [EMAIL PROTECTED] anywhere in any message even one time -- he says, resigning himself to another stupid bounce message from whoever it is on this list that apparently is using such an MUA:-). However, it seems to me to be just as bad an idea at the MTA level, and I have little patience with automated C/R systems because they I have yet to encounter a message for which they were appropriate or useful or anything but a PITA. > ] If that rejection occurred during the original transaction and generated > ] a bounce -- well, that's the kind of thing we see above, a cure that can > ] easily be worse than the disease, ... > > The idiotic messages from that stupid challenge/response system are > not generated during the original SMTP transaction. It is possible > to do challenge/responses that do not involve separate messages, but > they suffer from MUAs and MTAs that do not handle SMTP rejections > properly and users who cannot understand them. > > Somehow making SMTP rejections understandable to users is something > that the IETF might attempt. I think that is something the ASRG is > considering. I also think that is nearly impossible. such is life. > ] If I understand what you are saying, perhaps there is a way to "do it > ] correctly" -- reject the spam at the original smtp transaction but with > ] a message that goes back to the original sender (only) in spite of the > ] fact that both the From and Return Path header entries might well be > ] forged and the message relayed through one or more open relays. ... > > Headers and the SMTP envelope, forged or not, are irrelevant to SMTP > 5yz and 4yz rejections, as far as the rejecting SMTP server is concerned. > If the spam came through an open relay, then a proper SMTP rejection > might cause the relay to send a bounce to an innocent mailbox, but > SMTP relays are out of favor among spammers compared to open proxies. I will wait with great interest to see if the "nearly impossible" comes to pass -- it certainly has before in the world of IT;-) Even so, I personally would want a degree of control over what the MTA rejects out of mail sent to me. A spamassassin-like tool (or SA itself) integrated with the MTA so that the agent uses user-specified rules in place of or on top of global/default rules, and a fair degree of control over what is done with regard to the rejected mail. I actually think that the spamassasin/procmail combination above is nearly ideal on the MUA side, as I can see no particular reason to want to bounce to spammers or anybody else, and MOST of the mail that MIGHT be mis-scored could easily be either whitelisted or confirmed even without a bounce with a definitely non-spam out of band message. By spooling my rejects for a week, I don't even have to have a retransmission, just a message saying "why didn't you respond to XYZ". And SA is pretty smart, and actually getting smarter...new rules seem to be gradually eliminating a lot of the [EMAIL PROTECTED] messages, for example. rgb -- Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:[EMAIL PROTECTED]
