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. One needs to be careful not to dismiss established techniques in favor of the latest fashionable one that is not as well fully understood. 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. 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. 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. 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. > 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. > unfortunately, the vigilante character of various open-relay blacklists blacklists are not the subject of this BCP. > killed any attempt at this kind of innovation. just as we're now in > danger of various kinds of brain-dead "authentication" methods and > meaningless requirements killing useful email functionality. new authentication methods are not the subject of this BCP. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf