Keith,
it's possible to have open relays that don't contribute to spam. but
those relays need to employ some other means, e.g. rate limiting, to
Rate limiting is a relatively recent technique. Though very useful it has...
ummm, limited applicability.
Actually, in my neck of the woods at least rate limiting has been a popular
technique to use for at least five years, and has been in use at some sites for
a lot longer. However, I see it used mostly in two ways:
(1) To limit the amount of damage a local zombie can do.
(2) To limit incoming spam.
I've been tempted to try and write a document about rate limiting, but the
problem is most of the information I have about its effectiveness (or lack
thereof) is anecdotal in nature. Such a document really needs to be developed
by folks with substantial experience using the technique on a large site over a
number of years, and even then I don't think you're going to get an analysis of
its relevance to operating open relays.
One needs to be careful not to dismiss established techniques in favor of the
latest fashionable one that is not as well fully understood.
The problem with rate limiting isn't that it isn't well understood, for some
class of attacks at least. Rather, the problem is, as you indicate below, the
nature of the threat continues to evolve, and the way it has evolved has made
rate limiting less useful, for sure when it comes to blocking incoming spam. It
remains useful in limiting damage from local zombies, mostly because these
still tend to send lots of messages very quickly.
For example, rate limiting is used to control a single source. It's quite
useful
when used at the destination. At a sufficiently well-run source network, it
also
can be pretty useful.
Exactly.
The problem is with zombies. They make mush of old-time models of spam, since
they demonstrate that a very small data stream from a single source can be
leveraged into a very, very large data stream, given enough sources.
Zombies are indeed the problem, but it breaks down into two cases, one where
the zombies you're trying to deal with are your own systems (or your customer's
systems), and another where the zombies are elsewhere and are targetting you.
Rate control, especially rare control with notification, is still pretty
effective at dealing with local zombies.
However, I fear that use of rate limiting to allow open relaying is more
cloesely aligned with the second case.
One can start imagining more complex rate-limiting models, but then we would
be
talking about research efforts. A BCP is not supposed to rely on research,
especially when it hasn't been done.
The rate limit stuff I see in use is an odd mixture of sophistication and
simplicity. For example, it is common to see limits applied at multiple levels,
that is, there may be a limit on recipients per transaction, a limit on
transaction per session, and finally a rate limit on incoming sessions.
However, it is often the case that rate limit information isn't shared all that
well between mutlple systems. I also don't see careful analysis of the effect
of rate limits being done, although that may be more due to folks keeping
their results to themselves than anything else.
Besides that, note my comment above about "sufficiently well-run source
network"
is clearly not possible when the network accepts mail without accountability
of
the submitter. In other words, an open relay.
Agreed.
block spam. the goal of such relays is to make it at least as easy for
the spammer to simply contact the appropriate MXes for the destination
addresses as to use the relays. of course it is necessary for such
relays to record source IP addresses, etc., so that they are as
traceable to their origin as messages sent directly to MXes.
I don't know how much experience you have trying to do such tracing, but the
spamops folks have made quite clear that it is both vastly more effort and
considerably less productive, than one might expect. Again, there is no way
that relying on that is a reasonable best practise on the current Internet.
As
a small example, not that spammers now are stealing IP Address blocks. That
pretty much kills backtrace accountability.
This is another case where I have only anecdotal information - I may write the
software but I don't run a large site that uses it - but the information I have
agrees with your assessment.
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf