> 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