a note to those who would automate their rejection notices

    > of the foundational principles which made the internet
    > possible and which made it different from alternatives such as
    > OSI, very few remain.

Would SPF <http://spf.pobox.com/> be a bit less destructive than many
other proposals to counter "trivial forgery".

No. Nor will Yahoo's recently announced technology make any real difference.
Preventing forgery is a way of protecting domain names as "service marks" and
also ensuring that your own or your customers' non-spam output isn't snared
in a bunch of false-positive trappery. But it won't stop or even slow the
rate at which spam is sent or is received. Spammers still lie, but they are
no longer as dumb as fence posts, and they can register throw-away domains
whose crypto-authenticity is completely valid, even in the presence of wide
scale wormspoor-proxy usage.

It could be that I'm just especially irritable this year, or it could be that
the reinvention frequency of bad ideas really is growing at the same rate as
the internet's population.

I no longer think that E-mail as we know it will survive. But I would be
less irritable about it if the people who keep proposing to "save" it would
(a) do their homework, (b) assume that spammers are going to try to adapt,
and (c) think about the side effects of the tools they deploy. This is
information warfare. "Warfare." You aren't fighting the terrain or the
elements or some mindless bacteria. You're fighting other humans, and they
are armed, committed, dangerous, and adaptive. In that light, I look at
things like Bayesian filters or Vipul's Razor and I wonder, why is the "D"
in Vern's DCC (see www.rhyolite.com/dcc) so difficult to predict a need for?

(Y'all already know my views on relay-probing without spam-in-hand, but the
tie-in here is "how can you fight spam if your principles aren't different
from the people you're fighting? where exactly do you think it will end?")

Anyway, I hope folks will stop sending automated rejection notices to domains
who were not involved, other than by forgery, in the transmission of a virus
or spam. In other words, there's relevant operational content in this thread,
and when "fighting" spam it would be reasonable to avoid hurting uninvolved
third parties. AOL, please listen.

Cox in particular was doing this until recently (we got their attention rather
quickly after blacklisting their main mail servers). We were being joe jobbed
badly, and cox's mail servers were generating massive amounts of bounces per
minute, and out of all the bounces, cox was generating the most (at least 3/4
of them)

The result was that each one of their mail servers (more then a dozen) was
sending one bounce per connection, and launching anywhere between 5-12
connections at a time, then reconnecting right away after sending the single
bounce and disconnecting. We quickly ran out of connection slots on both the
primary and secondary mail spoolers, leaving us unable to get incoming mail
until we firewalled out cox's mail servers.

One would think, if your going to run a cluster of mail servers to handle your
mail, that you would rate limit your bounces so that people (like myself) who
can't afford to have a dozen or more heavy duty mail servers don't end up
getting DoS'd by your mail server's ability to pump out millions of messages
per hour.

Someone said on one of the newsgroups, "Well, maybe they setup their system
correctly, and don't see a need to change something that works." The problem
is, theres a difference between properly configuring a mail server and
responsibly configuring a mail server. When you responsibly configure a mail
server, you take into account OTHER people's systems and how THEY will be able
to deal with your server.

Part of the issue comes with when you accept a mail, then bounce afterwards,
instead of just bouncing after RCPT TO: or DATA. When you delay the bounce,
you will generate a bounce to the From: address, even if it is forged. When
you outright reject the message, you pretty much reduce the risk of that
happening by far, as the sending server will see that the message was
rejected, and hopefully move on. Now, this works with open proxies, but not
with open relays. Do spammers use open relays much anymore? No, not really.
Why leave a trail back to yourself when you can hide completely?

AOL has _not_ done this to us though, we've seen maybe one or two bounces from
AOL's servers, but nothing even remotely close to what Cox is doing.

Just my thoughts, flame away :slight_smile: