Since you top posted, I will, against nature, respond in kind. The one "item" you missed from your analogy is that postal mail is "paid" for up front, by the person "posting" (anon or not) - eg the post-office gets paid _before_ your letter gets delivered. The problem with spam is that the receipient is "paying" the cost (cod with no chance to refuse delivery)... -- Larry Smith SysAd ECSIS.NET sysad@xxxxxxxxx On Thursday 16 June 2005 21:50, nick.staff@xxxxxxxxxxx wrote: > I'm sure many will think this a stupid comment, but in the hopes that some > don't I'll point out that the largest and arguably most efficient messaging > system in the world is built upon open relay. Anyone can anonymously drop > a letter in any mailbox in the US and while there's junk mail it's > proportions are certainly nothing like spam. Why the difference? Well > first I split spam into 2 categories: 1. legitimate advertisements for > legitimate products (whether solicited or unsolicited). 2. Fraudulent > mail, scams, cons, etc. > I think the email abusers almost entirely fall into the second category and > that nobody would be complaining if spam primarily consisted of > Bloomingdale's catalogues and coupon val-paks. So I think we are attacking > things the wrong way. The methods we are using - whether blacklists or > 'authorized email' is going to either prove fruitless or end up ruining the > big picture, which for me is electronic communication for everyone, to > everyone. Using electronic means, I don't see how we can ever prevent spam > and still have open global communication among disparate systems. It would > be a different story if one organization ran all email servers worldwide > but that horrible thought aside there will always be holes and breaks in an > authentication/authorization scheme unless people limit who they can > communicate with, and even then there will be spam. There's also the > returns we see on our efforts to consider. Think of the millions of > man/woman hours spent trying to stop spam - so many hours it probably would > have taken less to inspect every email by hand. And then when you think > (if you believe as I do) that everything can be gotten around and that > security holes are as infinite as the imagination, well then you know there > will always be some kid with a script (which also includes any real > spammer) who will be able to get around your defenses within a week of them > being implemented. My last unconstructive comment is that simple systems > scale lossless and complex systems grow in a complexity proportionate to > their size. Funny enough, I think the postal inspector's department came > about because of the amount of scams being sent via mail shortly after the > civil war (such a glut that it was bringing the postal service to their > knees). Yet the postal service remained open-relay - why? Maybe because > they realized that they didn't need to 'trace' scam-mail because scams are > trace-inclusive as the scammer must include a point of contact. Sure > there's the occasional anonymous letter bomb but since their resources > aren't spent blocking coupon mailers they are much more likely to catch the > big stuff. I know there are 8 trillion problems with this idea but I think > in general, email fraud needs to become like mail fraud and there needs to > be a team of inspectors who follow up on such reports and arrest violators > (I know the Internet is bigger than the US, so of course it's up to each > country how to handle it). I'm sorry for the non-technical post but I > think blacklists are disgusting (I don't care if they help or not) and I > just think so much brilliance could be directed elsewhere. Thanks and best > regards, > Nick Staff > nick.staff@xxxxxxxxxxx > -------------- Original message -------------- > > > > 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. > > mostly because of blacklists. it was working fine for its intended > purpose. > > > One needs to be careful not to dismiss established techniques in favor of > > the latest fashionable one that is not as well fully understood. > > I don't know what you mean by "relatively recent", but I was doing it at > least as early as April 1999 - that's the last mod date on my source files. > RFC 2554 only dates from March 1999. > > > 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. > > It's also pretty useful for preventing a relay from being exploited by > spammers. > > > 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. > > Rate limiting of this type (based on source IP address), if done properly, > doesn't > help or hurt zombies. The rates need to be set such that zombies can send > directly > to the recipients' MXes as easily, and more reliably, as they can send the > same mail via the rate limiting SMTP servers. > > > 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. > > Maybe you should stick to talking about things that you know something > about. > > > > 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. > > That's a problem with mail relaying in general, not just with open relays. > Now if you want to discourage multi-hop mail relaying, that might actually > be useful for lots of reasons besides just traceability. > > > > unfortunately, the vigilante character of various open-relay > > > blacklists > > > > blacklists are not the subject of this BCP. > > This thread has pretty much diverged from the subject of your draft > document anyway. > > > > 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. > > You mean "your draft document". It's certainly not a BCP as it's > currently written. > > Keith > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > > > -- > Best regards, > > Nick Staff > > -------------- Original message -------------- > > > > > 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. > > > > mostly because of blacklists. it was working fine for its intended > > purpose. > > > > > One needs to be careful not to dismiss established techniques in favor > > > of the latest fashionable one that is not as well fully understood. > > > > I don't know what you mean by "relatively recent", but I was doing it at > > least as early as April 1999 - that's the last mod date on my source > > files. RFC 2554 only dates from March 1999. > > > > > 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. > > > > It's also pretty useful for preventing a relay from being exploited by > > spammers. > > > > > 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. > > > > Rate limiting of this type (based on source IP address), if done > > properly, doesn't > > help or hurt zombies. The rates need to be set such that zombies can send > > directly > > to the recipients' MXes as easily, and more reliably, as they can send > > the same mail via the rate limiting SMTP servers. > > > > > 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. > > > > Maybe you should stick to talking about things that you know something > > about. > > > > > > 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. > > > > That's a problem with mail relaying in general, not just with open > > relays. Now if you want to discourage multi-hop mail relaying, that might > > actually be useful for lots of reasons besides just traceability. > > > > > > unfortunately, the vigilante character of various open-relay > > > > blacklists > > > > > > blacklists are not the subject of this BCP. > > > > This thread has pretty much diverged from the subject of your draft > > document anyway. > > > > > > 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. > > > > You mean "your draft document". It's certainly not a BCP as it's > > currently written. > > > > Keith > > > > _______________________________________________ > > Ietf mailing list > > Ietf@xxxxxxxx > > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf