Re: Last Call: 'Email Submission Between Independent Networks' to BCP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]