"FAQ 6.5 Why can't I bounce spam back to the sender?" The reasons you give are of course perfectly valid. However, to my mind the most obvious reason for not bouncing spam and one that is seldom acknowledged is the much more important consideration of traffic congestion. The internet is already groaning under the strain of billions of spam messages. If every one of them were to be bounced spam-mail traffic would in effect be doubled and the system would probably be unable to cope. At the very least, it would necessitate a great increase in world-wide server capacity the cost of which would almost certainly be passed on by ISPs to their clients. It is unfortunate that some of your competitors proudly proclaim as a 'feature', the ability of their programme to bounce spam messages. I can only conclude that they are either very shortsighted or irresponsible morons. Please consider the foregoing purely as comment. It is not intended to be critical of SpamBayes in any way. Perhaps you could expand the answer to FAQ 6.5 to reflect the above, e.g. something along the lines "In addition, bouncing spam messages simply increases email traffic leading to even further congestion on the internet." might suffice. Regards, Geo.
There are more important reasons to not bounce spam than internet congestion. A bounce is a class of automated message called a delivery status notification (DSN). A recipient MTA that accepts a message for delivery must send a DSN to the return-path address if the MTA is unable to make final delivery. Spambayes runs in the MUA only after final message delivery, so you can't say the message wasn't delivered :) For this reason, SMTP makes no provision for an MUA to ever send a DSN. More importantly, there is no reliable bounce address in a message that later turns out to be spam. In fact, we know that the return-path is virtually always forged. Generating a bounce after acceptance will abuse an innocent third party, if it is deliverable at all. Many MTA's persisted for a number of years in promiscuously accepting all messages for their domains and sending DSN's later for undeliverable messages. Operating an MTA this way is called a store-and-forward configuration. Once people started using IP blacklists, spammers quickly realized that they could trick MTA's that were not blacklisted into delivering their spam. They would simply address the spam to an undeliverable address at a domain with a good reputation, let's say bogus@aol.com, and put the real target address into the return-path, say victim@poorslob.com. AOL's MTA accepts the message, since it purports to be for an AOL customer. Then it finds it had no mailbox named 'bogus' and sends a bounce message containing the spam to victim@poorslob.com assuming they were the originator. The MTA at poorslob.com accepts all messages from aol.com, so it accepts and delivers the spam and then blames AOL. So the best answer as to why it is inappropriate to bounce spam is that it turns your MTA into a spam reflector, which will properly get you blacklisted for abuse. -- Seth Goodman
participants (2)
-
Geo. -
Seth Goodman