email@example.com (Scott Dorsey) wrote:
> In article <firstname.lastname@example.org>, jdj <email@example.com>
>> On Wed, 17 Nov 2004 03:12:34 -0500, Dan Lanciani wrote:
>>> My filters respond to every (seemingly) spam message with a note
>>> indicating how to bypass the filter if in fact the mail is not spam.
>>> (Actually they do this only once per sender per some months, but you
>>> get the idea.) I really can't just dump (seeming) spam in the bucket
>>> since there are a few false positives. But I get 1500+ spams per day
>>> and I can't look at them all.
>> Chances are that your filters are sending responses to forged
>> addresses. Occasionally I see messages like that and they are treated
>> like spam, since they have nothing to do with me and responding to
>> them is useless. They go to /dev/null. Until it's full.
> I am totally inundated these days with misidirected challenge/response
> messages and bounces from spammers that send out huge amounts of spam
> using my e-mail in the return address. It's got to the point where I
> just dump anything from mail-daemon or from postmaster addresses, and
> I just dump anything that looks like a C/R.
Under normal conditions I get only 20-30 of these per day so I try to
look at them in case any really do represent something intended for me
(or an interesting error).
N.B. I'm not a big fan of pure C/R systems because of the obvious
deadlock issues and the extraneous traffic. But I maintain that
bouncing mail for content is no worse than bouncing it for any other
reason, and explaining the reason as part of the bounce message is
> When someone does a spam run with my return address, I will get ten
> to fifteen thousand bounces in a 24 hour period. This is very
Yes. Happily I get those only every few months.
> You _might_ do a lot better just to extract the first Received: line from
> the header and send a complaint to wherever that came from. For example,
> take the following procmail rule:
> # Comcast dynamic addresses
> |* ? /usr/local/bin/formail -xReceived: -uReceived: | grep
> |cat $HOME/spam - | Mail -s "Your Spam" firstname.lastname@example.org
> We can basically be sure that if something comes from a dynamically
> allocated address on comcast, that it's spam from a zombie machine, so
> the false positive rate on this is basically zero. Real mail from
> comcast customers comes from the comcast mail server.
I think that that would be an extremely bad idea for several reasons.
First, it would fail to fulfill the primary purpose of responding: to
inform false positives that an error has been made.
Almost as important, it would require me to automatically create
_outbound_ SMTP connections as a matter of course. That really is
unsolicited email and, while I don't agree that it is actually "spam",
it would provide the C/R haters ammunition to have my mail server
As things stand I can almost always return my warning message via the
incoming SMTP session that carries the spam. This has several
advantages. First it avoids the issue of sending unsolicited email as
above. Second, for cases where the spammer is connecting directly and
not using a real relay it pretty much guarantees that bogus bounces
will not make it back to the forged from address, thus sparing
innocent users a little junk mail.
> Of course, Comcast doesn't care and they won't do anything about the
> complaints, but it will make you feel better to report the stuff
No, really, it won't make me feel better. :) I try to "feel" as little
as possible about spam. I would feel very bad if I incorrectly
reported someone for spamming, though. IMHO, too much "feeling" about
spam -- keeping the War on Spam raging -- is a big part of the
problem. There is a lot of empire building going on with hundreds of
blacklists trying to punish various behaviors (apparently including in
some cases the behavior of wanting to fight spam differently from the
list's owner) yet ultimately doing little to prevent the increase of
spam (let alone reduce it). This worries me in the same way that the
anti-virus companies' dependence on the virus worries me.
> And there are legitimate ISPs that do actually take care of
> problems, although these days they are increasingly in the minority.
Even if, say, 50% of them did something I'd still have way too much
spam to look at.
> Dan Lanciani <email@example.com> wrote:
>> firstname.lastname@example.org (jdj) wrote:
>>> On Wed, 17 Nov 2004 03:12:34 -0500, Dan Lanciani wrote:
>>>> Interesting. I didn't realize that this was considered a bad thing.
>>> There are a lot of people who equate receiving spam to stepping in
>>> what the cat leaves on the lawn.
>> This makes no sense. How exactly can you avoid "receiving spam"?
> By removing spammers.
Sure, but you haven't mentioned a practical way to accomplish that.
Like most people, I learned to avoid stepping in cat/dog/whatever
droppings on the lawn within a few years of learning to walk.
Avoiding "receiving spam" seems a tad harder, and I find it a bit
insulting to equate "receiving spam" with being so careless as to step
in "what the cat leaves on the lawn."
Again IMHO, the way to eliminate spam is to make it an ineffective
tool for profit, and the only way to do that at the end user level is
to make it invisible. Yet when anyone suggests a way to do this, the
anti-spam warriors always have some scare tactic ready, e.g., the
classic quip that you will lose business by missing important email
(as if most businesses answer any -- let alone spamish -- email these
> If every single one of us here went and injured a single spammer, the
> spam problem would be more or less gone. In fact, if one person beat
> Ralsky up with a baseball bat, I think we'd all see about a 50% drop
> in spam.
Yes, it seems to be ok to propose totally absurd solutions since there
is little danger of their being implemented. However, an approach
that might actually hurt the spammers financially (e.g., my suggestion
of sending a SYN for each URL they deliver to you) is very dangerous
because someone might be sued. This seems to be typical of collective
anti-spam efforts that succeed in their direct goal (e.g., punishing
owners of open relays) yet do nothing in the long run to stop spam,
even though that is supposedly their indirect goal.
>> Obviously. But why should I care? The point of the response is to
>> tell people who were neither sending spam nor forging their address
>> that their mail has been incorrectly identified as spam. Note that I
>> do not include the body of the original message in my automated
>> response, so you can't use my filter to reflect spam to a third party.
> The problem is that the number of people in that category is a very
> small one,
It is small, but it is still several per month. If I cannot bounce
the messages with a warning I must look at them all.
> and the number of people who receive misdirected bounces is
> a very high one.
That may or may not be true depending on the way the spam is sent in
the first place. But even if it were true, do you really believe that
it represents a significant burden over that created by other types of
bounces (bad target address, over quota, sender not allowed, etc.)?
The problem is that you are elevating spam to a level beyond any other
email such that it cannot even be bounced legitimately. For anyone
that does not wish to miss genuine email that leaves only the option
of looking at (at least) the subject of every message. This has the
effect of keeping spam in the spotlight and perpetuating the
associated angry feelings.
> The cure is worse than the disease.
I don't buy it. First of all, it at least is a cure. There are many
other purported cures that are worse than the disease (e.g., blocking
legitimate ISP clients to leverage collateral damage and similar
political intrigue) that seem to do little good for end users while
feeding the ever-growing war. Second, is reading a bounce message
really worse than reading a spam message? Certainly it is for the
spammers because it defeats their purpose of maximum visibility.
> Note that on the whole, the vast majority of messages that your spam
> cleaner detects will actually be spam, and therefore will not have an
> accurate return address. In fact, the vast majority of messages
> received at all will actually be spam, if your statistics are anything
> like mine.
They are. However, it is a mistake to equate a forged address with a
bounce that may actually reach a legitimate user. From the samples I
have examined, an extremely large percentage of spam messages that I
receive have nonsense addresses that simply do not exist. From
connections that I have monitored and even interacted with, a large
percentage of spam delivery sessions appear to come direct from spam
sending software and not from a real relay. There is no way that the
spam delivery software is going to forward my 550-style rejection
message back to the forged from user, if that user exists at all.
In order for my system to cause bounces to a real (innocent) user a
spammer must not only forge that user's from address but also send the
message through a full-fledged mail relay that is willing to package
up a session transcript and mail it "back" to the user. I don't think
this is a common scenario these days. If it really is a problem it
could be solved by something like SPF with an option that says,
"please silently drop mail with my envelope address that comes from
an unauthorized relay rather than rejecting it." (And yes, I know
SPF is another thing that anti-spam warriors hate. And yes, I do
understand how SPF reduces the generality of SMTP relaying. Or at
least I understand how it would reduce that generality if it had not
already been reduced by the war on open relays. :)
Oh, and I also understand the argument about zombies using their
host's legitimate relay. (a) I don't see a lot of that kind of
traffic and (b) I'm not convinced that I owe such users (whose machine
would be, after all, spamming me) the duty to silently absorb their
spam. They are not quite the same as the competely innocent victims
Anyway, as I said the the other correspondent in this thread, please
feel free to have the last word. I realize that this is a religious
issue and could be debated forever. However, I ask that you not
assume that I haven't done some fairly extensive analysis before
implementing my solution.