Re: Categorization of TCP/IP service provision types (was: Re: The right to refuse, was: Re: Principles of Spam-abatement) (FWD: I-D ACTION:draft-klensin-ip-service-terms-00.txt)
At 19:19 22/03/04, John C Klensin wrote: The subject is not going to do away as long as people think they have a fundamental human right to do the equivalent of moving to a cardboard box under a bridge and then demanding banks and creditcard companies to see them as creditworthy as their bourgeois neighbors. Of course, that belief is not limited to the Internet... for better or worse. Actually it could be a way of describing mobiles. And it also works for 5 years old kids. jfc
Re: Categorization of TCP/IP service provision types (was: Re: The right to refuse, was: Re: Principles of Spam-abatement) (FWD: I-D ACTION:draft-klensin-ip-service-terms-00.txt)
--On Friday, 19 March, 2004 18:34 -0700 Vernon Schryver [EMAIL PROTECTED] wrote: From: John C Klensin Last week's version of the spam discussions, led to an interesting (to me) side-discussion about what was, and was not, an Internet connection service. ... draft-klensin-ip-service-terms-00.txt. http://www.ietf.org/internet-drafts/draft-klensin-ip-service-t erms-00.txt This clearly isn't finished, indeed, it is not much more than a skeleton with a few examples. It needs more work, probably additional categories, and more clarity about the categories that are there. I think it is about as clear as it should be. Much more clearity would require sample contracts or risk getting bogged down in nitpicking on whether it is practical to run an SMTP server on a dynamic IP address, whether an IP address that changes once a year is really dynamic, and so forth. Those are the places where I clearly don't think we should go. To do so rapidly gets us, I think, to a function matrix. That would be conceptually useful, but would not be extremely unlikely to be adopted by vendors and hence would not help at all with the promote truth in advertising theme that started the attempt. What I see missing are hints why dynamic addresses are widely blacklisted. There need to be words about the first three classes usually being priced so low that providers cannot afford to keep records of who was using a given address when it was used to send spam, denial of service attacks, or other naughtiness, or cannot afford to have abuse department to consult any records there might be. Text would be welcome, but it seems to me that this addresses a different theme. One could say that quality of customer service usually improves with categories, but that isn't universally true until one starts making categories of customer service efforts. From my experience, I would even question your description above, although we don't disagree about the consequences: my impression is that a number of the broadband operators offering low-end services actually have fairly good logs. What they don't have are abuse departments with the will and resources to dig through those logs and identify specific offenders. Hand that same provider a subpoena associated with, e.g., some clearly criminal behavior, and records seem to turn up in a lot of cases. What I've done in response to several comments is to add text to the beginning of the terminology section that tries to make it clear that these definitions are about what the provider intends to offer. Whether the restrictions are imposed by AUP (or contractual terms and conditions) and whether technical means to enforce particular restrictions are effective on a particular day seems less important. The dynamic address issue is, from that point of view, just a technical means to enforce (or just consistent with) an AUP or Ts and Cs. I.e., if one believes that blacklisting dynamic addresses is rational, then part of the reason for that isn't too cheap or the addresses themselves, it is that these dynamic addresses tend to show up only in server prohibited environments. Maybe it is equally rational to blacklist an address range on the theory that anything coming from that range is in violation of provider conditions of service and that one bad deed (violating AUPs or Ts and Cs) is as bad as another (demonstrated spamming). But I don't see a reasonable way to incorporate any of that reasoning (whether one agrees with it or not) into the document without generally weakening it. If you do, please suggest text. If there is real interest in the subject, I'd like to see someone else take over the writing and editing. If there isn't any real, perhaps we can stop spending time discussing the subject. The subject is not going to do away as long as people think they have a fundamental human right to do the equivalent of moving to a cardboard box under a bridge and then demanding banks and creditcard companies to see them as creditworthy as their bourgeois neighbors. Of course, that belief is not limited to the Internet... for better or worse. If no one else will take the job and if there is any hope of getting it past the IESG, I'll happily be your editor, elaborator, or whatever. My strengths don't include writing intelligible English, but it needs doing. Thanks. I've started a discussion with some selected ADs about what they want to do with this, if anything. My intent is to wait to see what they have to say. If they aren't interested, and interested in moving toward BCP, then the effort is, as far as I'm concerned, dead. If they want a WG, then the next real task is charter. Otherwise... well, let's how they want to proceed. And, as far as I can tell, you do intelligible English very well. john
Re: Categorization of TCP/IP service provision types (was: Re: The right to refuse, was: Re: Principles of Spam-abatement) (FWD: I-D ACTION:draft-klensin-ip-service-terms-00.txt)
On Mon, 22 Mar 2004 13:19:12 -0500, John C Klensin wrote: And, as far as I can tell, you do intelligible English very well. I am travelling just now but when I come to rest I volunteer to look over if this would be of value. Jeffrey Race
Re: Apology Re: Principles of Spam-abatement
On Tue, 16 Mar 2004, Ed Gerck wrote: Dean Anderson wrote: On Tue, 16 Mar 2004, Ed Gerck wrote: For example, saying that you're [EMAIL PROTECTED] should not be so easy to do when you're sending email, even though it should still be easy to set [EMAIL PROTECTED] as your address in your MUA. The From: address is just dressing. It makes no difference what its actual value is, nor that it can or can't receive email. As was pointed out, many things only send email, and don't receive it. Those things will have informative (or not) from addresses that are invalid for reception. Things that send email but don't receive them can nonetheless have a valid email entry for 'no mail accepted', with no mailbox. What difference is there between 'not accepted, not a valid mailbox', and 'not accepted, never heard of it before'? Either can still be faked, so making a distinction does not remove such an abuse. Such a distinction just makes the broken Verizon mailbox test be a somewhat more valid test, but it doesn't change the other negative and non-scalable aspects of such testing. More importantly, knowing this information doesn't help you stop abuse. It is clearly just a reaction to the invalid assumptions made by the Verizon test, and an attempt to make the assumptions less invalid. However, there is no gain by doing so because abusers would simply react by using valid addresses that are either valid, has mailbox, or valid, no mailbox. rather than simply randomly made-up addresses. After abusers adapt, there is no benefit to the alteration, yet ISPs will have a huge cost in making the changes. The practice of using false and deceptive email addresses has been made illegal by the CAN-SPAM Act, and genuine spammers have largely (or completely) stopped doing this. That leaves the abusers whose aim is purely annoyance who fake from: addresses. But such abusers aren't going to stop faking from: addresses. They will just start faking 'valid' from: addresses that are either 'valid and receive email', or 'valid and don't receive email'. They simply adapt. We have been making gratuitous, dead end, unsuccessful protocol modifications for 10 years now. Unless you can show that this will actually lead to something beneficial, it is just another in a series of gratuitous and expensive changes with no benefits. In terms of trust as I defined before here [1], an email address for those things (or any other things) should have a *minimum* of three values: + trusted according to policy(+) 0 trust value not assigned - distrusted according to policy(-) Of course, the positive and negative range can be expanded in values as well. How to assign these values? How the trust model works? Let me copy from an earlier discussion elsewhere. This is the wrong question to ask. The real answer is, what trust model would you like? ' Those who suggest that the decision is not whether a trust model, but 'what kind of trust model would you like' are again jumping ahead of themselves. There is no evidence that we need to use a trust model nor that a trust model will solve the problem. Just the opposite. We've had a lot of experience with trust over the last 10 years--and we have frequently found the advocates of trust to be untrustworthy themselves. We have seen repeatedly, again and again, that anti-spammer leaders aren't trustworthy, and use their trusted positions inappropriately for personal revenge. These aren't simply mistakes, but are bald lies that are easily disproved. The leaders know, however, that some people will be misled for some time, anyway. Given that record, how can we possibly __trust__ such a proposition? We can't use a trust model. Further, as previously pointed out, for a trust model to be effective, one needs a method of effective identification which we don't have, and which is a major problem to any trust model, even if the trust operators were trustworthy. A trust model won't work. The problem is, thus, not how do you determine trust, especially with all the different definitions of spam possible, but how do you want to do it. I disagree. The problem is how to stop abuse. We have learned quite a bit about that. Mostly, we have learned how not to do it. Some suggest we shouldn't worry about how to stop the problem, but should simply concern ourselves with how to effect gratuitous changes. Of course, they don't describe their changes as gratuitous, but it seems some do think the question of whether the changes are gratuitous shouldn't be considered since doing so impedes their implementation. Obviously, no one wants to implement gratuitous changes. We have certainly learned not to do some things: --- Trust models aren't a solution because the operators are dishonest and untrustworthy, as history and experience with many dishonest blacklists has demonstrated. --- Trust models can't be fixed simply by having more honest operators,
Re: Categorization of TCP/IP service provision types (was: Re: The right to refuse, was: Re: Principles of Spam-abatement) (FWD: I-D ACTION:draft-klensin-ip-service-terms-00.txt)
From: John C Klensin Last week's version of the spam discussions, led to an interesting (to me) side-discussion about what was, and was not, an Internet connection service. ... draft-klensin-ip-service-terms-00.txt. http://www.ietf.org/internet-drafts/draft-klensin-ip-service-terms-00.txt This clearly isn't finished, indeed, it is not much more than a skeleton with a few examples. It needs more work, probably additional categories, and more clarity about the categories that are there. I think it is about as clear as it should be. Much more clearity would require sample contracts or risk getting bogged down in nitpicking on whether it is practical to run an SMTP server on a dynamic IP address, whether an IP address that changes once a year is really dynamic, and so forth. What I see missing are hints why dynamic addresses are widely blacklisted. There need to be words about the first three classes usually being priced so low that providers cannot afford to keep records of who was using a given address when it was used to send spam, denial of service attacks, or other naughtiness, or cannot afford to have abuse department to consult any records there might be. If there is real interest in the subject, I'd like to see someone else take over the writing and editing. If there isn't any real, perhaps we can stop spending time discussing the subject. The subject is not going to do away as long as people think they have a fundamental human right to do the equivalent of moving to a cardboard box under a bridge and then demanding banks and creditcard companies to see them as creditworthy as their bourgeois neighbors. If no one else will take the job and if there is any hope of getting it past the IESG, I'll happily be your editor, elaborator, or whatever. My strengths don't include writing intelligible English, but it needs doing. Vernon Schryver[EMAIL PROTECTED]
Re: Apology Re: Principles of Spam-abatement
On Wed, 17 Mar 2004, Ed Gerck wrote: Dean Anderson wrote: On Tue, 16 Mar 2004, Ed Gerck wrote: Dean Anderson wrote: On Tue, 16 Mar 2004, Ed Gerck wrote: What information theory says is that the probability of detecting spam is less than 100%. No, information theory doesn't say that at all. Sure it says, and that's why a spam filter will never be 100% effective. I guess we agreed on this before ;-) I think you must have missed my message noting our disagreement. http://www.ietf.org/mail-archive/ietf/Current/msg24213.html Let me make sure. You think then that a spam filter can be 100% efficient? If you do, please log off and go sell it. If you don't then I agree with you. No, that isn't what I said. You need to re-read the message. It is fairly clear. --Dean
Categorization of TCP/IP service provision types (was: Re: The right to refuse, was: Re: Principles of Spam-abatement) (FWD: I-D ACTION:draft-klensin-ip-service-terms-00.txt)
Last week's version of the spam discussions, led to an interesting (to me) side-discussion about what was, and was not, an Internet connection service. There have been discussions on and off for years (since before the User Services area was inactivated) about doing such a set of definitions. On my general theory that it is better to try to actually do something than it is to discuss forever how desirable it might be, I've hacked a preliminary document together and posted it as draft-klensin-ip-service-terms-00.txt. This clearly isn't finished, indeed, it is not much more than a skeleton with a few examples. It needs more work, probably additional categories, and more clarity about the categories that are there. If there is real interest in the subject, I'd like to see someone else take over the writing and editing. If there isn't any real, perhaps we can stop spending time discussing the subject. I-D announcement attached. john ---BeginMessage--- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Terminology for Describing Internet Connectivivy Author(s) : J. Klensin Filename: draft-klensin-ip-service-terms-00.txt Pages : 6 Date: 2004-3-17 As the Internet has evolved, many types of arrangements have been advertised and sold as 'Internet connectivity'. Because these may differ significantly in the capabilities they offer, the range of options, and the lack of any standard terminology, has cause considerable consumer confusion. This document provides a list of terms and definitions that may be helpful to providers, consumers, and, potentially, regulators in clarifying the type and character of services being offered. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-klensin-ip-service-terms-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username anonymous and a password of your e-mail address. After logging in, type cd internet-drafts and then get draft-klensin-ip-service-terms-00.txt. A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: [EMAIL PROTECTED] In the body type: FILE /internet-drafts/draft-klensin-ip-service-terms-00.txt. NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the mpack utility. To use this feature, insert the command ENCODING mime before the FILE command. To decode the response(s), you will need munpack or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with multipart MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://ftp.ietf.org/internet-drafts/draft-klensin-ip-service-terms-00.txt ---End Message---
Re: Apology Re: Principles of Spam-abatement
Dean, I'm not gonna feed the troll. The bottom line is that spam filters are not 100% effective and anti-spam protocols are not 100% effective either, in the same way that your car is not 100% fuel effective. The reason is pretty much the same. Thus, your indefatigable assertion that there are no technical solutions for spam strikes me as irrelevant. We all work with and improves things that will never be 100% effective. The good part of this is that we shan't run out of work ;-) If you don't agree with any of the above, pls email me in PVT. Cheers, Ed Gerck Dean Anderson wrote: On Wed, 17 Mar 2004, Ed Gerck wrote: Dean Anderson wrote: On Tue, 16 Mar 2004, Ed Gerck wrote: Dean Anderson wrote: On Tue, 16 Mar 2004, Ed Gerck wrote: What information theory says is that the probability of detecting spam is less than 100%. No, information theory doesn't say that at all. Sure it says, and that's why a spam filter will never be 100% effective. I guess we agreed on this before ;-) I think you must have missed my message noting our disagreement. http://www.ietf.org/mail-archive/ietf/Current/msg24213.html Let me make sure. You think then that a spam filter can be 100% efficient? If you do, please log off and go sell it. If you don't then I agree with you. No, that isn't what I said. You need to re-read the message. It is fairly clear. --Dean
Re: Apology Re: Principles of Spam-abatement
[EMAIL PROTECTED] (Ed Gerck) writes: Dean, I'm not gonna feed the troll. ... NOW you're not gonna feed the troll? where's the ...any more! ?? it does me no good to filter out postings from known whackjobs if you and others are just going to reply anyway, often including the very drivel that i'd avoided having to look at directly. please show some self-restraint. -- Paul Vixie
Re: Principles of Spam-abatement
On Wed, 17 Mar 2004, Doug Royer wrote: Dean Anderson wrote (in part): c) Work out what to do about relays and proxies, again to prevent man-in-the-middle DoS more than anything else. One site should not be able to generate mail that it forwards with fictitious headers and evil content so that it appears to come from some hapless but innocent network. Relays don't add ficticious headers, nor do they add evil content. They may place their (true) headers on top of ficticious headers. They cannot verify that the headers given are accurate. This is true of all relays, open or closed. Sounds like his first point - fix it so they are checkable. If I am going to relay for X number of domains, it seems reasonable that we share some kind of shared key or password so they the headers they pass me can be verified. The premise that relays add ficticious headers and evil content is wrong. But header checking would not be practical. It quickly becomes: I am going to relay for some domains. The domains I am going to relay for are unknown in advance (or very much in advance) because the customer may add new domains. Further, that customer may themselves relay for some number of unknown domains. The description I gave of reasons that RMX won't work also applies. You may have to relay for other domains. The problem is very similar to, but much, much larger than the BGP route registries' configuration databases. There are about 140,000 or so advertised network number prefixes, and providers change their routing to other providers relatively infrequently compared with end users. The Route registry, in principle, allows one to automatically generate router configurations based on the what routes might be advertized by which AS numbers. In practice, it hasn't been such a success, though it does have it's proponents. It sounds much better in theory than it does in practice. Trying to do the same for millions of domains would be impractical, since the routing of those domains is even less static than the network routes between service providers. At the end of this, all you find out is that spammers will stop using forged headers. But quite a lot of spam these days doesn't have any forged headers. Indeed, it seems that spammers/abusers have lost interest in adding forged headers, as they have lost interest in open relay abuse. There is a related point that the IP addresses in the forged headers appear to be chosen randomly. So some percentage of these will not be routed, and will not be allocated. One could easily implement a check which simply tested all the IP addresses in the headers for routability. Of course, spammers would stop picking addresses at random, and would simply start selecting random addresses from the route tables. Such a test is obviously not worth implementing. There is (1.0) legal spam and (2.0) illegal spam. Illegal spam can be (2.1) advertisements or (2.2) viruses. (1.0) Is most often traceable using the headers and content. This is getting easier to stop and there can be things done to make it easier - a computer parseable unsubscribe link and a standard protocol to unsubscribe. CAN-SPAM prescribed the use of unsubscription methods, and 56% of spammers were fully compliant in January, and 95% were partially compliant in January. I've been using the links on some spam from genuine spammers, (eg tekmailer.com). They've been providing a mail-to url and an http url for unsubscription. These are already computer parsable. However, the hard part is to distinguish the genuine spammers from the fake spammers. I've been able to do this in most cases by examining the headers and the company--genuine spammers won't have any forgeries at all, and looking up information on them will turn up the fact that they are a real company. Fake spammers have web sites, too, and their unsubscribe links result in further mail bombing. But so far I've been able to pick them out, as they have to fake something, else they'd be real. (2.1) Often is traceable by the content, and almost never by the headers. This isn't true. After the abuser has injected the message, the subsequent headers will be true. So abuse is traceable by the headers back to the SMTP injection point. Forged headers are always detectable, since they try to make one believe that mail was handled by a machine IP address that didn't actually handle the message. It is easy to see where the authentic recieved headers stop and the forged headers start. However, one can (and SpamCop does**) forward a complaint to the responsible party for each listed relay and domain. Those parties can then determine by looking at the message and their logs if their users were responsible for the message. If the message was injected by an open proxy, you can trace back to the open proxy. You may not be able to trace beyond that, but that isn't an SMTP protocol or relay issue.
Re: Apology Re: Principles of Spam-abatement
Did anyone expect professional behavior from someone who doesn't have an AUP on their own sites, someone who supports demonstrated abusers, someone who associates with court-proven liars, and someone who posts misleading information about their own legal experiences? I didn't. Clearly, technical competence does not equate to honesty and integrity. It also does not equate to professional conduct. And of course, those who lack intelligence to make sensible arguments have to resort to name-calling. I'm surprised it took this long to resort to name-calling. --Dean On 18 Mar 2004, Paul Vixie wrote: [EMAIL PROTECTED] (Ed Gerck) writes: Dean, I'm not gonna feed the troll. ... NOW you're not gonna feed the troll? where's the ...any more! ?? it does me no good to filter out postings from known whackjobs if you and others are just going to reply anyway, often including the very drivel that i'd avoided having to look at directly. please show some self-restraint.
Re: Apology Re: Principles of Spam-abatement
Well, you are the one trying to attribute statements that you agree with to me, even though I've made it clear that we don't agree, and why we don't agree. If you can't understand what your opponents position is, and what points you agree and disagree with, there is no point in discussing it, until you do. --Dean On Thu, 18 Mar 2004, Ed Gerck wrote: Dean, I'm not gonna feed the troll. The bottom line is that spam filters are not 100% effective and anti-spam protocols are not 100% effective either, in the same way that your car is not 100% fuel effective. The reason is pretty much the same. Thus, your indefatigable assertion that there are no technical solutions for spam strikes me as irrelevant. We all work with and improves things that will never be 100% effective. The good part of this is that we shan't run out of work ;-) If you don't agree with any of the above, pls email me in PVT. Cheers, Ed Gerck Dean Anderson wrote: On Wed, 17 Mar 2004, Ed Gerck wrote: Dean Anderson wrote: On Tue, 16 Mar 2004, Ed Gerck wrote: Dean Anderson wrote: On Tue, 16 Mar 2004, Ed Gerck wrote: What information theory says is that the probability of detecting spam is less than 100%. No, information theory doesn't say that at all. Sure it says, and that's why a spam filter will never be 100% effective. I guess we agreed on this before ;-) I think you must have missed my message noting our disagreement. http://www.ietf.org/mail-archive/ietf/Current/msg24213.html Let me make sure. You think then that a spam filter can be 100% efficient? If you do, please log off and go sell it. If you don't then I agree with you. No, that isn't what I said. You need to re-read the message. It is fairly clear. --Dean
Re: Principles of Spam-abatement
Paul, PV but i'll bet my bank has ways of trusting your bank. ... PV if your bond is only $30/year then i probably wouldn't trust you no matter PV what my bank told me about your insurance company or what your insurance It depends upon what is being trusted and what the incentives are for violating the trust. Some trust does require a large, enforceable penalty for violations. Other trust can work quite well based only on history. A bank might give out small, unsecured loans based on that history, but might require a big loan to be secured. I might be willing to take a first-first email from someone who has a history of not-spamming, without requiring that they suffer a penalty (other than my reporting them to the third-party trust agency) if they violate that. d/ -- Dave Crocker dcrocker-at-brandenburg-dot-com Brandenburg InternetWorking www.brandenburg.com Sunnyvale, CA USA tel:+1.408.246.8253
Re: Principles of Spam-abatement
I might be willing to take a first-first email from someone who has a history of not-spamming, without requiring that they suffer a penalty (other than my reporting them to the third-party trust agency) if they violate that. no, you would not. dave, you're not thinking of this as information warfare. you have to. every time you consider a plan, ask yourself where are the loopholes? or how can it be abused? (and, what if 6 billion people did this?) identities without history will be a dime a dozen, or cheaper. spammers with no history could trample your privacy all day long if you allowed it. accepting incoming communication from someone the world has no hooks into is off the table. allowing the world to have its hooks in someone whose identity you don't know (and could never find out) has to continue to work, but anonymity and homelessness are not the same thing.
Re: Principles of Spam-abatement
From: Paul Vixie ... identities without history will be a dime a dozen, or cheaper. spammers with no history could trample your privacy all day long if you allowed it. accepting incoming communication from someone the world has no hooks into is off the table. allowing the world to have its hooks in someone whose identity you don't know (and could never find out) has to continue to work, but anonymity and homelessness are not the same thing. Stated that way, but perhaps with an unintended interpretation, I agree. Every mail sender is hooked by an entity that the mail receiver knows and that has its own reputation that can be checked today. The ISPs that own the IP addresses in every IP packet that Ralsky sends have their hooks in Ralsky. You can decide whether the implicit no-spam guarantee from that hooking agency is sufficient by checking your own blacklist or the blacklists of others via DNS or BGP. All of the possible good and bad aspects of any possible trust or reputation system are already present in the current system. - If you say that you can't trust ISPs to check that a new customer is not Al Ralsky in disguise or one of his proxies, then you must say the same about any other organization. - If you say that ISPs cannot check the reputation of new customers for a $30/month account, then you must say the same about any other organization. - If you say that you cannot trust ISPs to terminate the accounts of spammers, then you must say that you cannot trust any other outfit to revoke the PKI cert or other assurance for spammers. - If you trust some of those other outfits to revoke their virtual letters of introduction and recommendation, than you must be willing to trust some ISPs to do the same and terminate accounts. - If you say that third party organization could assure you that a mail sender is not a spammer, then you must agree that an ISP could check with that organization before adding a password to a RADIUS server or or turn on a DSLAM, and that an ISP could terminate an account when that third party revokes is assurance. - You can be anonymous on the Internet only if your ISP protects you. No one is homeless on the Internet. The SYN-ACK for your SYN to port 25 must get back to your source IP address home at your ISP. The connection between you, the spam or mail target, and the ISP that has its hooks in the mail sender is better than any PKI or crypto related system could possibly be. It is not only much cheaper than anything Microsoft/Yahoo/AOL/Verisign would sell, but technically more reliable. IP address spoofing was practically impossible for spam even before RFC 1948 and related defenses, because it was too hard and unreliable if you need to make 10,000,000 successfully spoofed ISN predicted TCP connections per day. On the other hand, we all knew even before the bogus Microsoft Corporation certs or the discovery that those bogus certs could not be revoked that commercial PKI is eyewash. If you believe that reputation or trust systems might help the spam problem, then the only room for improvement is in the trust query protocol. DNS is a screw driver being used as a hammer in DNS blacklists. However, this is merely a matter of optimization or elegance. Vernon Schryver[EMAIL PROTECTED]
Re: Principles of Spam-abatement
On 3/17/2004 9:33 AM, Paul Vixie wrote: identities without history will be a dime a dozen, or cheaper. spammers with no history could trample your privacy all day long if you allowed it. accepting incoming communication from someone the world has no hooks into is off the table. Not applicable to sales@ or emergency@ type mailboxes. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Principles of Spam-abatement
Eric A. Hall wrote: On 3/17/2004 9:33 AM, Paul Vixie wrote: accepting incoming communication from someone the world has no hooks into is off the table. Not applicable to sales@ or emergency@ type mailboxes. Why? Should someone arrive at your Sales or Emergency window in your office, naked, what would you do? Off the table is IMO the correct action for an email address that is naked -- i.e., that has no verification information. Note that this is nothing new. We already do this with IP numbers. If you send me a packet with a non-verifiable source IP there will be no communication possible. Why should it be different with email addresses? Cheers, Ed Gerck
Re: Principles of Spam-abatement
[EMAIL PROTECTED] (Vernon Schryver) writes: ... If you believe that reputation or trust systems might help the spam problem, then the only room for improvement is in the trust query protocol. DNS is a screw driver being used as a hammer in DNS blacklists. However, this is merely a matter of optimization or elegance. so, it's possible that there is some overlap between my universal privacy goals, and my support for the long-awaited dnssec extensions, and my support for the procket/juniper/cisco/paix/nasa/verio/shepfarm/isc multicast deployment effort. -- Paul Vixie
Re: Principles of Spam-abatement
Vernon Schryver wrote: If you believe that reputation or trust systems might help the spam problem, then the only room for improvement is in the trust query protocol. DNS is a screw driver being used as a hammer in DNS blacklists. However, this is merely a matter of optimization or elegance. I had some preliminary conversations with blacklist operators about this. There wasn't any interest in making a better protocol, but some people did expressed a need to document the existing one. Yakov
Re: Apology Re: Principles of Spam-abatement
On Tue, 16 Mar 2004, Ed Gerck wrote: Dean Anderson wrote: On Tue, 16 Mar 2004, Ed Gerck wrote: What information theory says is that the probability of detecting spam is less than 100%. No, information theory doesn't say that at all. Sure it says, and that's why a spam filter will never be 100% effective. I guess we agreed on this before ;-) I think you must have missed my message noting our disagreement. http://www.ietf.org/mail-archive/ietf/Current/msg24213.html Now, you may want to refer to that mythical element, the 'spam-free' protocol, a protocol that an information theory model says cannot be built. I guess we also agreed before that a 'spam-free' protocol is impossible. The IETF should not attempt to develop it. Thus, in asking for IETF technical solutions for spam, it is obvious that I do not mean spam filters or 'spam-free' protocols. We would all be very happy with a protocol that is almost spam-free -- in fact, I believe we would be quite happy with 90% at this time. Me thinks we don't need 100% ;-) An IETF technical solution to reduce spam is doable. Your comment on 'spam-free' is useful-free ;-) The IETF cannot reduce spam either. Protocol changes are simply gratiutious. One might say that there is very little spam on X.400 mail systems. But it is simply because spammers aren't interested, not because X.400 has some special immunity. Spammers will simply adapt to any gratuitous change. At best, only a temporary reduction would be obtained, until the spammers adapt. After they adapt, there is no reduction. However, I think there are things that show some promise that might be harder to adapt to, such as automated text summarization, bayesian filters, mail agents that filter on the user's interest in the message subject, and such. I think these are worth pursuing, but these are not subjects for the IETF. Further, there are still inverse methods for spammers, so even these will simply be temporary. But I think the benefit of intelligent agents and summarization and interest filtering could be very beneficial in filtering even non-spam mail. Ages ago, managers had secretaries filter there postal mail and phone calls. I'd love to have a 'secretary' filter my email, so that I could subscribe to noisy lists and see only the messages that I was interested in. But this is technology that isn't a protocol, nor does it seem to be in need of a protocol, so there is little or no reason for the IETF to be involved. No, it is quite useful: The IETF can do nothing to prevent spam. ;-) this mantra is becoming a spam. Or perhaps it is the mantra that the IETF can do something to reduce spam. What interests the IETF are technical spam solutions, for example, that would prevent email that comes from unidentifiable or rogue senders/MTAs to be ever received. The only thing that can acheive this is to turn off the computer. No, it's a matter of degree. Even if not all spam is preventable, preventing email address spoofing (even to a degree) would have a range of benefits. For example, I would no longer receive those undelivered messages for email that I purportedly sent, but actually never did. And people receiving email from me could actually trust to some extent the outcome of their filters. And, to be clear, I'm not talking about PKI. Actually, I want to receive those bounced messages. Otherwise I don't know if someone is out there trying to abuse me. Often, the perpetrator can be identfied from these bounce messages, since they usually include the original message and its mail headers, which give an IP address and a time of use. But it is easy to delete messages from Mailer Daemon if you don't want them. The problem here is to distinguish the real you from the not-real you. Or rather, to distinguish the unauthorized not-real you from both the authorized not-real-you and the real-you. Real users use relays. Real users also use agents, like cron jobs to send email. How do you know the cron job is not a spammer? It might be abuse. It might not be abuse. We don't know until we check on it. There is no way to avoid this check. RMX can't work, because real users need to be able to use a wide range of relays, which depends on their physical location as well as their arrangements for outsourcing, as well as the service offerings of multiple providers. For example, Av8 Internet provides relay services for users of earthlink, because those users have leased line services from Av8, but email services from Earthlink, and earthlink doesn't do relay service outside its IP address space. How is the relay to know if the message is really from you or not really from you? Password (or per-user account) style authentication (such as SMTP AUTH) hasn't had any effect on spam, and it doesn't scale well, and isn't widely supported. Passwords can be stolen by viruses, or by disgruntled users if they are well-known. If you
Re: Principles of Spam-abatement
On 3/17/2004 10:47 AM, Ed Gerck wrote: Eric A. Hall wrote: Not applicable to sales@ or emergency@ type mailboxes. Why? Should someone arrive at your Sales or Emergency window in your office, naked, what would you do? uh, public nudity is (mostly) criminal, so not a good analogy, although comparisons to a no shirt, no shoes, no service policy statement would be getting there. A better analogy is with new checking accounts. Many places won't accept checks numbered below 1000, since they indicate that the account has not established a track record. Other places will accept the checks after verification, other places will accept them with thumbprint or some other identifier. In all these cases, the organization is able to determine its risk limits and act accordingly. I'm not going to get sucked into this endless debate, but it is equally tyrannical to require everyone use some kind of hard trust as it is to require everyone use no trust (what we are moving away from, in blobbish fashion and pace). There must be consideration for exceptions; the swimming pool snack bar probably cannot enforce a no shirt... policy. Property rights (of which I am a big advocate) work because they can be selected and enforced at the owner's scale; people can put up no trespassing or no solicitation or no hunting or no shirt... signs to advertise their chosen policies. The same kind of mechanism is needed for property protection to work in networking as well. Note that this is nothing new. We already do this with IP numbers. If you send me a packet with a non-verifiable source IP there will be no communication possible. Why should it be different with email addresses? Verification is different from trust. My position is that you need to be able to validate and verify before you can successfully apply any kind of trust (otherwise the trust is meaningless). Paul's message that I replied to was specifically describing a minimum threshold of trust (it was akin to the no checks below #1000 position). -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Principles of Spam-abatement
When you cannot trust people like Paul Vixie and Bill Manning to terminate sites that are engaging in plainly obvious and egregious defamation and harrassment claiming that IP address space is hijacked when a quick check of the registry indicates that it isn't, then you also can't trust them to be in charge of a trust system. They are people who have asked others to trust them. They are people who have said that trust is important. They are people who have said ISP's should have AUP's, and should enforce them against abusive users. The world certainly has its hooks into them. Yet, we find that they are associated with court-proven liars and other disreputable people, who have their own spiteful agenda, and they aren't even embarrassed by that finding. We find them misleading their subscribers, for example by blocking companies outside of their criteria, or just completely falsely for spite. This type of thing hasn't happened just once, but many times, by many blacklist operators. Quite obviously, we can't have a trust based system, because the anti-spammers are even less trustworthy than the spammers. --Dean On Wed, 17 Mar 2004, Vernon Schryver wrote: From: Paul Vixie ... identities without history will be a dime a dozen, or cheaper. spammers with no history could trample your privacy all day long if you allowed it. accepting incoming communication from someone the world has no hooks into is off the table. allowing the world to have its hooks in someone whose identity you don't know (and could never find out) has to continue to work, but anonymity and homelessness are not the same thing. Stated that way, but perhaps with an unintended interpretation, I agree. Every mail sender is hooked by an entity that the mail receiver knows and that has its own reputation that can be checked today. The ISPs that own the IP addresses in every IP packet that Ralsky sends have their hooks in Ralsky. You can decide whether the implicit no-spam guarantee from that hooking agency is sufficient by checking your own blacklist or the blacklists of others via DNS or BGP. All of the possible good and bad aspects of any possible trust or reputation system are already present in the current system. - If you say that you can't trust ISPs to check that a new customer is not Al Ralsky in disguise or one of his proxies, then you must say the same about any other organization. - If you say that ISPs cannot check the reputation of new customers for a $30/month account, then you must say the same about any other organization. - If you say that you cannot trust ISPs to terminate the accounts of spammers, then you must say that you cannot trust any other outfit to revoke the PKI cert or other assurance for spammers. - If you trust some of those other outfits to revoke their virtual letters of introduction and recommendation, than you must be willing to trust some ISPs to do the same and terminate accounts. - If you say that third party organization could assure you that a mail sender is not a spammer, then you must agree that an ISP could check with that organization before adding a password to a RADIUS server or or turn on a DSLAM, and that an ISP could terminate an account when that third party revokes is assurance. - You can be anonymous on the Internet only if your ISP protects you. No one is homeless on the Internet. The SYN-ACK for your SYN to port 25 must get back to your source IP address home at your ISP. The connection between you, the spam or mail target, and the ISP that has its hooks in the mail sender is better than any PKI or crypto related system could possibly be. It is not only much cheaper than anything Microsoft/Yahoo/AOL/Verisign would sell, but technically more reliable. IP address spoofing was practically impossible for spam even before RFC 1948 and related defenses, because it was too hard and unreliable if you need to make 10,000,000 successfully spoofed ISN predicted TCP connections per day. On the other hand, we all knew even before the bogus Microsoft Corporation certs or the discovery that those bogus certs could not be revoked that commercial PKI is eyewash. If you believe that reputation or trust systems might help the spam problem, then the only room for improvement is in the trust query protocol. DNS is a screw driver being used as a hammer in DNS blacklists. However, this is merely a matter of optimization or elegance. Vernon Schryver[EMAIL PROTECTED]
Re: Principles of Spam-abatement
On Wed, 17 Mar 2004, Vernon Schryver wrote: (A bunch of beautifully said things that I agree with fully) If you believe that reputation or trust systems might help the spam problem, then the only room for improvement is in the trust query protocol. DNS is a screw driver being used as a hammer in DNS blacklists. However, this is merely a matter of optimization or elegance. The one other place that I think there COULD be room for improvement is to make the process of identifying sites that are originating spam or viruses more rapid and automatic, and to create a better/more formal set of rules responding to a site (or an entire SP subnetwork) postmaster. Such work might actually spell out all the steps between reporting and being blacklisted. Right now I think it is safe to say that most users don't know anything about postmaster addresses. Nor do they know how to read a mail header (or they may be using a MUA that doesn't present the full header even as an option). Finally, complaining about spam takes time, especially when you have a lot and have to write an actual message about each one one at a time. Consequently 99+% of all users are effectively prevented from reporting spam to the hosting SP of the originator by a mix of inertia, ignorance, and inability. No wonder the SPs feel that they can ignore the problem -- instead of a million pieces of spam generating a million complaints and burying the poor postmaster admins of the enabling SP in an emergency consisting of rapidly filling mail spool files and writing procmail rules to handle them all so they can extract real communications from all the spam complaints, they get ten reports of spam, maybe, from ten hardnosed old timers who can read a mail header and care enough to report them (maybe because they make it through their filters). I no longer bother -- if I have to generate a complaint message per piece that my filters identify, I'll never get ANY work done. If every ten pieces of spam sent out of an SPs network -- even every 100 pieces -- generated a complaint message to postmaster with headers laid out that clearly identified the offending host/client, I think that it would provide SPs with a real incentive, AND the tools, to address the problem. I don't know if this is a problem that could be addressed in protocol, but it might be. I can think of several things that an MTA (or MUA) might do to facilitate a spam-bounce. a) Preparse the header so that the entire delivery path is the primary content of the message, with the message itself added (header intact) as an attachment. b) Return the complaint as mail to postmaster of the originating network with a special error code that would allow it to be counted and digested easily. One doesn't want to create a new kind of DoS attack on postmaster, and making it easy and automatic to return a complaint COUNT of some sort on otherwise identical content can help prevent that while making it easier for SP admins to deal with mounting complaint levels. c) Work out what to do about relays and proxies, again to prevent man-in-the-middle DoS more than anything else. One site should not be able to generate mail that it forwards with fictitious headers and evil content so that it appears to come from some hapless but innocent network. d) Take steps to ensure that SPs run a postmaster address, and maybe come up with things like Jeff Chase was proposing to continuously measure their responsiveness to spam/virus-class bounce messages and globally blacklist the worst (least responsive) offending SPs. Etc. Right now enabling SPs are insulated from any kind of RFC-based responses or complaints about spam because MUA's and MTA's have no predefined protocol for generating such a response in a constructive way. Most complaints/bounces that are automatically generated by antivirus software or reported by humans (I've read plenty of both:-( are hopeless and de facto useless without several rounds of communications, and sometimes not even then: the humans don't even know what a mail header IS and often have no way of knowing or suspecting that the From address is bogus or sending in the real header so it can be parsed by the SP postmaster. Antivirus software developers should know better (damn it!) but even THEY don't bother to parse the header or include the header in the stupid bounces they generate, or validate any sort of correspondance between originating host and From address. So even though one could argue that adding a real protocol layer for a preformatted, standardized, spam/virus bounce is not strictly necessary because all the information is already IN the header, doing it anyway might codify and standardize a complaint so that the complaint always contains the essential information and so that a complaint to the right target is easy to generate (can even be generated automatically). It could then guide the development of compliant tools that can deal with this for
Re: Principles of Spam-abatement
Vernon Schryver [EMAIL PROTECTED] wrote: All of the possible good and bad aspects of any possible trust or reputation system are already present in the current system. Not so. - If you say that you can't trust ISPs to check that a new customer is not Al Ralsky in disguise or one of his proxies, then you must say the same about any other organization. ISPs operate in a _very_ different business environment than, say, UNICEF. - If you say that ISPs cannot check the reputation of new customers for a $30/month account, then you must say the same about any other organization. ISPs offering $30-per-month service are very likely losing money (and worrying who to lay off next). Your bank, OTOH, is probably doing nicely on less than $30-per-month service charges. Also, some ISPs have no reason to worry much about their reputation, because they have in effect a government-mandated near-monopoly. - If you trust some of those other outfits to revoke their virtual letters of introduction and recommendation, then you must be willing to trust some ISPs to do the same and terminate accounts. Ah, yes, but _which_ ISPs? - If you say that third party organization could assure you that a mail sender is not a spammer, then you must agree that an ISP could check with that organization before adding a password to a RADIUS server or or turn on a DSLAM, and that an ISP could terminate an account when that third party revokes is assurance. The first part is actually true: I think we'd actually see that if such third-party services come into common use. :^) The second part (terminating) is not true, IMHO. There's a real danger of getting sued for that, not to mention the loss of revenue. However, donning Pangloss's hat, I do hope that they might activate some port-25 bandwidth-limiting. ;^) If you believe that reputation or trust systems might help the spam problem, then the only room for improvement is in the trust query protocol. DNS is a screw driver being used as a hammer in DNS blacklists. Current DNS blacklists are, IMHO, trying to do an impossible job. However, this is merely a matter of optimization or elegance. I disagree: it's a matter of biting off more than you can chew. -- John Leslie [EMAIL PROTECTED]
Re: Principles of Spam-abatement
Hello folks, Eric A. Hall wrote: uh, public nudity is (mostly) criminal Too bad! Actually, what is often proscribed is lewd behavior, and nudity is often wrongly considered lewd. Anyway it's awfully difficult to really reconcile nudity with criminal behavior. Regards, Charlie P.
Re: Principles of Spam-abatement
On Wed, 17 Mar 2004, Eric A. Hall wrote: A better analogy is with new checking accounts. Many places won't accept checks numbered below 1000, since they indicate that the account has not established a track record. Other places will accept the checks after verification, other places will accept them with thumbprint or some other identifier. In all these cases, the organization is able to determine its risk limits and act accordingly. Which is really pretty silly, right? Since anybody will print you checks that start with any number you like, completely legally. In fact, you can print your own checks with any number(s) you like, completely legally, as long as the bank information at the bottom is there and is correct and you actually own the account in question and don't commit fraud or pass bad checks. This kind of silly response is no obstacle to a criminal or spammer; it is merely an inconvenience (a pain in the ass) to the innocent. It also leaves one with all sorts of catch-22 problems -- one cannot get a track record until one is let onto the track, and one cannot get onto the track without a track record. Besides, this is all talking about IP numbers, right, since we all AGREED that user identies were transient artifacts and impossible to regulate. In the checking account metaphor above, on the internet I can print a new check with whatever numbers you like for each and every transaction, and back it up with a shiny new driver's license and any other identification tokens you require unless and until you create a huge government bureaucracy to regulate it and harsh laws to punish abuse. Sort of like the ones we have for real driver's licenses and checking accounts and human identities. Banking (and other human metaphors) are not correct for addressing IP number trust. It's more like can you trust the current residents of this neighborhood or that house down the street...when you never get to see them, only their masks. And IF we're talking about IP addresses, we can pretty much stop talking. As Vernon has repeatedly pointed out, trust-like facilities at the IP level are either ALREADY THERE and proving to be moderately ineffective against spam or run square against the economics and realities of the SP business. We cannot do anything silly like not trust a new IP number assigned by an SP to a new customer until they have a track record. Trusted has to be the default or the Internet and a variety of business become impossible and incredibly burdensome on the innocent (far more so than spam). But I don't care if you agree -- as you note, you can not trust any parts of IP space you choose according to any criterion you select, within your own hosts or networks. Just don't blame anybody else when things stop working because you've punched a hole through a path to a critical service or human. Note that this is nothing new. We already do this with IP numbers. If you send me a packet with a non-verifiable source IP there will be no communication possible. Why should it be different with email addresses? Verification is different from trust. My position is that you need to be able to validate and verify before you can successfully apply any kind of trust (otherwise the trust is meaningless). Paul's message that I replied to was specifically describing a minimum threshold of trust (it was akin to the no checks below #1000 position). You have to be able to quantify trust as well, in order to be able to use it as a filtering criterion. I fear that your metaphor is exact -- it is NO more difficult for a spammer to achieve whatever level of trust is required for acceptance for long enough to spew than it is for me to ask the bank to start the checks for my brand new checking account at #2000 since of course some merchants won't take them otherwise. Or going home and printing some new ones. Somebody (Dean?) pointed out that if you can really solve the problem of trust at the electronic level, scalably and more or less for zero marginal cost, you're missing the real point. These are the SAME problems that are incredibly difficult to solve in the financial industry where the penalties are large and expensive, laws that severely punish identity theft artists and check forgers are vigorously enforced, and where instruments for reasonably reliably affirming identity (photo drivers' licenses, passports, birth certificates all abound and are tightly constrained by law and expensive government agencies and services. It's hard to trust even paper money, let alone that some stranger is who they assert themselves to be. In that sense it is an excellent milieu to look for metaphors to the network/spam/identity problems, just as paper spam and phone spam are also good places. If you can solve one, you can solve the other IF you are willing to pay similar costs. So next time anyone wants to advance a human-scale metaphor for a trust model, please a) ensure that it actually is
Re: Principles of Spam-abatement
From: Paul Vixie [EMAIL PROTECTED] If you believe that reputation or trust systems might help the spam problem, then the only room for improvement is in the trust query protocol. DNS is a screw driver being used as a hammer in DNS blacklists. However, this is merely a matter of optimization or elegance. so, it's possible that there is some overlap between my universal privacy goals, and my support for the long-awaited dnssec extensions, and my support for the procket/juniper/cisco/paix/nasa/verio/shepfarm/isc multicast deployment effort. DNSSEC would be a Good Thing(tm) on its own merits, but I don't see any direct connection between it and a replacement for DNS blacklists. Of course a replacement would start without reasonable authentication. If you insist on using DNS screwdrivers as SMTP authorization hammers, then DNSSEC blacklists would be a minor improvement. DNS has the wrong sorts of caching as well as the wrong sort of data for a reputation database. You want answers better than 32 bit number (PTR RR) or an ASCII string (TXT RRT). I don't see what multicast has much to do with my SMTP server asking my chosen (and hired) clearinghouse about the reputation of the owner the IP address of an SMTP client. Some sort of anycast might be a good optimization. I guess anycasting can be seen as a form of multicasting. Is that what you mean? ] From: Yakov Shafranovich [EMAIL PROTECTED] ] I had some preliminary conversations with blacklist operators about ] this. There wasn't any interest in making a better protocol, but some ] people did expressed a need to document the existing one. People with working code and large customers bases rarely choose to replace a servicable solution like the current DNS blacklist kludge with a proper solution, no matter how much more elegant. Replacing the DNS blacklist kludge with something better today would be little more than arranging the deck chairs. What's needed is to patch the hole in the hull, or for more ISPs to do as Earthlink has done in recent years and get serious about dealing with spam. Earthlink is far from perfect, but they are far better than they were and far, far better than other outfits. For example, as far as I can tell, today an SMTP connection from Comcast is likely to be carrying spam, while a connection from Earthlink probably isn't. If you don't have your own traps, see the numbers at http://www.senderbase.org/ or the better but less immediate numbers at http://spamhaus.org/ } From: Robert G. Brown [EMAIL PROTECTED] } ... } The one other place that I think there COULD be room for improvement is } to make the process of identifying sites that are originating spam or } viruses more rapid and automatic, and to create a better/more formal set } of rules responding to a site (or an entire SP subnetwork) postmaster. } Such work might actually spell out all the steps between reporting and } being blacklisted. I strongly disagree. There is and can be nothing better than the IP address of the SMTP client for identifying the orgin of a mail message. Some will object that's not the origin, but they're generally repeating the nonsense and lies of ISPs trying to duck blaim for supporting spammers. The practical origin of a paper letter is wherever the postals service, FedEx, etc. accepts it, no matter whether you wrote it while standing in the post office, at home, at work, or in an airplaine 35,000 feet above practically unknowable real estate. Yes, I've heard about UUCP, SMTP relays, smarthosts, and so forth and so on. As far as your SMTP server is concerned, a good, sufficient, and necessary definition of the origin of a mail message is the IP address of the sending SMTP client. It doesn't matter whether the sending IP address is an open proxy on a Comcast network, a system in China, or Dell Computers' newsletter senders. The IP address as good as anything else could be, and already available. It's only defect is that it makes ISPs responsible for taking Ralsky's money. } If every ten pieces of spam sent out of an SPs network -- even every 100 } pieces -- generated a complaint message to postmaster with headers laid } out that clearly identified the offending host/client, I think that it } would provide SPs with a real incentive, AND the tools, to address the } problem. I used to say that, but then I saw that even (or especially) the worst ISPs can figure out how to connect postmaster@ to /dev/null or to an autoresponding ignorebot that lies about the responsibility of the ISP. | From: John Leslie [EMAIL PROTECTED] | - If you say that you can't trust ISPs to check that a new customer |is not Al Ralsky in disguise or one of his proxies, then you must |say the same about any other organization. | |ISPs operate in a _very_ different business environment than, say, | UNICEF. Possibly true but certainly irrelevant. | - If you say that ISPs cannot check the reputation of new customers |
Re: Principles of Spam-abatement
On Wed, 17 Mar 2004, Robert G. Brown wrote: a) Preparse the header so that the entire delivery path is the primary content of the message, with the message itself added (header intact) as an attachment. This is true now. Many people don't know how to parse the headers, but it obeys a specific syntax and is machine parseable. b) Return the complaint as mail to postmaster of the originating network with a special error code that would allow it to be counted and digested easily. One doesn't want to create a new kind of DoS attack on postmaster, and making it easy and automatic to return a complaint COUNT of some sort on otherwise identical content can help prevent that while making it easier for SP admins to deal with mounting complaint levels. This is possible now, and SpamCop does this. The problem with SpamCop is that they alter the message, making it useless. SpamCop complaints are routinely deleted as a result. I usually forward them on to customers with an FYI that we don't consider such to be a valid complaint, but they may want to be aware of what someone said. c) Work out what to do about relays and proxies, again to prevent man-in-the-middle DoS more than anything else. One site should not be able to generate mail that it forwards with fictitious headers and evil content so that it appears to come from some hapless but innocent network. Relays don't add ficticious headers, nor do they add evil content. They may place their (true) headers on top of ficticious headers. They cannot verify that the headers given are accurate. This is true of all relays, open or closed. Proxies are another story. I don't know of any genuine reasons to run open proxies, though closed proxies (web caches) are clearly useful. I don't know of anyone claiming they are useful. But neither does that mean they have no use. However, as a service provider, I would say this much: If a customer found a useful reason to have an open proxy, then I would only insist that they keep logs of its use. This is easy to place in a contract or AUP. d) Take steps to ensure that SPs run a postmaster address, and maybe There is already a BCP for this. Rarely is this a problem. come up with things like Jeff Chase was proposing to continuously measure their responsiveness to spam/virus-class bounce messages and globally blacklist the worst (least responsive) offending SPs. Etc. How would you define responsiveness? Does it mean getting an auto-responder message? Does it mean getting a message saying something had been done? You cannot give out certain information about customers. Basically, all you can do is send an auto-responder message and a notice that the ticket was closed. That doesn't indicate what happened, nor does it indicate who the spammer was, or if the ISP agreed they were a spammer. Sometimes the action is obvious if, say, a website disappears. But how do you know they took action against a dialup customer? You can't. Continuous measurement is the same as a DOS attack. A ping flood is a continous measurement of the bandwidth available and its responsiveness. That's why there is a -f option to ping. Unauthorized measurements are illegal. Right now enabling SPs are insulated from any kind of RFC-based responses or complaints about spam because MUA's and MTA's have no predefined protocol for generating such a response in a constructive way. ??? I'm not sure what you mean. By the time you -read- a spam, it is delivered, and the SMTP protocol has long since finished. Spam isn't the only kind of abuse that an ISP responds to. The abuse@isp works pretty well, since you can forward the complained-of message. There are some things I'd like MUA's to do, such as include the whole headers(some MUA's do, some MUA's don't), but that isn't an RFC issue, either. Most complaints/bounces that are automatically generated by antivirus software or reported by humans (I've read plenty of both:-( are hopeless and de facto useless without several rounds of communications, and sometimes not even then: the humans don't even know what a mail header IS and often have no way of knowing or suspecting that the From address is bogus or sending in the real header so it can be parsed by the SP postmaster. Antivirus software developers should know better (damn it!) but even THEY don't bother to parse the header or include the header in the stupid bounces they generate, or validate any sort of correspondance between originating host and From address. Yes, it would be good to send the entire headers. But users should know that the from: header can be forged. They should also know some other things about email and the internet, such as don't open attachments you aren't expecting. If you get an unexpected attachment, ask the person if they sent it. This is an education problem. --Dean
Re: Apology Re: Principles of Spam-abatement
Dean Anderson wrote: On Tue, 16 Mar 2004, Ed Gerck wrote: Dean Anderson wrote: On Tue, 16 Mar 2004, Ed Gerck wrote: What information theory says is that the probability of detecting spam is less than 100%. No, information theory doesn't say that at all. Sure it says, and that's why a spam filter will never be 100% effective. I guess we agreed on this before ;-) I think you must have missed my message noting our disagreement. http://www.ietf.org/mail-archive/ietf/Current/msg24213.html Let me make sure. You think then that a spam filter can be 100% efficient? If you do, please log off and go sell it. If you don't then I agree with you. Cheers, Ed Gerck
Re: Principles of Spam-abatement
[EMAIL PROTECTED] (Vernon Schryver) writes: ... but I don't see any direct connection between [DNSSEC] and a replacement for DNS blacklists. i know. but you asked about trust query protocols, not about blackhole lists. as the creator of the first blackhole list, let me just say, they don't scale. I don't see what multicast has much to do with my SMTP server asking my chosen (and hired) clearinghouse about the reputation of the owner the IP address of an SMTP client. Some sort of anycast might be a good optimization. I guess anycasting can be seen as a form of multicasting. Is that what you mean? no. for one thing, this is not (at heart) an smtp problem. more later. -- Paul Vixie
Re: Principles of Spam-abatement
Dean Anderson wrote (in part): c) Work out what to do about relays and proxies, again to prevent man-in-the-middle DoS more than anything else. One site should not be able to generate mail that it forwards with fictitious headers and evil content so that it appears to come from some hapless but innocent network. Relays don't add ficticious headers, nor do they add evil content. They may place their (true) headers on top of ficticious headers. They cannot verify that the headers given are accurate. This is true of all relays, open or closed. Sounds like his first point - fix it so they are checkable. If I am going to relay for X number of domains, it seems reasonable that we share some kind of shared key or password so they the headers they pass me can be verified. Most complaints/bounces that are automatically generated by antivirus software or reported by humans (I've read plenty of both:-( are hopeless and de facto useless without several rounds of communications, and sometimes not even then: the humans don't even know what a mail header IS and often have no way of knowing or suspecting that the From address is bogus or sending in the real header so it can be parsed by the SP postmaster. Antivirus software developers should know better (damn it!) but even THEY don't bother to parse the header or include the header in the stupid bounces they generate, or validate any sort of correspondance between originating host and From address. Yes, it would be good to send the entire headers. But users should know that the from: header can be forged. They should also know some other things about email and the internet, such as don't open attachments you aren't expecting. If you get an unexpected attachment, ask the person if they sent it. This is an education problem. There is (1.0) legal spam and (2.0) illegal spam. Illegal spam can be (2.1) advertisements or (2.2) viruses. (1.0) Is most often traceable using the headers and content. This is getting easier to stop and there can be things done to make it easier - a computer parseable unsubscribe link and a standard protocol to unsubscribe. (2.1) Often is traceable by the content, and almost never by the headers. Content filters and blacklists of some kind can catch these and throw them in the trash or hang-up when the content matches a URL that somehow blacklisted. (2.2) Is for a virus scanner to catch and is almost never traceable. There are things the IETF can do to help with the spam problem (1.0). -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)520-4044 http://Royer.com/People/Doug | Fax:(866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: Principles of Spam-abatement
On Wed, 17 Mar 2004, Vernon Schryver wrote: } From: Robert G. Brown [EMAIL PROTECTED] } ... } The one other place that I think there COULD be room for improvement is } to make the process of identifying sites that are originating spam or } viruses more rapid and automatic, and to create a better/more formal set } of rules responding to a site (or an entire SP subnetwork) postmaster. } Such work might actually spell out all the steps between reporting and } being blacklisted. I strongly disagree. There is and can be nothing better than the IP address of the SMTP client for identifying the orgin of a mail message. Some will object that's not the origin, but they're generally repeating the nonsense and lies of ISPs trying to duck blaim for supporting spammers. The practical origin of a paper letter is wherever the postals service, FedEx, etc. accepts it, no matter whether you wrote it while standing in the post office, at home, at work, or in an airplaine 35,000 feet above practically unknowable real estate. Yes, I've heard about UUCP, SMTP relays, smarthosts, and so forth and so on. As far as your SMTP server is concerned, a good, sufficient, and necessary definition of the origin of a mail message is the IP address of the sending SMTP client. It doesn't matter whether the sending IP address is an open proxy on a Comcast network, a system in China, or Dell Computers' newsletter senders. The IP address as good as anything else could be, and already available. It's only defect is that it makes ISPs responsible for taking Ralsky's money. I AGREE with this. There is a bit of difficulty associated with just which IP address in a chain of delivery hops is the actual point of origin, but at least at this point I generally trust that forwarding hosts really are just forwarding hosts when I look at a header to see. To be concrete (pulling a note at random out of the garbage for the week): From [EMAIL PROTECTED] Sun Mar 14 15:28:51 2004 Return-Path: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: from pohl.acpub.duke.edu (pohl.acpub.duke.edu [152.3.233.64]) by mail.phy.duke.edu (Postfix) with ESMTP id B5A33A77F7 for [EMAIL PROTECTED]; Sun, 14 Mar 2004 15:28:51 -0500 (EST) Received: from 152.3.233.64 ([200.215.92.74]) by pohl.acpub.duke.edu (8.12.10/8.12.10/Duke-5.0.0) with SMTP id i2EK4b0 3030509; Sun, 14 Mar 2004 15:04:57 -0500 Received: from [7.197.76.17] by 152.3.233.64; Mon, 15 Mar 2004 02:01:00 +0600 Here I'm pretty sure that pohl.acpub.duke.edu (also 152.3.233.64) is telling the truth about where it received the message from and isn't forging the previous hop because its administrator(s) are local and accountable and their address resolves. This particular example is interesting in that as far as I can tell from registry information, 7.197.76.17 doesn't exist and there is no route to it. The 200.215.92.74 address is a relay in brazil. Neither of them seems promising in terms of being able to report the spam. Note also that I have to WORK with whois, traceroute, host, dig, a variety of tools trying just to figure out where the spam is coming from (although admittedly spamassassin does the same work automatically and better which is why the message is in the trash). However, I'm still left unable to complain to the enabling ISP. They speak portuguese and I don't. They may have postmaster set up or may not. They may give a rat's ass or may not (likely not). To even START to fix this problem, postmaster has to work on the relay and be responsive. The relay host manager has to know that their access to the entire Internet will be effectively terminated if they don't have a working postmaster address and are not responsive to spam. The communication mechanism that reports spam has to both include the key information about times, addresses, and so forth AND has to function independent of knowledge and degree of expertise of the user. I know what I'm doing (at least, to a point:-) and I'm daunted by the prospect. Most users wouldn't even know what all those words I just used mean... So I have to say again -- there may be IETF work that could be done here. It shouldn't be this difficult, and there needs to be a whole structure erected to make mail administrators accountable at some level. And ultimately, we may all have to be willing to pull the plug on [EMAIL PROTECTED]|B:747host 200.215.76.17 17.76.215.200.in-addr.arpa domain name pointer BrT-S4-1-2-22-bnuce300.brasiltelecom.net.br. and effectively cut them off from the Internet if they don't police their relays and e.g. refuse to accept mail from unregistered hosts. Only thus can we forge a chain of responsibility back to the SPs that they cannot easily evade. } If every ten pieces of spam sent out of an SPs network -- even every 100 } pieces -- generated a complaint message to postmaster with headers laid } out that clearly identified the offending host/client,
Re: Principles of Spam-abatement
On Wed, 17 Mar 2004, Dean Anderson wrote: On Wed, 17 Mar 2004, Robert G. Brown wrote: a) Preparse the header so that the entire delivery path is the primary content of the message, with the message itself added (header intact) as an attachment. This is true now. Many people don't know how to parse the headers, but it obeys a specific syntax and is machine parseable. Of course. To both -- many people don't know how to parse the headers. I'd estimate some 499,950,000 of the half a billion users of mail. So the CAPABILITY of parsing the headers exists, but not even AV vendors (who should know how and know better) do it. b) Return the complaint as mail to postmaster of the originating network with a special error code that would allow it to be counted and digested easily. One doesn't want to create a new kind of DoS attack on postmaster, and making it easy and automatic to return a complaint COUNT of some sort on otherwise identical content can help prevent that while making it easier for SP admins to deal with mounting complaint levels. This is possible now, and SpamCop does this. The problem with SpamCop is that they alter the message, making it useless. SpamCop complaints are routinely deleted as a result. I usually forward them on to customers with an FYI that we don't consider such to be a valid complaint, but they may want to be aware of what someone said. So what you are saying is, that this CAN be done and even is being done, but it isn't done correctly and consistently and isn't widely available. I agree. In fact, I think that this is potential work for the IETF -- define a way for it to be done correctly and consistently (which wouldn't be too difficult, I imagine) via a protocol. Then SpamCop could fix their tool, SpamAssassin could add a compliant interface, Joe's Spam Seal (not yet written) could be written to comply with the protocol and abuse@ or postmaster@ addresses could actually AUTOMATE a response process based on consistent completely reported problems. This lowers their cost and makes it easier and more likely that they'll take effective action. As you say, if you get insufficient information, there is little that you can do even with the best of will as the manager of an ISP with too little time and too many things to fill it. You probably don't have time or energy to engage in the please resend your complaint with the full header and message attached game (known to administrators everywhere, and not just in regard to mail:-). c) Work out what to do about relays and proxies, again to prevent man-in-the-middle DoS more than anything else. One site should not be able to generate mail that it forwards with fictitious headers and evil content so that it appears to come from some hapless but innocent network. Relays don't add ficticious headers, nor do they add evil content. They may place their (true) headers on top of ficticious headers. They cannot verify that the headers given are accurate. This is true of all relays, open or closed. Proxies are another story. I don't know of any genuine reasons to run open proxies, though closed proxies (web caches) are clearly useful. I don't know of anyone claiming they are useful. But neither does that mean they have no use. However, as a service provider, I would say this much: If a customer found a useful reason to have an open proxy, then I would only insist that they keep logs of its use. This is easy to place in a contract or AUP. Again, precisely. So what this means is that if I set up a mail server and send a lot of spam from it all with a header that is forged UPstream from my host, I obscure my host as its true point of origin. I can pick on a hapless host somewhere far away and make it look like the spam originates from THEIR network, and one would have to compare traffic logs on the two hosts and/or intermediary hops to determine which of us is lying. This makes for an interesting attack -- send egregious spam purporting to come from somebody you hate or some network you are in competition with, in a messages with multiple relays. Somebody with a big view of the hand might finally figure out what was happening, but proving it would be, well, difficult doesn't begin to describe it, given that all the log data on both sides could be easily forged. Again, there might be work for the IETF here that could help IF this becomes a problem or as a preemptive measure now. There are ways to do this -- signing a key with a local secret and adding it to the message, for example -- that even if you didn't have a universal PKI for all participating hosts would make forging headers for openly fraudulent reasons easy to catch. You can forge the upstream route, but you cannot forge the upstream keys, and the last common host whose key can unlock their MTA-added tag is left holding the responsibilty bag. d) Take steps to ensure that SPs run a postmaster
Re: Principles of Spam-abatement
From: Robert G. Brown [EMAIL PROTECTED] From [EMAIL PROTECTED] Sun Mar 14 15:28:51 2004 Return-Path: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: from pohl.acpub.duke.edu (pohl.acpub.duke.edu [152.3.233.64]) by mail.phy.duke.edu (Postfix) with ESMTP id B5A33A77F7 for [EMAIL PROTECTED]; Sun, 14 Mar 2004 15:28:51 -0500 (EST) Received: from 152.3.233.64 ([200.215.92.74]) by pohl.acpub.duke.edu (8.12.10/8.12.10/Duke-5.0.0) with SMTP id i2EK4b0 3030509; Sun, 14 Mar 2004 15:04:57 -0500 Received: from [7.197.76.17] by 152.3.233.64; Mon, 15 Mar 2004 02:01:00 +0600 Here I'm pretty sure that pohl.acpub.duke.edu (also 152.3.233.64) is telling the truth about where it received the message from and isn't forging the previous hop because its administrator(s) are local and accountable and their address resolves. This particular example is interesting in that as far as I can tell from registry information, 7.197.76.17 doesn't exist and there is no route to it. The 200.215.92.74 address is a relay in brazil. Neither of them seems promising in terms of being able to report the spam. I disagree: 1. pohl.acpub.duke.edu is not an external relay for you. It is your system, even if you don't have a root password or any account on it. 2. 200.215.92.74 is not just a misconfigured relay, because it used the spam trick of using the IP address of its target for its HELO value. It might be an owned box with a trojan or it might be worse. 3. the Received line pointing to 7.197.76.17 is obviously silly nosnense for more than one reason. Let's not educate the listening spammers on the details. 4. you don't need to know why I claim #2 or #3 to properly report that spam. All you need is a tool that will pick out the only IP address that matters from the only Received header you can trust, the top one, and send a report. There are several common tools that do exactly that. Some involve commands lines, but most are point-and-click. Their defects are mostly that they try to do more, such as detecting hosts of spamvertised URLs. 5. #2-#4 are irrelevant. Whether Comite Gestor da Internet no Brasil hears about the spam fountain at 200.215.92.74 is none of your concern unless you have an unhealthy obsession with spam. All you should care is that by hosting that spam fountain, all hosts in 200.128/9 are less likely to be able to send mail to pohl.acpub.duke.edu and mailqueue1.duke.edu 6. Yes, I am a certifiable expert on at least some unhealthy obsessions with spam. To even START to fix this problem, postmaster has to work on the relay and be responsive. The relay host manager has to know that their access to the entire Internet will be effectively terminated if they don't have a working postmaster address and are not responsive to spam. The communication mechanism that reports spam has to both include the key information about times, addresses, and so forth AND has to function independent of knowledge and degree of expertise of the user. I know what I'm doing (at least, to a point:-) and I'm daunted by the prospect. Most users wouldn't even know what all those words I just used mean... NO! Nothing significant has changed since Steve Wolfe stopped being the bogyman we used to frighten lusers into not being naughty. - all that is needed to fix this problem is for the operators of mailqueue1.duke.edu and pohl.acpub.duke.edu to have reasonable counts of the spam from 200.128/9 and take action, or to delegate those actions to the SMTP trust vendor of their choice (currently DNS blacklists). - If Comite Gestor da Internet no Brasil is a reputable outfit, then it will do as bazillions of other repubutable outfits, including Duke University, have long done, and detect and deal with its spam problem, without your let, leave, hindrance, assistence, notice, help, or nagging. - Purely for extra credit, someone might try to forward an unmodifed copy of that spam with complete headers to [EMAIL PROTECTED], [EMAIL PROTECTED], and/or [EMAIL PROTECTED] If the recipient can't figure out purely from the copy of spam what to do, then that's not our problem. At most 200.128/9 we should disconnnected from the Internet that we use by adding to our blacklists. If someone at Duke finds a need to receive mail from 200.128/9, you might review that blacklist entry or punch a hole in the blacklist. Apologists for spam friendly ISPs including those who claim to believe that $360/year is a fair price for a fundamental human right will say that ISPs can't stop spam unless everyone reports it. That claim is nonsense. When it comes from ISPs, it is a bald faced lie; it is possible even for a raw IP bandwidth ISP to detect spam. So I have to say again --
Re: Apology Re: Principles of Spam-abatement
On Wed, 17 Mar 2004 12:26:13 -0500 (EST), Dean Anderson wrote: However, I think there are things that show some promise that might be harder to adapt to, such as automated text summarization, bayesian filters, mail agents that filter on the user's interest in the message subject, and such. How about You are a polluter, your connectivity has terminated, you are on a customer blacklist, and you will never get connectivity from us again? Spammers would have a little trouble adapting to that. I think these are worth pursuing, but these are not subjects for the IETF. IETF's documenting that this is the behavior expected of any firm offering connectivity is certainly within the IETF's purview. And it would have a dramatic effect. (Partly because of norms; partly, at least in the U.S., because it would expose pollution-enabling ISPs to heavy-duty legal liabilities. Stockholders would get after their boards.) Jeffrey Race
Re: Principles of Spam-abatement
On Wed, 17 Mar 2004 14:04:58 -0500, John Leslie wrote: - If you say that third party organization could assure you that a mail sender is not a spammer, then you must agree that an ISP could check with that organization before adding a password to a RADIUS server or or turn on a DSLAM, and that an ISP could terminate an account when that third party revokes is assurance. The first part is actually true: I think we'd actually see that if such third-party services come into common use. :^) The second part (terminating) is not true, IMHO. There's a real danger of getting sued for that, Depends entirely on what the contract of carriage says. Obviously one of the norms we have to universalize in standards and practice documents is that carriage is denied to polluters as part of the contract, and this provision must bind everyone else who shares connectivity under the contract. not to mention the loss of revenue. There you have it! Polluting pays! See http://www.camblab.com/nugget/spam_03.pdf Jeffrey Race
Re: Principles of Spam-abatement REALITY CHECK TIME
On Wed, 17 Mar 2004 15:48:05 -0500 (EST), Dean Anderson wrote: How would you define responsiveness? That's an easy one! 'Does the pollution cease?' is the answer. Let's pause this very interesting thread for a momentary reality check. See ROKSO. The world's top spammers, accounting for the great bulk of the packets, are known by name, address and telephone number. Their upload paths are known. Their software is known. The stigmata of their transmissions are known. (In many cases their criminal records are known.) It is trivially easy to verify _at any moment_ whether a pollution-enabler has responded. Does everyone agree? Dean, you too? :) Jeffrey Race
Re: Principles of Spam-abatement
On Wed, 17 Mar 2004 17:21:42 -0500 (EST), Robert G. Brown wrote: To even START to fix this problem, postmaster has to work on the relay and be responsive. The relay host manager has to know that their access to the entire Internet will be effectively terminated if they don't have a working postmaster address Work has already started on this: http://www.rfc-ignorant.com/
Re: Principles of Spam-abatement
Robert G. Brown wrote: Right now enabling SPs are insulated from any kind of RFC-based responses or complaints about spam because MUA's and MTA's have no predefined protocol for generating such a response in a constructive way. Most complaints/bounces that are automatically generated by antivirus software or reported by humans (I've read plenty of both:-( are hopeless and de facto useless without several rounds of communications, and sometimes not even then: the humans don't even know what a mail header IS and often have no way of knowing or suspecting that the From address is bogus or sending in the real header so it can be parsed by the SP postmaster. Antivirus software developers should know better (damn it!) but even THEY don't bother to parse the header or include the header in the stupid bounces they generate, or validate any sort of correspondance between originating host and From address. So even though one could argue that adding a real protocol layer for a preformatted, standardized, spam/virus bounce is not strictly necessary because all the information is already IN the header, doing it anyway might codify and standardize a complaint so that the complaint always contains the essential information and so that a complaint to the right target is easy to generate (can even be generated automatically). It could then guide the development of compliant tools that can deal with this for ignorant humans using stupid MUAs and maybe even (presumably) smarter AV programmer humans as well. We have a closed subgroup in the ASRG for discussions of exactly this kind of stuff (http://asrg.sp.am/subgroups/abuse_reports.shtml). But we haven't gathered that much interest which makes us think that not everyone considers this a great idea. Yakov
Re: Principles of Spam-abatement
Robert G. Brown wrote: On Wed, 17 Mar 2004, Dean Anderson wrote: On Wed, 17 Mar 2004, Robert G. Brown wrote: ... b) Return the complaint as mail to postmaster of the originating network with a special error code that would allow it to be counted and digested easily. One doesn't want to create a new kind of DoS attack on postmaster, and making it easy and automatic to return a complaint COUNT of some sort on otherwise identical content can help prevent that while making it easier for SP admins to deal with mounting complaint levels. This is possible now, and SpamCop does this. The problem with SpamCop is that they alter the message, making it useless. SpamCop complaints are routinely deleted as a result. I usually forward them on to customers with an FYI that we don't consider such to be a valid complaint, but they may want to be aware of what someone said. So what you are saying is, that this CAN be done and even is being done, but it isn't done correctly and consistently and isn't widely available. I agree. In fact, I think that this is potential work for the IETF -- define a way for it to be done correctly and consistently (which wouldn't be too difficult, I imagine) via a protocol. Then SpamCop could fix their tool, SpamAssassin could add a compliant interface, Joe's Spam Seal (not yet written) could be written to comply with the protocol and abuse@ or postmaster@ addresses could actually AUTOMATE a response process based on consistent completely reported problems. This lowers their cost and makes it easier and more likely that they'll take effective action. We are actually soliciting volunteers in the ASRG specifically for this kind of work - protocols and formats for abuse reporting to be discussed in a closed subgroup separate from the main ASRG list (http://asrg.sp.am/subgroups/abuse_reports.html). So far, we haven't gotten much interest :( As you say, if you get insufficient information, there is little that you can do even with the best of will as the manager of an ISP with too little time and too many things to fill it. You probably don't have time or energy to engage in the please resend your complaint with the full header and message attached game (known to administrators everywhere, and not just in regard to mail:-). If part of the protocol and format states that specific information is required, you can discard non-compliant reports solely on the basis of being non-standard. Or you can just discard them :) d) Take steps to ensure that SPs run a postmaster address, and maybe There is already a BCP for this. Rarely is this a problem. In the US. Try hitting the postmaster of 7.197.76.17, and good luck communicating with the postmaster of the brazilian relay in my previous reply. (This is picking nits -- actually I agree that what can be done largely has been done, but it would be lovely to be able to extend overseas with a little more ease, to get a bit poetic...;-) There has been a proposal in the ASRG from someone about storing contact data for abuse departments in the rDNS tree the same way there is a responsble RR type for forward DNS. So far hasn't seen much interest... come up with things like Jeff Chase was proposing to continuously measure their responsiveness to spam/virus-class bounce messages and globally blacklist the worst (least responsive) offending SPs. Etc. How would you define responsiveness? Does it mean getting an auto-responder message? Does it mean getting a message saying something had been done? You cannot give out certain information about customers. Basically, all you can do is send an auto-responder message and a notice that the ticket was closed. That doesn't indicate what happened, nor does it indicate who the spammer was, or if the ISP agreed they were a spammer. Sometimes the action is obvious if, say, a website disappears. But how do you know they took action against a dialup customer? You can't. No, I think that responsiveness has to be measured by the level of spam reported as originating within the site -- results. I don't think this is that difficult, actually. Vernon pointed out that once earthlink got serious about controlling spam, the reduction in traffic was very apparent. If the IETF has any role here (and it may not) it might be to codify the process of blacklisting ISPs that aren't serious as they are revealed. You've pointed out several times that abuse of blacklists is pretty easy as things stand. It shouldn't be. And people like you who have bad experiences with the previous non-process should be the ones who end up agreeing that whatever schema that might be proposed is fair and equitable and not likely to punish ISPs who are doing their best. A general BCP on blacklists and how to properly apply them would be higly useful. Another BCP on how to properly manage a blacklist would be useful as well. Both have been floated in the ASRG, no one volunteered :( Right now enabling SPs are insulated
Re: Principles of Spam-abatement
... you asked about trust query protocols, not about blackhole lists. as the creator of the first blackhole list, let me just say, they don't scale. Are you saying that a new secure scalable trust query protocol be help? more of a new trust system than what you said. one thing to chew on is, there are many orders of magnitude more potential bad actors than potential good ones. What about the inherent resistance of existing people to change? there's no way to get existing people to change... against their will.
Re: Principles of Spam-abatement
On Thu, 18 Mar 2004, Yakov Shafranovich wrote: Paul Vixie wrote: [EMAIL PROTECTED] (Vernon Schryver) writes: ... but I don't see any direct connection between [DNSSEC] and a replacement for DNS blacklists. i know. but you asked about trust query protocols, not about blackhole lists. as the creator of the first blackhole list, let me just say, they don't scale. Are you saying that a new secure scalable trust query protocol be help? What about the inherent resistance of existing people to change? This excuse is used as stop sign for number of new idea or protocol change in case of IETF. Don't listen to it - propose the ideas and work on them, if its truly good - it should be at least attempted. As far as trust protocol or whatever, this is very far from mainstream and current mechanisms are either within group of geeks using PGP or large corporations that use S/MIME and need it for their internal policies. It has not entered society at large so we still have time to come up with something good that will make it worth it for that to happen. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: Principles of Spam-abatement
william(at)elan.net wrote: On Thu, 18 Mar 2004, Yakov Shafranovich wrote: Paul Vixie wrote: [EMAIL PROTECTED] (Vernon Schryver) writes: ... but I don't see any direct connection between [DNSSEC] and a replacement for DNS blacklists. i know. but you asked about trust query protocols, not about blackhole lists. as the creator of the first blackhole list, let me just say, they don't scale. Are you saying that a new secure scalable trust query protocol be help? What about the inherent resistance of existing people to change? This excuse is used as stop sign for number of new idea or protocol change in case of IETF. Don't listen to it - propose the ideas and work on them, if its truly good - it should be at least attempted. Thanks :) As far as trust protocol or whatever, this is very far from mainstream and current mechanisms are either within group of geeks using PGP or large corporations that use S/MIME and need it for their internal policies. It has not entered society at large so we still have time to come up with something good that will make it worth it for that to happen. The discussions here, on the main ASRG list, in ietf-mxcomp and smtp-verify subgroup of the ASRG are currently dancing around this issue of trust and trust protocols. I would like to converge all of these discussions into one single forum, possible the ASRG. Yakov
Re: Apology Re: Principles of Spam-abatement
On Tue, 16 Mar 2004, Dr. Jeffrey Race wrote: On Mon, 15 Mar 2004 18:12:22 -0800, Ed Gerck wrote: BTW, how can we talk about actions that have consequences in terms of a technical solution that the IETF can pursue? The whole point is there are NO TECHNICAL SOLUTIONS and never will be. Correct, and I gave an explanation for this in inforamtion theory. (There are some technical aspects to improving traceability, however.) The traceability is about as good as it will get. If you have an IP address and a time, that is all you need, and like a phone number, all you might hope to get. While an open proxy can hide the true IP of the abuser, you still get the IP of the open proxy. Likewise, if the dialup account is stolen, you may get the IP address assigned to users of the dialup gateway, which also isn't the culprit. Even cryptographic methods start by having ISP's issues certificates. The certificates, like other accounts might be thought of as disposable. Or they might be stolen. Authentication is not a solution to spam. As you might recall, after the east coast power outage, it was suspected that the outage might have been related to a virus. While it turned out not to be, it didn't take long for the virus author to be tracked down by law enforcement. There is nothing wrong with the current traceability. What anti-spammers want is to have access to private information. This will not happen without proper legal procedures. CAN-SPAM explicitly permits information to be obtained by subpoena, but basically, this was all obtainable before, as AOL and many others have demonstrated. IETF would not apply the consequences; the victims would apply the (behavioral) consequences using established guidelines, employing technical measures already established in RFCs. IETF and other standards bodies can bless agreed procedures for using the existing technical steps in new behavioral ways. There are two reasons this is crucial: 1) Courts often, perhaps usually, defer to declared norms of industry standards bodies, in establishing reasonableness of disputed behavior. We can be decisive in establishing these norms. The courts can't easily act to use the COMPLETELY ADEQUATE EXISTING LAWS in part because of this lacuna. Example? Given that you seem to think open relays are bad (from you proposal), and since the only time I've ever heard such a claim involved open relays, I'm guessing that's what you mean. Having litigated the issue--it was so frivolous that it didn't get to a filing but there were lawyers involved, I can report to you that the reasonableness of running open relays in particular has nothing to do with technical standards. The central issue is that there a genuine reasons to provide unauthenticated or post-authenticated relay services outside one's assigned IP address space, and secondly, the claims that open relays are somehow associated with spam or provide some benefit to spammers doesn't hold up to legal scrutiny. Open relays are not the same as anonymous relays. Open relay use doesn't in any way impede investigation of spam. Nor does open relay use impede spam blocking. There are two types of people who speak against open relays: The first type are misled. They have very little idea of what an open relay is or why they would be used. They've just been told that open relays are bad, and have come to believe this fervently themselves. It is an article of faith, and not of logic. The second type abuses them. Genuine spammers of the sort that would be subject to the CAN-SPAM act do not abuse open relays. Only radical anti-spammers search for, and abuse open relays. 2) Normative documents, and personal leadership, convert a group or a mob into an emergent structure (say a business firm, a dance company, a charitable organization, a military unit, a religious order, a teen gang) in which the norms absolutely bind the behavior of the participants, even to death. I say, in a completely non-deprecating way, that these points from law and sociology may not be apparent to engineers (or in fact to anyone else who is not an attorney or a sociologist) but they are completely true and completely binding on human behavior. The consequences are not technical. In addition, they would need to be arbitrated and we know how long, ineffective and expensive that can be. No arbitration needed. Please re-read the proposal. My proposal (which received input from many people) is basically just common sense. That's what we need now. The answers are in. The proof is in. Let's do it. Now. Actually, common sense would be that anytime you interfere with someone's rights, there will be legal procedures involved. But this is another weakness in the cherished assumptions of the radical anti-spammers. They seem to think that they are the only people with rights.
Re: move to second stage, Re: Principles of Spam-abatement
Ed Gerck wrote: In a separate thread, under Yakov's suggestion, the solution part of this discussion is now probably moving on to the closed ASRG list (with open archive) as posted in http://article.gmane.org/gmane.ietf.asrg.smtpverify/300 I'd like to now address the other part of Yakov's reply below, or Why not keep the old design if we can get back to the old assumption? Comments inlined. The solution to spam lies squarely in the IETF hands. We need an Internet design where the end points are less trusted than the connection. The opposite of what we have today. Only then, IMHO, can we have those kind of solutions that the IETF can take on in order to really reduce the problem. Of course, updating the Internet design to fit its current operating conditions is useful not only to stop spam. Social engineering and spoofing attacks also rely on the old honor system where users are trusted. Trust no one should be the initial state under the new Internet paradigm. So the bottom line is that we lack trust. This echoes the comments made by the IAB in section 3.1 of (http://www.iab.org/documents/drafts/draft-iab-e2e-futures-05.txt). How would introducing trust help with the spam problem? Would the cost of doing so perhaps would be so prohibitive that we will not be able to do so? Is it really possible to introduce trust that will actually work? Yakov
Re: Apology Re: Principles of Spam-abatement
Dean Anderson wrote: On Tue, 16 Mar 2004, Dr. Jeffrey Race wrote: The whole point is there are NO TECHNICAL SOLUTIONS and never will be. Correct, and I gave an explanation for this in inforamtion theory. What information theory says is that the probability of detecting spam is less than 100%. This has nothing to do with what or what not the IETF can do to prevent spam. This result is useful only for an end-user, to feel good about his spam filter not being 100% effective. This is a user result, not an IETF goal. What interests the IETF are technical spam solutions, for example, that would prevent email that comes from unidentifiable or rogue senders/MTAs to be ever received. Not because spam is detected as such but because untrusted, unidentifiable or rogue senders/MTAs are detected. Yeah, this would still leave room for trusted and identifiable senders/MTAs to send spam messages. But such spammers are no longer a hidden target. And it would be a lot harder for someone to send spam on behalf of you. These are examples of feasible technical, IETF-relevant solutions to spam, not at all denied by information theory. To implement these solutions, we need an Internet design where we recognize that the end points have become much less trusted than the connection. This is the opposite of what the DARPA Internet assumed and was designed for. So, some things gotta change. For example, saying that you're [EMAIL PROTECTED] should not be so easy to do when you're sending email, even though it should still be easy to set [EMAIL PROTECTED] as your address in your MUA. Cheers, Ed Gerck
Re: move to second stage, Re: Principles of Spam-abatement
Yakov Shafranovich wrote: So the bottom line is that we lack trust. Depends how you define trust. In my view, the bottom line is that trust depends on corroboration with multiple channels while today we have neither (a) the multiple channels nor (b) the corroboration mechanisms. So, we lack trust because we can't communicate it. It's an even more basic limitation than just lacking it ;-) How would introducing trust help with the spam problem? By allowing trust to be earned between humans and machines, and to each other. Machines can then become our agents also in terms of trust decisions. Would the cost of doing so perhaps would be so prohibitive that we will not be able to do so? Anything else will be more expensive because there is no other solution. Trust is that which provides meaning to information (Shannon: information is that which you do not expect, information is surprise). Without trust, all we have is a string of bits. Let me give you some examples. 1. If I ask you whether the expression in quotes 1=1 is true or false, what would you say? Looks simple enough, no? HINT: Your answer depends on the meaning you assign to the expression 1=1, which depends on what you rely upon (i.e., what you trust) when you evaluate it. The same process is reflected in software when that expression is evaluated to true or false. For example, the above expression is incorrect in C. 2. if I tell you I'll send you a GIFT, can you tell me what you think I'll send: (a) a present (b) a poison (c) anything HINT: To answer this question, you also need to assign a meaning to the word GIFT, which depends on what you rely upon (i.e., trust) in regard to me (since I formulated the question). Again, the same process is reflected in software when a tag is evaluated in a protocol. In English, (a) is correct. In German, (b) is correct. Is it really possible to introduce trust that will actually work? It works every day. Otherwise we would not be able to cook, earn money or even talk. We just have to transpose this knowledge from our wetware to the software. Cheers, Ed Gerck
Re: move to second stage, Re: Principles of Spam-abatement
On 3/16/2004 3:41 PM, Yakov Shafranovich wrote: How would introducing trust help with the spam problem? Would the cost of doing so perhaps would be so prohibitive that we will not be able to do so? Is it really possible to introduce trust that will actually work? Trust is a contiuum, like everything else related to security. Different people will have different levels of trust; having a marketplace of trust brokers -- each of whom provide different levels and strenghts based on different factors -- is appropriate. Some people and/or services will require notarization-based trust, others will be happy knowing that blacklist-dujour.org doesn't think the sender is scum. I don't see what cost has to do with it. The IETF only needs to provide standardized mechanisms for negotiating trust between end-points. Leave the brokerage functions (and the implementation costs) to the service providers who want to enter the market. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Apology Re: Principles of Spam-abatement
Ed Gerck wrote: What interests the IETF are technical spam solutions, for example, that would prevent email that comes from unidentifiable or rogue senders/MTAs to be ever received. Not because spam is detected as such but because untrusted, unidentifiable or rogue senders/MTAs are detected. Yeah, this would still leave room for trusted and identifiable senders/MTAs to send spam messages. But such spammers are no longer a hidden target. And it would be a lot harder for someone to send spam on behalf of you. Yes! I agree that the IETF can not stop spam. A very reasonable goal would be to stop or make very unlikely, or difficult to send forged spam. Or at least make it detectable early in the process of accepting email and hang up on the spammer. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)520-4044 http://Royer.com/People/Doug | Fax:(866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: Apology Re: Principles of Spam-abatement
On Tue, 16 Mar 2004, Ed Gerck wrote: Dean Anderson wrote: On Tue, 16 Mar 2004, Dr. Jeffrey Race wrote: The whole point is there are NO TECHNICAL SOLUTIONS and never will be. Correct, and I gave an explanation for this in inforamtion theory. What information theory says is that the probability of detecting spam is less than 100%. No, information theory doesn't say that at all. Indeed, the probably of detecting spam is probably very close to 100% This has nothing to do with what or what not the IETF can do to prevent spam. No, it is quite useful: The IETF can do nothing to prevent spam. What interests the IETF are technical spam solutions, for example, that would prevent email that comes from unidentifiable or rogue senders/MTAs to be ever received. The only thing that can acheive this is to turn off the computer. Not because spam is detected as such but because untrusted, unidentifiable or rogue senders/MTAs are detected. Yeah, this would still leave room for trusted and identifiable senders/MTAs to send spam messages. But such spammers are no longer a hidden target. And it would be a lot harder for someone to send spam on behalf of you. These are examples of feasible technical, IETF-relevant solutions to spam, not at all denied by information theory. The IETF can specify protocols with certain features, say PKI, but doing so will not prevent spam, since the IETF (nor anyone else) cannot specify a 'spam-free' protocol. This is a result of information theory. To implement these solutions, we need an Internet design where we recognize that the end points have become much less trusted than the connection. This is the opposite of what the DARPA Internet assumed and was designed for. So, some things gotta change.
Re: Apology Re: Principles of Spam-abatement
Dean Anderson wrote: On Tue, 16 Mar 2004, Ed Gerck wrote: For example, saying that you're [EMAIL PROTECTED] should not be so easy to do when you're sending email, even though it should still be easy to set [EMAIL PROTECTED] as your address in your MUA. The From: address is just dressing. It makes no difference what its actual value is, nor that it can or can't receive email. As was pointed out, many things only send email, and don't receive it. Those things will have informative (or not) from addresses that are invalid for reception. Things that send email but don't receive them can nonetheless have a valid email entry for 'no mail accepted', with no mailbox. In terms of trust as I defined before here [1], an email address for those things (or any other things) should have a *minimum* of three values: + trusted according to policy(+) 0 trust value not assigned - distrusted according to policy(-) Of course, the positive and negative range can be expanded in values as well. How to assign these values? How the trust model works? Let me copy from an earlier discussion elsewhere. This is the wrong question to ask. The real answer is, what trust model would you like? There is a built-in notion (given by the abstract trust definition in [1]) of the meta-rules that a trust model has to follow, but I might buy a trust model from someone and add that, design my own, or even augment one I bought. Thus, I can ask for a fingerprint and check it against the FBI, Scotland Yard, and Surite databases, check their PGP key to make sure that it was signed my Mother Theresa, ask for a letter of recommendation from either the Pope or the Dalai Lama (except during Ramadan, when only approval by an Iman will do), and then reject them out of hand if I haven't had my second cup of coffee. As flippant as I'm being, this has a lot of value. I write with a GUI framework because I don't have to worry my pretty little head about the details of how to draw a checkbox. I ask the system to draw it for me, and it does. It even handles what happens when it's clicked. I just ask the checkbox if it's on or off, and it tells me. If I want a special checkbox, I can make one of those as a subclass, and once I've done that work, I don't have to think about it again, I just use it. Similarly, if I use such a concept of trust, I may have to do some up front work to get things the way I want but I can always use an off-the-shelf validity mechanism. In either case, I just ask the trust framework if the trust assertion is valid. The framework can combine rules of thumb with special-cases as appropriate, and without my having to worry my pretty little head about it. Trust on the sender cannot be proven by the sender (self-assertions cannot induce trust -- e.g., trust me doesn't work), but must be calculated using sources independent of the sender. The sender may hint to a specific trust service used, and even provide it and its values, but we should be able to get that information from the service directly and/or chose our own trust services independently. In doing so, trust on the sender is what the receiver determines at a specific time based on a behavior model for the sender. If the sender cooperates, the process can be faster and easier. But the sender cannot determine the process. The problem is, thus, not how do you determine trust, especially with all the different definitions of spam possible, but how do you want to do it. Cheers, Ed Gerck [1] http://nma.com/mcg-mirror/trustdef.htm
Re: Apology Re: Principles of Spam-abatement
Dean Anderson wrote: On Tue, 16 Mar 2004, Ed Gerck wrote: What information theory says is that the probability of detecting spam is less than 100%. No, information theory doesn't say that at all. Sure it says, and that's why a spam filter will never be 100% effective. I guess we agreed on this before ;-) We also agreed that spam filters are a user matter, not IETF matter. Now, you may want to refer to that mythical element, the 'spam-free' protocol, a protocol that an information theory model says cannot be built. I guess we also agreed before that a 'spam-free' protocol is impossible. The IETF should not attempt to develop it. Thus, in asking for IETF technical solutions for spam, it is obvious that I do not mean spam filters or 'spam-free' protocols. We would all be very happy with a protocol that is almost spam-free -- in fact, I believe we would be quite happy with 90% at this time. Me thinks we don't need 100% ;-) An IETF technical solution to reduce spam is doable. Your comment on 'spam-free' is useful-free ;-) No, it is quite useful: The IETF can do nothing to prevent spam. ;-) this mantra is becoming a spam. What interests the IETF are technical spam solutions, for example, that would prevent email that comes from unidentifiable or rogue senders/MTAs to be ever received. The only thing that can acheive this is to turn off the computer. No, it's a matter of degree. Even if not all spam is preventable, preventing email address spoofing (even to a degree) would have a range of benefits. For example, I would no longer receive those undelivered messages for email that I purportedly sent, but actually never did. And people receiving email from me could actually trust to some extent the outcome of their filters. And, to be clear, I'm not talking about PKI. The IETF can specify protocols with certain features, say PKI, but doing so will not prevent spam, since the IETF (nor anyone else) cannot specify a 'spam-free' protocol. This is a result of information theory. Because it can't be perfect, it can't be done? No one needs perfection. All we need is to have a degree of spam-freeness that is acceptable. Sterilized milk is not bacteria-free, it just has a reduced count of bacteria -- which count is low enough to guarantee its stated shelf life. Cheers, Ed Gerck, who doesn't believe in rejecting every possible spam bit.
Re: Apology Re: Principles of Spam-abatement
On Tue, 16 Mar 2004, Ed Gerck wrote: Trust on the sender cannot be proven by the sender (self-assertions cannot induce trust -- e.g., trust me doesn't work), but must be calculated using sources independent of the sender. The sender may hint to a specific trust service used, and even provide it and its values, but we should be able to get that information from the service directly and/or chose our own trust services independently. In doing so, trust on the sender is what the receiver determines at a specific time based on a behavior model for the sender. If the sender cooperates, the process can be faster and easier. But the sender cannot determine the process. The problem is, thus, not how do you determine trust, especially with all the different definitions of spam possible, but how do you want to do it. I wrote one whole response earlier but deleted it (fortunately, as Dean went through my points far more tersely than I was about to). Here I just can't stand it. Ed, are you not paying attention? It is fundamentally, intrinsically, eternally IMPOSSIBLE TO IDENTIFY INDIVIDUAL HUMANS on the internet. I can sit at my laptop and create a hundred entirely real accounts with no humans behind them, with real humans behind them, with me behind them, with alien invaders who will eat your head behind them. From the other side of my network connection YOU CANNOT TELL which of these are real and which are fake. You will never be able to tell without violating so many of my civil liberties that I (and everybody else on the planet) would be out in the streets rioting to get them back. Mail sent out by my perfectly functional MTA (any of them that I might choose to install or one that I might custom-write to serve a particular purpose) is for all practical trust-based purposes ANONYMOUS. Mail has always been designed to be anonymous (paper mail too). There are individually authenticated services and there are anonymous services, and mail transport is an anonymous service because it crosses authentication boundaries. Mail (paper or otherwise) has an envelope, sure, but the only thing on it that you can trust even a little bit is the set of postmarks it develops along its route to your mailbox (and even here, you can really only trust the LAST postmark in the chain, the one one hop upstream). Your MTA cannot fill in the envelope. That can only be done by my (the sender's) MTA unless you've developed that psychic mail transport mechanism. This is no different from paper mail. YOU have to fill in the address information on a paper envelope. You control the pen as surely as you control your sending MTA -- every byte or stroke can be truth or lie. You can lie about your return address. You can fill the envelope with ricin and anthrax or with money and praise (I'd prefer the latter, naturally). I cannot tell if the envelope tells the truth before opening and reading the message. I cannot even tell with CERTAINTY that the envelope tells the truth AFTER opening it except by an out of band communication with the sender. If you want to argue that all mail has to be sent the electronic equivalent of certified mail in the paper world, forget it and think through the metaphor. First of all nobody EVER sends certified mail in the paper world except when money is on the line because a) it COSTS money to have it certified; and b) it is a pain in the ass to have it certified (it costs time). Finally, even in the paper world, certified mail generally means that you send it TO a positively identified receiver with a guarantee that they will receive it. You are generally NOT required to show some sort of id proving that the return address is valid and that you are the person corresponding to the return address and indemnity information. Maybe you are. Maybe you aren't. Maybe you're just a messenger boy. Maybe you're sending well-certified anthrax and lie about everything on the return/sender forms you fill out. In any event, you likely own, literally, the certifying machine (the sender). Spam and paper mail abuse is not a problem that can be solved by addressing trust of identities. It is fundamentally a problem WITH real identification. In the HUMAN world, it is remarkably difficult, and remarkably uncommon, to validate that a human is who they say they are; most glib examples that have been cited to show that it can easily be done show the opposite -- that it is NOT easy and it IS expensive and a PITA. My kids have to bring birth certificates and photo id's to certain things (SAT tests, school registrations). These documents/tokens are not easy to file, to find, to to keep straight and available and are easily lost or stolen. I have to show certain forms of legally certified id in order to validate certain transactions, mostly involving money, and I have to jealously guard them as they are easily lost or stolen. Rituals involving them (such as getting a loan or cashing a check) are
Re: Apology Re: Principles of Spam-abatement
Robert G. Brown wrote: Ed, are you not paying attention? Read below and draw your own conclusions, please. It is fundamentally, intrinsically, eternally IMPOSSIBLE TO IDENTIFY INDIVIDUAL HUMANS on the internet. Who is talking about humans? I am talking about EMAIL ADDRESSES, MTAs, MUAs, END POINTS. Trust at the end points -- the end point is able to do TCP/IP, end points are not human. It is also not relevant if there is, or there is not, a human in control of an end point. It can very well be another machine. I also mentioned that trust should be based on the same definition betwen machines as we use for millenia between humans. Why? So that machines could use well-developed, real-world, tested notions of trust -- and be thus useful as our agents. This answers the rest of your email. Are you paying attention? ;-) Cheers, Ed Gerck PS: BTW, take a look at a work some 5 years ago allowing ISPs to identify who was at the keyboard by their usage pattern, in a household, to properly target advertising. Humans are more identifiable on the Internet than you think. But this is 100% irrelevant to what I wrote about. Humans can't do TCP/IP.
RE: Apology Re: Principles of Spam-abatement
It is fundamentally, intrinsically, eternally IMPOSSIBLE TO IDENTIFY INDIVIDUAL HUMANS on the internet. No one knows you're a dog on the Internet seems to capture it. (Dilbert?) Actually, this cartoon was published in The New Yorker on July 5, 1993, by Peter Steiner. On the Internet, nobody knows you're a dog. (A dog, sitting at a computer terminal, talking to another dog.) -- Christian Huitema
Re: The right to refuse, was: Re: Principles of Spam-abatement
On Sun, 14 Mar 2004, Yakov Shafranovich wrote: First of all, I would like to clarify that I am refering to abuse reporting not just for open relays, but also for hijacked machines and spammers abusing AUPs of their connectivity provider. Many of the abusers I have reported included hijacked machines performing various kinds of abuse, including sending viruses out. If it can be abused, I've probably experienced it and reported it. I didn't quote any percentages. Just my experiences that nearly all of my bad experiences have involved radical antispammers. The rest of my experiences have been largely satisfactory, with the exception of the far east, where language barriers impede effective communication. But this is mostly a language problem, not a lack of care problem. When it has been important, I've found a native speaker to make the complaint. But, as I showed by example, the anti-spam leaders don't think they need to address their own abuse, and are often the people conducting abuse. If you want to discuss responses to abuse, you first have to look at the responses to abuse by the leadership of the anti-spam movement. You have very little credibility without that. However, most providers do address abuse. If I were to make up a percentage, I would put it at around 99% have good abuse programs. It is a very rare case where there is no acceptance of abuse reports. As you note, sometimes it is a matter of getting the necessary attention at the provider. But often, the complaints about lack of provider response are just a result of the anti-spammers' own actions to spam the providers abuse addresses with inappropriate or insufficient information. Often, the anti-spammers try to remove information to generate more complaints and prevent response to complaints. Unfortunatly my experience with with abuse reporting has been different than yours. In most cases when I reported network abuse, very little action has been taken. In one memorable recent case, it took over three weeks and a threatening fax to the CEO's office to stop a hijacked machine on a DSL network of a US baby bell from speweing viruses to my email address. You were successful with a fax to the attention of the CEO. But if others spam the fax line with hundreds of complaints, the fax line will get turned off. Radicals have tried to get end-users to complain directly to the ISPs that the end users (often ignorantly and wrongly) think are responsible. Radicals also alter the messages so that one cannot identify the person abused. SpamCop, as I said before is particularly bad about this. Such reports cannot be accepted, and are not going to be accepted. Non-response in such a case isn't a fault of the provider. Here is an excerpt from a gem posted by Barry Shein (CEO of another Boston ISP) to Spam-l: (11 Feb 1999) I see several of you probing in my logs, but you've gone suddenly silent. Is it because the holes are all closed now and there's no fun in saying that? I recall clearly getting rather reamed when I was a nascent spamfighter by Mr. Shein and posted an apparent spam from std.com. I don't recall the incident, but are you using words like nascent and apparent to try to say you were actually wrong and the spam did not come from our site, that you fell for a forged header or something? Why is so much said here so fishy and full of mitigating phrasing? Further having a bunch of end users try to report abuse about a forged header to the wrong ISP just overwhelms the abuse desk, and slows their response. Additionally, the feedback I have been getting from some of the people who write and sell software for abuse desks at ISPs has been that most ISPs do not respond to individual abuse reports until the report count reaches some magic number irrevelant of the number of spams actually being reported. That's probably not an unreasonable approach. Real abuse usually generates a lot of complaints. Yet, quite a lot of people make spam reports to get off non-spam mailing lists to which they are too lazy or too ignorant to unsubscribe. This type of false reporting is typically low numbered, and can obviously be ignored. So there is a lot to be said of a statistical approach, especially at large providers where such statistics are significant enough to be useful. Is there something wrong with that? In any case, it seems IMHO that there exists a percentage of ISPs that either ignore or mishandle abuse reports. Absolutely true, there are such ISPs. I gave you two examples. But they are few and far between. I just gave you an example of Paul Vixie (ISC.ORG) and his service provider (Bill Manning of EP.NET) refusing to have either an AUP or accept abuse reports on a user that has already been booted from other ISPs, and is clearly and verifiably making defamatory statements. As I said, if anti-spammers aren't going to accept reports and curb abuse,
Re: Principles of Spam-abatement
On 12-mrt-04, at 21:45, Yakov Shafranovich wrote: if there is anything the IETF should or should not be doing in the spam arena (changing existing standards, making new standards, etc.)? How about this: As time goes on, an email address gets on more and more spam lists. One way to avoid this is to use an email address for some time, and then discard it. However, this has the unpleasant side effect that people who only know the old address can no longer send email. What could help here is a standardized mechanism that allows someone to take an old email address and from that discover a pointer to where the new address can be found. This could be done in (at least) two ways: 1. A standard transformation: [EMAIL PROTECTED] - http://xyz.muada.com/iljitsch 2. An SMTP response code: 522 DOES NOT ACCEPT MAIL SEE url
Apology Re: Principles of Spam-abatement
As he so often does, I think Dave has put his finger on the nature of the problem with which we are failing to make progress: On Mar 12, 2004, at 9:36 PM, Dave Crocker wrote: NB some of us want to discuss it in terms of property rights, and others NB of us want to discuss it in terms of human rights. Unfortunately, the IETF mailing list is not a very good venue for either topic, because most of the folks on the IETF mailing list have no qualifications or special insight into these difficult issues. This is exactly right -- we have people arguing from two different paradigms, both fundamentally orthogonal to the expertise of the IETF. What this suggests to me is that until the larger society -- i.e. the courts and international institutions -- reach a determination of the right paradigm for dealing with spam, the IETF is going to spin its wheels on these issues. If someone could tell us definitively this is a question of property rights or this is a question of human rights or whatever, the IETF as a community would be well qualified to do the engineering implied by that conclusion. Until then, it's probably an unresolvable issue for a community as open and democratic as the IETF. But most of us recognize that spam needs to be attacked on several fronts. We can and should focus IETF efforts on getting as many not-overly-controversial approaches to spam control to work together, and declare out of IETF scope those efforts that are the subject of ongoing paradigmatic debates at the political layer. That doesn't mean that people like Paul and Vernon can't work on property-based approaches, nor that others of us can't work on approaches that consider the universal ability to communicate as a higher-priority requirement, but merely that the IETF as a body should probably avoid both of those families of solutions, pending a broader societal consensus. (When Paul started quoting John Locke, I was very tempted -- not being a big Locke fan, to say the least -- to start quoting several other philosophers, and that's when the the lightbulb finally went off in my head, a realization that this was not an IETF discussion anymore. Paul and I can debate philosophy on our own time, and I look forward to it.) Perhaps the rule of thumb is that if the discussion of a topic repeatedly deteriorates into arguments about the philosophical underpinnings of civil society, it's not a suitable topic for the IETF? The question that remains for IETF is this one: what can we -- including people like Paul and me who are mutually friendly and respectful, but philosophically from opposite ends of the Earth -- do together *constructively* about spam? For my part, I think we as an engineering community can make a lot of progress on the less-philosophically-controversial stuff that won't solve the whole spam problem, but that support both of our approaches -- not only the DNS-based approaches being discussed in ietf-mxcomp, but also, I suspect, a whole lot of other things (e.g., standardized headers to let challenge/response work better with mailing lists, protocols for sharing data for collaborative spam filtering, standardized SMTP extensions for cryptographic challenge/response (which this morning's BBC broadcast described as a new Microsoft invention!), and perhaps even improved tracing/accountability tools for law enforcement.) Anyway, in closing I apologize to the entire IETF community for taking so long to realize that some of my technical arguments have been founded upon basic philosophical assumptions which are not universally shared. Perhaps if we can all try to make this separation we will begin to make more progress. -- Nathaniel
Re: Apology Re: Principles of Spam-abatement
On Mon, 15 Mar 2004 10:27:46 -0500, Nathaniel Borenstein wrote: This is exactly right -- we have people arguing from two different paradigms, both fundamentally orthogonal to the expertise of the IETF. What this suggests to me is that until the larger society -- i.e. the courts and international institutions -- reach a determination of the right paradigm for dealing with spam, the IETF is going to spin its wheels on these issues. If someone could tell us definitively this is a question of property rights or this is a question of human rights or whatever, the IETF as a community would be well qualified to do the engineering implied by that conclusion. Until then, it's probably an unresolvable issue for a community as open and democratic as the IETF. The larger society HAS ALREADY REACHED A DETERMINATION because the larger society has dealt with this kind of problem, successfully, since the dawn of civilization. That's why it is called civilization. The principle, simply stated, is Actions must have consequences. When they don't, any sociologist will tell you that you will get exactly the results you see on the internet. This is all spelled out in http://www.camblab.com/misc/univ_std.txt which is based on http://www.camblab.com/nugget/spam_03.pdf. The IETF and other standards bodies can almost completely STOP spam, viruses, trojans, and other security threats, if they will develop tools (for example traceability) and norms (for example null-routing polluting sources) to impose consequences on actions. Once you do it (and there are tricks to make it work, easily, when you decide to do it) then the problems go away in HOURS (not after years of hot air such as we see on certain discussion groups). Now antisocial behavior produces only good for the perps, not the reverse. This is just common sense which every parent knows. Until the standards bodies start this process in motion, everything else is just useless whining. OK, I feel better now. Jeffrey Race
Re: Apology Re: Principles of Spam-abatement
From: Nathaniel Borenstein [EMAIL PROTECTED] Perhaps the rule of thumb is that if the discussion of a topic repeatedly deteriorates into arguments about the philosophical underpinnings of civil society, it's not a suitable topic for the IETF? Here's an idea, for what it's worth: One can think of IETF as a sovereign society whose sovereignty is IETF publications and events. This society has its own form of governance. Poltical and philosophical homogeneity within that society is undesirable and hopefully unachievable. At the same time, it's very often the political and philosophical implications of what IETF does that make it worth caring about. Rather than surpressing those discussions, why not institutionalize them in a way that resolves the tension between having those discussions and making forward progress on IETF's tasks? Maybe a next step (for IETF generally, not just on the narrow issue of spam) is the formation of formal _political_parties_ within the IETF society, each founded on a set of explicit principles. Before you roll your eyes There are proto-parties already, aren't there? Over particular issues and particular careers, some members of the IETF society already form temporary, shifting alliances -- creating factions on this or that issue. Some of those relationships are persistent -- others transient. The shared beliefs of these alliances are sometimes narrowly pragmatic but sometimes rooted in the deeper issues, no? IETF political parties could give that proto-party habit some structure and better effectiveness. It could contain while protecting the kinds of discussion that can degrade into flamewars on the IETF list. Parties could develop and express cross-cutting perspectives on a wide range of issues. They could publish party agendas and platforms. They could publish analysis papers in reaction to particular RFCs and other events. Parties could float candidates for positions within IETF. Parties could be useful interfaces between IETF and external political and cultural organizations: a next-step form of the widely-signed open letter. Where there are divergences between what people within IETF think some of the technology is for and how it is deployed in the real world -- parties could add an air of legitimacy to raising the greater (outside of IETF) society's awareness of the issues. Parties could help to focus IETF participant's messages to the rest of the world. The question that remains for IETF is this one: what can we -- including people like Paul and me who are mutually friendly and respectful, but philosophically from opposite ends of the Earth -- do together *constructively* about spam? And where there are deep philosophical differences, such as between you and Paul, parties could (a) create separate forums in which your respective positions can be developed, studied, and promoted; (b) help to depersonalize the confrontations between competing ideas; (c) muster participents on both sides to perform the search for the best points of agreement. Would parties have real teeth? Inevitably, if they took off, successful parties could muster enough support to block even rough consensus on any one issue. But it would take a while to reach that point and, anyway, my guess is that that would be only a mutually assured destruction scenario that in practice, led instead to formations of better-informed consensus. Would parties partition IETF participants into disjoint sets? I see no reason why they should. There is no need for voter registration in which people state an affiliation. Individuals could have multiple memberships and shifting memberships.The parties would simply be superimposed organizations each of which is chartered to focus on a particular set of broadly applicable principles. For my part, I think we as an engineering community can make a lot of progress on the less-philosophically-controversial stuff that won't solve the whole spam problem, but that support both of our approaches The only problem I see with that attitude is that it easily devolves into hiding away the differences and turning them from an issue for public debate into an issue for back-room intrigue. There's no such thing as apolitical engineering, especially within IETF. It's legitimate to not want to mire the technical work of IETF in flame-wars. But that can be done without sacrificing open and public vigilance towards the issues by enriching the political structure of IETF. _IF_ (a big if) the idea of political parties has appeal, it might be an interesting starting point to think about how some first ones might be chartered. -t
Re: The right to refuse, was: Re: Principles of Spam-abatement
Robert G. Brown wrote: On Sun, 14 Mar 2004, Yakov Shafranovich wrote: ... This is one of the many examples of things that the IETF can do that do not solve the overall problem, but are very well within the IETF's charter to make standards and can help with some aspects of the spam problem. Of course, we can argue about how much impact it will make vs. the cost of the solution, but that's something we should be doing anyway as part of sketching out such solutions in order to evaluate them properly. This is I think a very sane and appropriately limited thing for the IETF to tackle. As you note, it won't solve the spam problem, but then, nothing will as long as it is marginally profitable except possibly legislation and vigorous enforcement. Paper advertising junk mail (which costs roughly $1/piece or even more yet fills my mailbox daily) indicates that we aren't likely to be able to prevent spam by manipulating the profit margin side. Legislation is being advanced and test cases are appearing for existing legislation that might help, but spam is international and in some cases virus driven and hence difficult for real police to deal with. Filtering abates the problem for many if not most of us, and filtering doesn't require any action from the IETF but filter-based solutions are a constant war and a constant cost and bringing additional pressure to bear further upstream would be lovely if it were workable. I think that any sort of upstream attack on spam has to have several features to be successful: ... I am going to reply to the rest of your email off-list in detail since this is becoming out of scope for the IETF list. However, I would like to point out that I agree with many of your points: we need to determine whether there is sufficient buy-in from service providers, we need cheap and easy to use tools for them to use (open source maybe can help?), etc. All of this points to the facts that Dave Crocker was stating several times: for any proposed anti-spam solution we need to look at costs and benefits, AND also at whether the community and industry at large will use it, especially considering that cost vs. benefit balance. However, we should not be dismissing ideas out of hand unless it is very clear that they will not work. Abuse reporting standards is one example of such idea which might or might not work, and needs further discussion. This is exactly what we are trying to do now in the ASRG after John Levine and myself with help from several IETF members re-organized it. At this point we are looking for solutions for subsets of the spam problem such as abuse reporting standards that might be good ideas. As we find these ideas, we create small closed subgroups for discussion to determine whether there is sufficient benefit vs. costs, impacts on the community, AND whether there is sufficient interest in the industry. Our eventual goal is for these subgroups to become regular WGs in the IETF via the IRTF/IETF transfer. We currently have a number of subgroups (http://asrg.sp.am/about/subgroups.shtml), of which the filtering subgroup has been the most active recently discussing standards for MTA/MUA filter communications with participation from several open source and commercial filtering vendors. Most of the others do not have yet sufficient number of interested participants. What we are looking for is ideas from the IETF community, and most important, volunteers who are willing to participate in such closed subgroups to discuss various ideas, costs and benefits, etc. I know that the ASRG has acquired a pretty bad reputation over the past year within the IETF community but we are trying to change that by restructuring it along the lines of multiple closed subgroups focused on specific tasks. The main ASRG list is not necessarily the best representation of our efforts, but in the same vein the main IETF list does not provide the best representation of the IETF efforts either. We would like to use the ASRG as a vehicle for nurturing ideas that are not ready for the IETF but might be good enough to start discussing to prepare for possible IETF standardization in the future. This is one of the basic tasks that the IRTF does in conjunction with the IETF. Comments are welcome. Sincerely, Yakov Shafranovich ASRG Co-Chair
Re: The right to refuse, was: Re: Principles of Spam-abatement
Dean Anderson wrote: Given that, should the IETF pursue development of standards to make abuse reporting easier to facilitate the work of those ISPs that actually do handle abuse reports properly? I'm not against a protocol to help share abuse reports. However, I haven't seen this as much of a problem. As a network operator, I know what other network operators are looking for in terms of logs and evidence of misbehavior. It is quite a lot different from what radical antispammers demand, but those demands don't meet even the thinnest standard for breaking a contract. This is not really any different from, say, a lawyer knowing what elements make up a legal case, and where to file a case. The elements and format vary somewhat depending on the topic, and particular court, but every lawyer knows what they are, or ought to. Likewise, the network professionals generally know what is needed for an abuse report, or ought to. Our intent (the ASRG) in proposing such idea was in order to make abuse handling cheaper for ISPs since machine-readable abuse-reports can be parsed directly into helpdesk software without a need for a human being to type the information in. Obviously this is geared towards the ISPs that handle abuse reports properly today but can in theory be used to help non-compliant ISPs to start handling abuse if the tools are made available at a cheap enough cost. The overall effect in theory would allow ISPs to spend less money handling more abuse reports with better efficiency. At this time one of the closed subgroups of the ASRG (http://asrg.sp.am/subgroups/abuse_reports.shtml) is looking for volunteers to continue the discussion on this subject further in order to determine whether there is sufficient benefit vs. cost for this proposal, and whether the ISP industry at large will even be interested in this. Like I said in a different message. this is an example of something we can do now - pick out subsets of the spam problem and possible solutions, gather small groups of people to discuss it in detail including the benefits, costs, whether it will actually do anything, and industry interest; and for those solutions that actually make sense after discussing them in detail will be transferred over to the IETF as new WGs. This is what we are trying to do at the ASRG and this is something that we can do now. Yakov
Re: move to second stage, Re: Principles of Spam-abatement
In a separate thread, under Yakov's suggestion, the solution part of this discussion is now probably moving on to the closed ASRG list (with open archive) as posted in http://article.gmane.org/gmane.ietf.asrg.smtpverify/300 I'd like to now address the other part of Yakov's reply below, or Why not keep the old design if we can get back to the old assumption? Comments inlined. Yakov Shafranovich wrote: Ed Gerck wrote: The *possibility* of spam is due to an Internet design based on an honor system for the end points. The model being that the connection was less trusted than the end points. Access to the end points was granted under an honor system and usage rules were enforceable. Reality showed that the model was upside down for commercial operation. The end points cannot be controlled and are in fact less trusted than the connection. Anyone can connect to the network. There is no honor system. Usage rules are not enforceable -- users can hide and change their end points. The original design relied on the human assumption that someone would enforce the rules. In a commercial world, for some reason or another, the network operators either cannot or do not want to enforce the rules. If the network operators are able to enforce usage rules, that can make a difference without resorting to any changes in the underlying architechture. I is simply not possible to go back to the old assumption. We cannot effectively limit any particular user to NOT use the Internet. True, ISPs and the law can chase the guy round but he can run, he can hide and he can change his end point at will. How about network operators being able to enforce rules, as you suggest above, could that make a difference *without* resorting to any changes in the underlying architecture? Well, as you yourself wrote today in another thread, no. I share your concerns: My concern with your approach is with the fact that SPs can employ such measures against someone else without proof, simply cutting off connectivity for some stupid reason and blaming it on not handling abuse reports. What about ISPs erring on the side of caution and cutting off an entire netblock? Is there a provision for an accused pollutor to appeal the decision against the SP that is employing the practice? These are some of the questions that come up off-hand, I will be more than happy to discuss the entire document in detail with you off-list. Even in the real world, while there are consequences for actions, there are numerous checks and balances that make sure that the right person is actually punished for the actions that he or she actually did. This is why we have courts, appeals, clemency, etc. to mention a few. The same checks and balances must be applied in any similar mechanisms in the Internet arena. The problem is that these checks and balances make the process slower. This is where we move away from the technical issues and into the human ones, and this is where its gets very heated and political. It is thus a rather weak argument to talk about actions that have consequences in terms of a technical solution that the IETF can pursue to save the old design based on an enforceable honor system. The consequences would need to be arbitrated and we know how long, ineffective and expensive that can be. We can't go back to the explicit trust present in the early Internet. As Stef has mentioned, the DARPA Internet was more like a network than a network of networks. The Internet has no staff or sysadmin that would approve/remove users and enforce rules. The solution to spam lies squarely in the IETF hands. We need an Internet design where the end points are less trusted than the connection. The opposite of what we have today. Only then, IMHO, can we have those kind of solutions that the IETF can take on in order to really reduce the problem. Of course, updating the Internet design to fit its current operating conditions is useful not only to stop spam. Social engineering and spoofing attacks also rely on the old honor system where users are trusted. Trust no one should be the initial state under the new Internet paradigm. Comments? Cheers, Ed Gerck
Re: Apology Re: Principles of Spam-abatement
Dr. Jeffrey Race wrote: I just want to move the discussion from the present 'make the victims pay' model to the only one that will ever work, viz. 'make the polluters pay'. This reminds me of that story where the purported polluter (the lamb) was downstream but was killed anyway by the enforcer (the lion who was drinking upstream)...because the polluter had no power to resist the enforcer, even though the polluter could not pollute upstream... The Internet is to the user and the SPs like that lamb is to that lion. The user is the weak party and we should not have a standard that, once again, leaves the weak party exposed under the assumption that the other party is somehow trusted. Trust no one should be the initial state of the solution, for any solution. BTW, how can we talk about actions that have consequences in terms of a technical solution that the IETF can pursue? The consequences are not technical. In addition, they would need to be arbitrated and we know how long, ineffective and expensive that can be. It is fun, easy to do, shows fast results, and is proven by thousands of years of experience. ??? Cheers, Ed Gerck
Re: Apology Re: Principles of Spam-abatement
On Mon, 15 Mar 2004 18:12:22 -0800, Ed Gerck wrote: BTW, how can we talk about actions that have consequences in terms of a technical solution that the IETF can pursue? The whole point is there are NO TECHNICAL SOLUTIONS and never will be. (There are some technical aspects to improving traceability, however.) IETF would not apply the consequences; the victims would apply the (behavioral) consequences using established guidelines, employing technical measures already established in RFCs. IETF and other standards bodies can bless agreed procedures for using the existing technical steps in new behavioral ways. There are two reasons this is crucial: 1) Courts often, perhaps usually, defer to declared norms of industry standards bodies, in establishing reasonableness of disputed behavior. We can be decisive in establishing these norms. The courts can't easily act to use the COMPLETELY ADEQUATE EXISTING LAWS in part because of this lacuna. 2) Normative documents, and personal leadership, convert a group or a mob into an emergent structure (say a business firm, a dance company, a charitable organization, a military unit, a religious order, a teen gang) in which the norms absolutely bind the behavior of the participants, even to death. I say, in a completely non-deprecating way, that these points from law and sociology may not be apparent to engineers (or in fact to anyone else who is not an attorney or a sociologist) but they are completely true and completely binding on human behavior. The consequences are not technical. In addition, they would need to be arbitrated and we know how long, ineffective and expensive that can be. No arbitration needed. Please re-read the proposal. My proposal (which received input from many people) is basically just common sense. That's what we need now. The answers are in. The proof is in. Let's do it. Now. Jeffrey Race
Re: Apology Re: Principles of Spam-abatement
Dr. Jeffrey Race wrote: On Mon, 15 Mar 2004 18:12:22 -0800, Ed Gerck wrote: BTW, how can we talk about actions that have consequences in terms of a technical solution that the IETF can pursue? The whole point is there are NO TECHNICAL SOLUTIONS and never will be. (There are some technical aspects to improving traceability, however.) Actually, as discussed in another thread, there IS a technical solution for spam. The technical solution is based on strongly reducing the *possibility* of undesired actions (spam) to exist. You don't have to talk about consequences if you deny the very conditions that allow the undesired action (spam) to exist. Yeah, of course, there will still be the occasional message from a stranger that is not what it purports to be. But, at least, MTAs and MUAs would not greet that stranger and their MTA with open doors. The needed Internet paradigm, to do this, is trust no one. As any parent knows, it is a lot better to make the undesired action unlikely than to enforce consequences for the undesired but likely action. IETF would not apply the consequences; One more reason for the IETF to stay away from mandatory retaliation (aka consequences). the victims would apply the (behavioral) consequences using established guidelines, employing technical measures already established in RFCs. The victims are the least qualified parties to apply the retaliation you suggest. This principle is well-established in history and legal systems worldwide. That's why we have attorneys, court system, judges, jury, appeals, etc. IETF and other standards bodies can bless agreed procedures for using the existing technical steps in new behavioral ways. There are two reasons this is crucial: 1) Courts often, perhaps usually, defer to declared norms of industry standards bodies, in establishing reasonableness of disputed behavior. We can be decisive in establishing these norms. The courts can't easily act to use the COMPLETELY ADEQUATE EXISTING LAWS in part because of this lacuna. Are you a lawyer? It turns out that we the majority of the legal opinion is that, at least in those countries with common law such as the U.S., much of the legislation already in place for paper records and paper transactions also applies to electronic records. For example, when Telex was introduced, UK court decisions rejecting attempts to repudiate Telex contracts were based on jurisprudence and laws for contracts made using paper. Telegrams with their electronic dih-dhas were also used (and are used until today!) under the rule of legal evidence. 2) Normative documents, and personal leadership, convert a group or a mob into an emergent structure (say a business firm, a dance company, a charitable organization, a military unit, a religious order, a teen gang) in which the norms absolutely bind the behavior of the participants, even to death. to death seems a bit extreme, but I agree spam is a problem. I say, in a completely non-deprecating way, that these points from law and sociology may not be apparent to engineers (or in fact to anyone else who is not an attorney or a sociologist) but they are completely true and completely binding on human behavior. Nothing is 'completely true' or 'completely binding' in law or sociology. They are not exact sciences. This is not Pithagoras' formula. While I appreciate your efforts to be emphatic, infallibility is often denied by facts even in engineering ;-) The consequences are not technical. In addition, they would need to be arbitrated and we know how long, ineffective and expensive that can be. No arbitration needed. Please re-read the proposal. I did, some time ago. Hence my comment. No arbitration means liability. Who wants it, in business? My proposal (which received input from many people) is basically just common sense. That's what we need now. The answers are in. The proof is in. Let's do it. Now. I am sure you know that common sense is not that common ;-) That's why I believe there must be great caution and moderation in all of this. Cheers, Ed Gerck
Re: move to second stage, Re: Principles of Spam-abatement
AHA! Thanks Ed;-)... That is the best expose' of the current situation that I have so far seen. I would like to add that this outcome was possible because at the time of SMTP/RFC822 conception and standardization in the early '80's, the ARPA/NSF Internet had an Honor System based on the fact that access was controlled for all users by ARPA/NSF. Untrustworthy users were subject to loss of their access rights. Any use of the net was clearly a granted privilege! Also, the IETF had not yet been conceived, let alone established at that time. Its predecessor, if it might be called that, was the ARPA Contractors Meeting. As I recall, RFCs 822/821 were completed in 1982 around the time that IP/TCP was put into wide use after the great conversion date when the net was shut down for the last time, and NCP was decommissioned to enable IP/TCP to introduce the new Internet in place of the original ARPAnet. IETF was firmed up in 1986 to work on Internet protocols and coordination. The original Appropriate Use Policy of ARPAnet was modified somewhat in 1987 when NSFnet took the lead in continued Internet development, and NSF maintained the AUP which served to instill trust because any user in those days could be denied access rights if caught behaving badly contrary to the AUP. NSF dropped the AUP in 1994 as access was opened up to all who could afford it and the trustworthiness of the internet has gone downhill ever since because there is no longer any obvious incentive to inhibit bad behavior. Reasonable trustworthiness is no longer a hallmark of all Internauts. We all know that there are many bad apples in the barrel. I appears that the IETF did not foresee the fact of loss of trust, and did not foresee the affects such loss would have on everything, until now. And so, perhaps all the major IETF standards need to be reviewed for upgrading to deal with the almost complete loss of internet-user trust and Internet System Trust. This is why I would designate Inter-system and Inter-personal trust induction as the major paradigm shift to be navigated in this first decade of the New Millennium. Unfortunately, it appears that the shift of paradigms might be a bigger adjustment than we are ready to address. But, the fact is that our old trust has been lost, and something new is desperately needed, as seems clear from this discussion thread... I hesitate to spout off and claim that the first thing to be done regarding trust is to find a definition that we all can embrace so we will be able to work together on the same problems. But I strongly believe that trust needs to be well defined before we mount a search party to find it and bring it home to our beloved Internet. Without a good definition, we will be reduced to what might look like 2000 monkeys all trying to have sex with a football. Cheers...\Stef ++ At 22:22 -0800 3/13/04, Ed Gerck wrote: Yakov Shafranovich wrote: This discussion got me thinking about the need to state clearly that the IETF's goal is not to solve the spam problem. Inadequate design cannot be corrected? The *possibility* of spam is due to an Internet design based on an honor system for the end points. The model being that the connection was less trusted than the end points. Access to the end points was granted under an honor system and usage rules were enforceable. Reality showed that the model was upside down for commercial operation. The end points cannot be controlled and are in fact less trusted than the connection. Anyone can connect to the network. There is no honor system. Usage rules are not enforceable -- users can hide and change their end points. What I read above is denial that the spam problem was made possible by a design developed under the auspices of the IETF. This is good but can I motion that we now move to the second stage of problem solving? Cheers, Ed Gerck
The right to refuse, was: Re: Principles of Spam-abatement
On 14-mrt-04, at 2:49, Yakov Shafranovich wrote: This is the IETF - an organization that sets some of the standards for the Internet. What should the IETF be doing and NOT doing be in the fight against spam. Spam is only one example of communication that is desired by the sender but not the receiver. Port scans and denial of service attacks are two others. The current way for a receiver to handle this is to discard the unwanted communication after receiving it. This is far from ideal as it doesn't free the receiver from having to receive, but rather adds insult to injury by forcing the receiver to do even more work and figure out which communications are legit and which aren't. Malicious senders then go on to frustrate this process by making their unwanted communications look like legitimate ones. What we need here is a fundamentally different approach: one where desired communication is tagged as such explicitly. This allows intermediaries to block undesired communication on behalf of the receiver much closer to the sender, which in turn makes it possible for a service provider to determine accurately whether a customer is exhibiting malicious behavior. (And for other service providers to determine whether a service provider is taking steps against such customers.) The unsolved problem here is how to allow enough communication to be able to set up new desirability tags without creating a loophole that's big enough to invalidate the entire mechanism. This part is probably easier to do for IP than for email, as with IP there are many intermediaries (that can't be circumvented) and many individual packets, while for email intermediaries are largely optional and the number of messages between any combination of sender and receiver is low.
Re: The right to refuse, was: Re: Principles of Spam-abatement
On Sun, 14 Mar 2004 11:12:12 +0100, Iljitsch van Beijnum wrote: What we need here is a fundamentally different approach: one where desired communication is tagged as such explicitly. You are right a different approach is needed, but not this one because it does not admit communication from strangers. The only solution is one which removes from connectivity those who dump their trash on the commons. This is easy to do. Jeffrey Race
Re: The right to refuse, was: Re: Principles of Spam-abatement
On 14-mrt-04, at 12:49, Dr. Jeffrey Race wrote: What we need here is a fundamentally different approach: one where desired communication is tagged as such explicitly. You are right a different approach is needed, but not this one because it does not admit communication from strangers. I addressed this part at the end of my message. A mechanism to allow strangers to get hold of a desirability tag would of course be included. (If the holder of a tag misbehaves the tag is invalidated, of course.) With the above in place the problem scope is reduced to communication attempts from strangers, which pretty much solves the problem for IP, but not to the same degree for mail. The only solution is one which removes from connectivity those who dump their trash on the commons. This is easy to do. I don't think there are any easy answers here. If there were, they would have long since be implemented. What I think could work is a framework that allows different people to impose different requirements on strangers that want to send them mail. This has the advantage that different groups can choose different solutions that work well for that group. For instance, some groups may want to implement a PGP/GPG web of trust. Others may want to require a micropayment, and yet others solving a puzzle. By keeping the particulars outside of the mail protocols it should be simple to add new mechanisms so the arms race between spammers and victims could start losing its hare/turtle characteristics.
Re: The right to refuse, was: Re: Principles of Spam-abatement
At 07:56 AM 3/14/2004, Iljitsch van Beijnum wrote... On 14-mrt-04, at 12:49, Dr. Jeffrey Race wrote: You are right a different approach is needed, but not this one because it does not admit communication from strangers. I addressed this part at the end of my message. A mechanism to allow strangers to get hold of a desirability tag would of course be included. (If the holder of a tag misbehaves the tag is invalidated, of course.) If a stranger can get a tag, then it is useless, as there is nothing to stop a spammer from repeatedly getting new tags as old ones are invalidated. Basing them on source domain, IP, etc. makes no difference, as these are already frequently changed. It also requires creation of an entirely new authority and infrastructure to handle creation and distribution of these tags. Specifics, please, if you don't feel this is the case.
Re: The right to refuse, was: Re: Principles of Spam-abatement
From: Dr. Jeffrey Race [EMAIL PROTECTED] On Sun, 14 Mar 2004 11:12:12 +0100, Iljitsch van Beijnum wrote: What we need here is a fundamentally different approach: one where desired communication is tagged as such explicitly. You are right a different approach is needed, but not this one because it does not admit communication from strangers. That is true in both theory and practice. The only solution is one which removes from connectivity those who dump their trash on the commons. This is easy to do. That is true in theory. In practice it has been difficult. I'm not referring to the lies and whines of spammers and address block hijackers. There are big problems getting slumlords to evict tenents that throw their garbage and slops out their tenement windows onto the commons. UUnet is the classic case, with its years of claiming to be unable to act because it is unable to know from which window of which tenement any given stinking mess came (i.e. check RADIUS logs or count SYNs to outside port 25 and decide which of its resellers resold bandwidth to the spammer). When respectable people unilaterally shun all residents of a tenement with many spammers, we are greeted with demands for government and IETF intervention to stop our vigilante terrorism and redress our violation of the fundamental right to a free lunch. It has been suggested that something the IETF could do is define terms. It would help a lot if there were an official term describing the consumer level service intended for little more than web browsing, with often AUPs that prohibit servers, and often with blocks on port 25. People who want real Internet connectivity wouldn't howl when they don't get it after not paying for it. Consumer level doesn't quite work for me, since the a consumer might want the real thing and a business might not. No servers isn't quite right because it's SMTP clients that port 25 filters disable. The IETF needs to admit to itself and the world that the IP addresses assigned to many cable modem and DSL providers are beyond the edges of the Internet where the End to End Principle applies. Whether anyone likes it or not, they are not connected to the Internet. They might answer ICMP echo requests and they're better connected than hosts on the UUCP network were, but hosts on the UUCP network is what they are like. There is a pressing need to admit and publish this fact to forestall governments saving the situation. Contrary to the cries of the free lunch crowd, government regulation would try to reduce everyone's connectivity to their pale imitation than to give them the real connectivity they demand. Vernon Schryver[EMAIL PROTECTED]
Re: The right to refuse, was: Re: Principles of Spam-abatement
Vernon Schryver wrote: From: Dr. Jeffrey Race [EMAIL PROTECTED] ... The only solution is one which removes from connectivity those who dump their trash on the commons. This is easy to do. That is true in theory. In practice it has been difficult. I'm not referring to the lies and whines of spammers and address block hijackers. There are big problems getting slumlords to evict tenents that throw their garbage and slops out their tenement windows onto the commons. UUnet is the classic case, with its years of claiming to be unable to act because it is unable to know from which window of which tenement any given stinking mess came (i.e. check RADIUS logs or count SYNs to outside port 25 and decide which of its resellers resold bandwidth to the spammer). When respectable people unilaterally shun all residents of a tenement with many spammers, we are greeted with demands for government and IETF intervention to stop our vigilante terrorism and redress our violation of the fundamental right to a free lunch. This is a human problem, not a technical one - the ISPs are unwilling in many cases to handle abuse reports seriously, or are unwilling to invest in any kind of infrastructure to detect abuse. For example, one of the ideas floating around the ASRG has been a BCP for handling hijacked machines. A detection mechanism would be in place that counts outbound email from a given machine or subscriber, and if that usage spikes the mail would be queied and the subscriber notified. How many ISPs actually willing to do that (although ComCast begun shutting down accounts of hijacked machines)? What monetary incentive would the ISPs have to do that? And even if the IETF publishes the BCP, there is no way to enforce it. I do not see how the IETF can do anything to force ISPs to handle abuse complaints more seriously. This is why people tend to to block ISPs and IP blocks unilaterally in order to force ISPs to take action (not to say that I necessarily agree with it). The only two things that I see here that can be done by the IETF is either to facilitate easier abuse handling by ISPs via standard formats for abuse reports; or provide some kind of standards for exchanging reputation data among receivers. Both still rely on the human decisions made by both ISPs and receivers on how this data is used. Yakov
Re: The right to refuse, was: Re: Principles of Spam-abatement
Iljitsch van Beijnum wrote: On 14-mrt-04, at 12:49, Dr. Jeffrey Race wrote: ... The only solution is one which removes from connectivity those who dump their trash on the commons. This is easy to do. I don't think there are any easy answers here. If there were, they would have long since be implemented. What I think could work is a framework that allows different people to impose different requirements on strangers that want to send them mail. This has the advantage that different groups can choose different solutions that work well for that group. For instance, some groups may want to implement a PGP/GPG web of trust. Others may want to require a micropayment, and yet others solving a puzzle. By keeping the particulars outside of the mail protocols it should be simple to add new mechanisms so the arms race between spammers and victims could start losing its hare/turtle characteristics. The IETF can develop standards for such framework, and in fact the ASRG has been discussing at some point various schemes to do so such as an extensible web of reputation, ability to mail sender and receivers to exchange information about what type of payment/trust token/etc. is needed prior to delivery, etc. The decision to remove connectivity from those who dump the trash is one made by humans, and not standards. We can create standards to provide information that can be then used to make those decisions, but we cannot force any network players to make these decisions. Yakov
Re: move to second stage, Re: Principles of Spam-abatement
Ed Gerck wrote: Yakov Shafranovich wrote: This discussion got me thinking about the need to state clearly that the IETF's goal is not to solve the spam problem. Inadequate design cannot be corrected? The *possibility* of spam is due to an Internet design based on an honor system for the end points. The model being that the connection was less trusted than the end points. Access to the end points was granted under an honor system and usage rules were enforceable. Reality showed that the model was upside down for commercial operation. The end points cannot be controlled and are in fact less trusted than the connection. Anyone can connect to the network. There is no honor system. Usage rules are not enforceable -- users can hide and change their end points. The original design relied on the human assumption that someone would enforce the rules. In a commercial world, for some reason or another, the network operators either cannot or do not want to enforce the rules. If the network operators are able to enforce usage rules, that can make a difference without resorting to any changes in the underlying architechture. What I read above is denial that the spam problem was made possible by a design developed under the auspices of the IETF. The design is not what caused the problem, its one of the factors that is contributing to the problem. All I am saying is that the IETF's role is limited to the standards-related solutions. This is good but can I motion that we now move to the second stage of problem solving? Go ahead - I am looking for any kind of solutions that the IETF can take on in order to reduce the problem. Many solutions have been revolving around trust - but in the world where a computer can be easily hijacked, trust becomes harder to maintain. One example of what the ASRG has been looking at is a distributed web of reputation. Each MTAs or domain can publish a list of MTAs that it knows, including basic statistics on how long the MTA has been sending mail, average volume, etc. In addition to that basic information, you can also publish additional information such as I think this is a spammer because SpamAssasin detects 99% of all email from that MTA as spam, etc. The basic statistical information can be used to detect zombies and the extended information can be used to allow like-thinking domains to make joint decisions. The question of how much difference this would make is up for debate, and there are questions of how a new MTA can be introduced into the system, rule of the mob, etc. Yakov
Re: move to second stage, Re: Principles of Spam-abatement
Einar Stefferud wrote: NSF dropped the AUP in 1994 as access was opened up to all who could afford it and the trustworthiness of the internet has gone downhill ever since because there is no longer any obvious incentive to inhibit bad behavior. Reasonable trustworthiness is no longer a hallmark of all Internauts. We all know that there are many bad apples in the barrel. I appears that the IETF did not foresee the fact of loss of trust, and did not foresee the affects such loss would have on everything, until now. And so, perhaps all the major IETF standards need to be reviewed for upgrading to deal with the almost complete loss of internet-user trust and Internet System Trust. This is why I would designate Inter-system and Inter-personal trust induction as the major paradigm shift to be navigated in this first decade of the New Millennium. Unfortunately, it appears that the shift of paradigms might be a bigger adjustment than we are ready to address. But, the fact is that our old trust has been lost, and something new is desperately needed, as seems clear from this discussion thread... There is also a possible conflict between the need for trust and the end to end principle, as mentioned in (http://www.iab.org/documents/drafts/draft-iab-e2e-futures-05.txt). Yakov
Re: The right to refuse, was: Re: Principles of Spam-abatement
From: Yakov Shafranovich [EMAIL PROTECTED] ... This is a human problem, not a technical one - the ISPs are unwilling in many cases to handle abuse reports seriously, or are unwilling to invest in any kind of infrastructure to detect abuse. For example, one of the ideas floating around the ASRG has been a BCP for handling hijacked machines. A detection mechanism would be in place that counts outbound email from a given machine or subscriber, and if that usage spikes the mail would be queied and the subscriber notified. The ISP can't queue mail that doesn't go through its smarthosts. It can only block port 25. That generally causes mail to be lost, whether from legitimate MTAs to distant MUAs or from spamware. How many ISPs actually willing to do that (although ComCast begun shutting down accounts of hijacked machines)? What monetary incentive would the ISPs have to do that? And even if the IETF publishes the BCP, there is no way to enforce it. At $30/month, an ISP can't afford to do much watching for spikes. It certainly can't hold the hands of users who couldn't be bothered to install virus defenses or not open attachments. About all that a consumer grade ISP can afford to do is preemptively block outgoing port 25, 135, etc. for all customers. I've been complaining for years that is slum tenement Internet service, but it seems to all that must users are willing to pay for, in money and in acquiring and using technical expertise (e.g. virus filters and not opening attechments). If the IETF would officially define slum tenement Internet service (with better words, of course), then truth in advertising laws, the value of product differentiation to ISPs, and savvy users might make port 25 filtering universal where it is needed and absent elsewhere. That would stop lunacy like blacklisting any IP address whose reverse DNS name contains the substring dsl. I do not see how the IETF can do anything to force ISPs to handle abuse complaints more seriously. This is why people tend to to block ISPs and IP blocks unilaterally in order to force ISPs to take action (not to say that I necessarily agree with it). The only two things that I see here that can be done by the IETF is either to facilitate easier abuse handling by ISPs via standard formats for abuse reports; ISPs don't need to exchange abuse reports, but to deal with their own. There's no value in standardizing the unidirectional stream of abuse reports from the spam-hostile part of the Internet to the spam friendly part that largely ignores reports of abuse. or provide some kind of standards for exchanging reputation data among receivers. Both still rely on the human decisions made by both ISPs and receivers on how this data is used. Exchanging reputation about receivers makes as little sense as announcing consent to receive mail or solving spam with authentication. You can't trust people to announce their own reputations or to obey your announced refusal to receive spam. Reputation exchanges are either systems like TrustE's that in practice certify untrustworthiness and functional equivalents of the current DNS blacklists. Wise blacklist operators, and I think all major blacklist operators do not, could not, and would not have any reputations to exchange. You can add to your backlist only based on evidence that you can defend in court. Reports from outsiders, including users of your blacklist, are almost useless. Vernon Schryver[EMAIL PROTECTED]
Re: The right to refuse, was: Re: Principles of Spam-abatement
Vernon Schryver wrote: From: Yakov Shafranovich [EMAIL PROTECTED] ... How many ISPs actually willing to do that (although ComCast begun shutting down accounts of hijacked machines)? What monetary incentive would the ISPs have to do that? And even if the IETF publishes the BCP, there is no way to enforce it. At $30/month, an ISP can't afford to do much watching for spikes. It certainly can't hold the hands of users who couldn't be bothered to install virus defenses or not open attachments. About all that a consumer grade ISP can afford to do is preemptively block outgoing port 25, 135, etc. for all customers. I've been complaining for years that is slum tenement Internet service, but it seems to all that must users are willing to pay for, in money and in acquiring and using technical expertise (e.g. virus filters and not opening attechments). I agree with you - most ISPs do not have enough profit to do anything other than unilateral measures like port blocking. Another similar unilateral measure that very few ISPs started doing is to shut off accounts of customers with hijacked machines. One of my family members has an account with AceDSL, a small DSL provider in NYC, and had his account suspended because one of the computers in the house has been infected with a worm (Comcast claims to have started doing that with hijacked machines used for spam). Of course, this like port blocking is a rather harsh measure which might not be profitable for an ISP for an ISP to do in the long run. If the IETF would officially define slum tenement Internet service (with better words, of course), then truth in advertising laws, the value of product differentiation to ISPs, and savvy users might make port 25 filtering universal where it is needed and absent elsewhere. That would stop lunacy like blacklisting any IP address whose reverse DNS name contains the substring dsl. I am not sure if it's the IETF's role to define such definition. But in any case, the problem is that given the current situtation that ISPs do not have sufficient incentive to deal with the problem at the end points, is there anything that the IETF can really do aside from providing some standards and publishing BCPs? I do not see how the IETF can do anything to force ISPs to handle abuse complaints more seriously. This is why people tend to to block ISPs and IP blocks unilaterally in order to force ISPs to take action (not to say that I necessarily agree with it). The only two things that I see here that can be done by the IETF is either to facilitate easier abuse handling by ISPs via standard formats for abuse reports; ISPs don't need to exchange abuse reports, but to deal with their own. There's no value in standardizing the unidirectional stream of abuse reports from the spam-hostile part of the Internet to the spam friendly part that largely ignores reports of abuse. Given that most ISPs do not make that much profit, what anything change in the long run about their ignorance of abuse reports? Yakov
Re: The right to refuse, was: Re: Principles of Spam-abatement
From: Yakov Shafranovich If the IETF would officially define slum tenement Internet service (with better words, of course), then truth in advertising laws, the I am not sure if it's the IETF's role to define such definition. There are plenty of RFCs that consist of little more than definitions of terms. In a real sense, any standards track RFC is merely a list of definitions of terms. If the IETF has no business defining terms to name existing varieties of Internet service, then it certainly has no business publishing BCPs telling people how to provide Internet services, including how to run blacklists. But in any case, the problem is that given the current situtation that ISPs do not have sufficient incentive to deal with the problem at the end points, is there anything that the IETF can really do aside from providing some standards and publishing BCPs? A definition of what they're doing and the truth in labeling laws could give them some incentives. If ISPs offering slum Internet service would admit that's what they're selling, they could preemptively block port 25 and stop a large part of today's spam, worms, and viruses. The majority of their customers would not notice any difference, except fewer spam, worms, and viruses. Contrary to claims from some ISPs, filtered Internet service is not technically difficult or expensive to provide. In fact it is significantly cheaper, because it uses less bandwidth and abuse desk labor. That is why many ISPs offer it instead of real Internet service. (Some do try the cheaper and less honest tactic of submitting their own IP addresses to so called dynamic blacklists so that they don't need to hire help to configure their routers to block outgoing TCP SYNs to port 25.) Those users that did complain could be pointed at AUPs that often today prohibit the use of servers and offered upgrades to accounts with prices that allow ISPs to deal with the risk of abuse. That higher price might still be $30/month but with a $3000 bond. Or perhaps $300/month for the first 6 months and $30/month thereafter. As someone said privately, the slumlord ISPs are not only skipping on abuse desks. They also don't have valid SWIPEs, reverse DNS names, NTP or NNTP servers, monitoring to meet the SLAs they almost claim to offer and other services that come with real Internet service. Given that most ISPs do not make that much profit, what anything change in the long run about their ignorance of abuse reports? The Internet is being separated into two parts. One part is of spam filled slums that cannot send mail directly to the other part. That is the common purpose of DNS blacklists and port 25 filters. Whether you admit that fact and whether you say slum tenements and real Internet or spiritual heir to UUCP and transitive closure of direct SMTP connectivity doesn't change anything but the politics. What is needed is for the IETF to try to prevent politicians, government bureaucrats, and slumlord ISPs from colluding to regulate the whole Internet down into the tenement slums. There are interests that would love to see laws funnel all mail sent through Microsoft/AOL/Verisign servers (probably using a form of PKI cert). Spooks, spies, and police state officials would find those servers as convenient as monopolists would find them profitable. Vernon Schryver[EMAIL PROTECTED]
Re: Principles of Spam-abatement (fwd)
On Sun, 14 Mar 2004, Dr. Jeffrey Race wrote: On Sat, 13 Mar 2004 17:03:14 -0500 (EST), Dean Anderson wrote: No such thing was ever found. And just the opposite was proved to you in Exactis V. MAPS. That lawsuit was settled out of court, Dean you have expressed your case well but in the end you must agree none of this is persuasive because the case was never litigated on its merits. The principle defense was resolved before trial. MAPS only defense (First Amendment Privilege) was rejected before trial. The Court in the Temporary Restraining Order accepted the validity of the case presented by Exactis if all the facts were true. MAPS didn't contest any of the facts--they were all true. Another telling feature is the chastisement of MAPS attorney. With a set of uncontested facts, and no defense, what remains of that case is purely procedure and final judgement, which must then involve the court in the messy business of calculating awards and issuing injunctive orders. We have only he said, she said; maybe MAPS folded for lack of money or some other reason unrelated to the merits; happens all the time. No, that isn't the case, as can be seen from the records and transcripts in the Lawsuit. It is true that one cannot cite a finding in Exactis V. MAPS, because a _judgement_ was not made, and so will not appear in any legal record, however, it is not the case that we don't have any clue about the merits of the argument. There were definite legal decisions made, and the unusual act of chastising MAPS lawyer. I have been hoping for this issue to be litigated to a judgment but this has not happened to my knowledge. Only 1% of cases filed are ever brought to trial. Lawyers are expected to resolve frivolous disputes. Truly frivolous claims do not even make it to a filing in most cases. Most disputes are resolved this way: http://info.av8.net/spamstuff/verio-demand.pdf Followed by a post by Mr. Guilmette: http://info.av8.net/spamstuff/RFG-Verio-Email It may be significant (someone who knows more correct me) that even though there is more blocking now than then, no one affected has ever seen fit to sue on like grounds since them. Please correct me if I am wrong. There is substantially less blocking now by respectable blacklists. MAPS has not blocked any commercial entity since this lawsuit. Even the current complaint about Vixie doesn't involve MAPS, but Vixie's _personal_ blacklist. Vixie is offering SORBS service via ISC.ORG, while trying to pretend that he has no association with SORBS. SORBS is ostensibly located in Australia, by Matthew Sullivan, and adminstrator with the University of Queensland. Sullivan claims to have no assets. Indeed, the blacklist proponents have taken to trying to create lawsuit free, or lawsuit difficult sites by locating them in remote countries, and by having poor people who have no assets assume legal responsibility for them. Of course, as Joe Praad (attorney who has represented AOL in spam suits) has shown, this is no protection from the law. But Mr. Guilmette then goes on in another message to say that the law is not going to be on the side of blacklists (quite obviously) = MAPS has proven that the legal threat (against DNSbls) cannot be con- fronted directly or frontally. Any half-way competent General in this battle should take from this the obvious lesson that flanking maneuvers are clearly better than frontal assults in such contexts. Meanwhile, my encounter with Verio Corporate Counsel has illustrated, I believe, that it is possible to generate negative PR for lawsuit-happy companies whose total costs will exceed the costs of just fixing their spam prob- lems. This is a profoundly Good Thing, because in the long run, costs (as measured in dollars, yen, rubles, sheckels, rupies, whatever) are the _only_ thing that most corporations care about, and as the case of Verio illustrates[2], it doesn't take them long to understand that they cannot win the game when it is played this way. = The whole message at http://info.av8.net/spamstuff/RFG-Law-no-good-email pretty much lays out what the current strategy of the radicals has been. They hope that by having poor people assume legal responsibility for the illegal behavior, that they can impose costs on corporations who will have to pursue the unlawful behavior, but will be unable to recover their costs from poor people. The radical anti-spammer are nothing but a pack of liars and hypocrits promoting lies and conducting mailbombing attacks. It is not a far stretch to suspect that they are also the ones responsible for the viruses that are mailbombing millions of people with billions of messages. Dean Anderson CEO Av8 Internet, Inc
Re: The right to refuse, was: Re: Principles of Spam-abatement
On Sun, 14 Mar 2004, Yakov Shafranovich wrote: This is a human problem, not a technical one - the ISPs are unwilling in many cases to handle abuse reports seriously, or are unwilling to invest in any kind of infrastructure to detect abuse. This isn't true. Certainly, it is not representative of the industry. Over the years, I've submitted many reports of abuse of our relays to many other ISPs, and only in a few cases have run into admins (but rarer still ISPs) who were unwilling to help. In those few cases, the admins turned out to be radical antispammers, who thought it was OK to abuse open relays. Of course, when escalated beyond those admins, the ISP's felt differently. The only people that have ever refused to cooperate are anti-spammers. I have run into admins who simply weren't competent to track the abuse and needed help, but that is a rarity. Also, the blacklists (SpamCop is a particularly egregious abuse of this) alter the emails in their reports or do not include logs. Altered email quite obviously cannot be accepted. Quite obviously, no one is going to terminate a customer without any evidence. But that is exactly what radicals demand. But they are also frequently the abusers. For example, We've tracked open relay abuse to radical anti-spammers, and in at least one case, the abuser turned out to be in the abuse department of Verio, and was fired after repeated abuse. He claimed our relays were free for him to abuse. His legal department thought differently. Indeed, open relays provide no benefits to real spammers. We have also tracked who was searching for open relays, and again found only radical anti-spammers. I performed experiments by listing non-production servers with various lists, and then logging the connections to that IP. Connection rates skyrocketeed. Then closing and getting them delisted. Connection rates dropped off. Blocking the open relay sites greatly reduced the amount of abuse. But it seems that interest in open relays has also dropped off. Until last week, we hadn't had any abuse in a long time. So likely last week's abuse was also a group of radicals anti-spammers mailbombing. Mostly, its just the radical anti-spammers that perform abuse, and refuse to accept complaints about abuse. It is the radicals that are causing the problems, and they need to be dealt with--but there is no technical means to deal with them. They need to be dealt with legal means. Here is Bill Manning telling me he won't accept an abuse complaint regarding SORBS and ISC because he doesn't have a contract with us to do so. Most other ISPs accept abuse complaints. We had previously shown Mr. Manning a traceroute to SORBS which showed an address was allocated to ISC by EP.NET, for which Bill Manning is the contact, and a bounced message to [EMAIL PROTECTED] Paul Vixie is President of ISC.ORG. (the hypocrisy of this situation should be self-evident) Date: Wed, 14 Jan 2004 12:21:08 -0800 (PST) From: bill [EMAIL PROTECTED] To: Dean Anderson [EMAIL PROTECTED] Cc: bill [EMAIL PROTECTED] Subject: Re: Complaint regarding www.sorbs.net (204.152.186.189) (fwd) This was too cryptic to parse. Do you mean the mail does not bounce when you forwarded this to [EMAIL PROTECTED] I have no reason to act as your relay agent. We have no agreement in place for me to act in this manner. Do you mean that you don't think the following activities (from XO's AUP) violate your AUP? * Is unlawful, threatening, abusive, harassing, libelous, defamatory, obscene, deceptive, fraudulent, invasive of another's privacy, tortious, indecent, pornographic or inaccurate * Victimizes, harasses, degrades, or intimidates an individual or group of individuals on the basis of religion, gender, sexual orientation, race, ethnicity, age, disability or any other reason Or something else? I would also draw your attention that Vixie, in the guise of MAPS has previously been found to conduct just such activity in Exactis V MAPS, and was forced to stop. If you have an AUP, could you forward it to me? Our AUP applies to our customers and is available to them. Thanks, --Dean
Re: move to second stage, Re: Principles of Spam-abatement
Ed, Thank you for the wealth of information. I forwarded this message to the SMTP-VERIFY subgroup of the ASRG where the current discussion of the web of trust is taking place so we can evaluate the information (the archive can be found at http://news.gmane.org/gmane.ietf.asrg.smtpverify/). If you or anyone else wants to join that list, let me know off-list (its a closed list with about 30 members, separate from the main ASRG list). I will get back to you once we digested your paper. Yakov Ed Gerck wrote: Yakov Shafranovich wrote: Go ahead - I am looking for any kind of solutions that the IETF can take on in order to reduce the problem. Many solutions have been revolving around trust - but in the world where a computer can be easily hijacked, trust becomes harder to maintain. Trust is the problem [1]. What you mention below is a valid way to induce trust, namely by relying on trusted introducers (for trusted *and* distrusted MTAs). The question of qualifying the trusted introducers themselves is also qualitatively handled in the model you summarize. One thing that is missing is what I call the trusted witnesses, which are also necessary to induce trust [2]. Trusted introducers and trusted witnesses allow you to build two open-ended trust chains for every action, the witness chain providing the assurances (how did we get here?) that led to action (including the action itself) while the introducer chain (where do we go from here?) provides the assurances both for a continuation of that action and for other actions that may need assurances stemming from it. One example of what the ASRG has been looking at is a distributed web of reputation. Each MTAs or domain can publish a list of MTAs that it knows, including basic statistics on how long the MTA has been sending mail, average volume, etc. In addition to that basic information, you can also publish additional information such as I think this is a spammer because SpamAssasin detects 99% of all email from that MTA as spam, etc. The basic statistical information can be used to detect zombies and the extended information can be used to allow like-thinking domains to make joint decisions. The question of how much difference this would make is up for debate, and there are questions of how a new MTA can be introduced into the system, rule of the mob, etc. Seeing this as a web of trust would seem to clarify the issues you mention and point out what's missing. Relying on reputation alone (and not also on current behavior, etc.) can lead to race conditions, bait-and-switch, spoofing, laggard reactions, and a host of other threats that are easily exploitable. BTW, if reputation alone would be a solution, eBay customers would not have so many problems with online auctions -- the Federal Trade Commission says it receives more complaints about Internet auction fraud than any other online scam. Internet auctions accounted for 48 percent of all Internet fraud complaints filed with the commission in 2003 (1/26/04 article by Brian Krebs on eBay Feedback Forgers). Comments? Cheers, Ed Gerck [1] Understanding human trust is exactly what brought me to that great IT question in 1997: how can I trust a set of bytes? My answer provided a framework that has been useful in the field of information security. The answer also provides a framework for understanding human trust (as expected fulfillment of behavior) and bridging trust between humans and machines (as qualified information based on factors independent of that information). The original reference is http://nma.com/mcg-mirror/trustdef.htm -- please google for gerck trust to find applications and comments by others. [2] An example is described in http://nma.com/papers/e2e-security.htm#TR ...under the principle that every action needs both a trusted introducer and a trusted witness. We call this principle the Trust Induction Principle.
Re: The right to refuse, was: Re: Principles of Spam-abatement
On Sun, 14 Mar 2004, Yakov Shafranovich wrote: In any case, it seems IMHO that there exists a percentage of ISPs that either ignore or mishandle abuse reports. On the other hand there exists a percentage of ISPs that respond to abuse reports in a timely fashion. We seem to be in disagreement as to what those percentages are, but it seems to me that we all agree that both types of ISPs are present on the Internet today. Given that, should the IETF pursue development of standards to make abuse reporting easier to facilitate the work of those ISPs that actually do handle abuse reports properly? This is an example of something that we have been asking at the ASRG (http://asrg.sp.am/subgroups/abuse_reports.shtml). It is something within the scope of the IETF's charter, can possibly be useful for reducing spam by making it cheaper for some ISPs to handle abuse reports, and is not something that claims to solve the entire spam problem as a silver bullet. But clearly it is only a technical tool that facilitates the human solution to spam - handling abusers. The key question is whether the benefits provided by such standards justify the cost of implementing and developing them. This is of course something we can and probably should argue about. This is one of the many examples of things that the IETF can do that do not solve the overall problem, but are very well within the IETF's charter to make standards and can help with some aspects of the spam problem. Of course, we can argue about how much impact it will make vs. the cost of the solution, but that's something we should be doing anyway as part of sketching out such solutions in order to evaluate them properly. This is I think a very sane and appropriately limited thing for the IETF to tackle. As you note, it won't solve the spam problem, but then, nothing will as long as it is marginally profitable except possibly legislation and vigorous enforcement. Paper advertising junk mail (which costs roughly $1/piece or even more yet fills my mailbox daily) indicates that we aren't likely to be able to prevent spam by manipulating the profit margin side. Legislation is being advanced and test cases are appearing for existing legislation that might help, but spam is international and in some cases virus driven and hence difficult for real police to deal with. Filtering abates the problem for many if not most of us, and filtering doesn't require any action from the IETF but filter-based solutions are a constant war and a constant cost and bringing additional pressure to bear further upstream would be lovely if it were workable. I think that any sort of upstream attack on spam has to have several features to be successful: a) It has to have a uniform standard and basis. I think (if I understand Dean's earlier responses correctly) that having a uniform standard for taking various actions would provide valuable legal cover for SP-level enforcement while protecting them from antitrust accusations and the like. This the IETF can help with; indeed, there is nobody else that can, because although IETF recommendations and standards have no force in law they ARE the engineering basis for the internet and hence might be a bit more powerful than mere law in this particular context. b) It has to have buy-in from the SPs that will do the actual enforcement on the basis of standardized reports. c) Which in turn means that it has to be economical for them to enforce rather than ignore. d) Which requires tools that permit them to manage the work with a minimal investment in their time and resources and maximal automation. e) And very likely will require clearly spelled out SANCTIONS to be applied in the event that they refuse to enforce anyway. You'll have to draw a clear map of the road. You'll have to pave the road, put wheels on the cart, grease the axles, and show the donkey the map. You'll have to offer the donkey a carrot, and be prepared to beat the donkey with a stick and even make a drum out of its skin if it doesn't mosey down the road. And the donkey still might not move. This is the essence of Jeff Race's proposal (mentioned several times over the last few days) and seems like a very reasonable starting point for what you are proposing that the IETF do. Vernon suggested (IIRC) that similar proposals had been considered before, but hit the wall with SPs unwilling to invest the resources required for enforcement. I'm pretty skeptical. Vernon and Dean together have a good argument that doing nothing is preferrable to doing nearly anything that has been proposed so far in this discussion and that in time the problem may (like so many internet problems) prove to be fundamentally self-limiting even if we (the IETF) sit on our hands the entire time. Vernon has also pointed out in fairly acid tones that talk is cheap -- what is needed are specifications and software -- people doing actual
Re: Principles of Spam-abatement
On 13-mrt-04, at 3:48, Paul Vixie wrote: An intermediary who withdraws their consent can do so absolutely and your only recourse is to find a different intermediary -- which you can do absolutely, so long as you have their willingness to participate. I'm sorry, but this is nonsense. Now traditionally in IP networks we get away with lots of stuff, but do you think that something like this would hold up in the voice business? And like it or not, IP networks are becoming more and more like phone networks. If you don't mind dialing in you still get to choose between lots of ISPs (but what if your phone company decides to withdraw their willingness to participate in phone calls to ISPs they don't own?) but the same isn't true for broadband IP access. With great power (= wires, frequencies or just plain market share) comes great responsibility. (Things are slightly different for mail but not fundamentally so, especially as some ISPs are forcing their customers to use their relays.)
Re: Principles of Spam-abatement
Now traditionally in IP networks we get away with lots of stuff, but do you think that something like this would hold up in the voice business? voice is dominated by large players including some governments, and international interconnection seems to be regulated by the itu. if voice were full of mompop's the way IP is, then i daresay i would not be interrupted at my dinner hour by telemarketers nearly as often, simply because there would be no path from them to me. (Things are slightly different for mail but not fundamentally so, especially as some ISPs are forcing their customers to use their relays.) until the day a cable/dsl provider decides to block vpn access, none of that will matter. and since users of same working remotely with vpn access back to the office are a large part of the subscriber base, and are not a source of abuse, i do not expect them to block vpn's. with vpn's comes the freedom to do your business elsewhere (where it's safe) and use the cable/dsl line for access (as it seems to be intended) rather than for real internet (for which it seems ill suited.)
Re: Principles of Spam-abatement (fwd)
-- Forwarded message -- Date: Fri, 12 Mar 2004 19:27:42 -0500 (EST) From: Dean Anderson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Principles of Spam-abatement On 12 Mar 2004, Paul Vixie wrote: ultimately it was found that no law or regulation required carriage, and that an ISP (whether in the US, Canada, or EU) could subscribe to any blackhole list they wanted, and the only recourse any of their customers had was whatever was explicitly spelled out in their contracts. No such thing was ever found. And just the opposite was proved to you in Exactis V. MAPS. That lawsuit was settled out of court, and MAPS proponents like to pretend it didn't happen. However, before it was settled, there were some preliminary decisions made regarding the case. MAPS tried to have it dismissed on the grounds that MAPS had a first admendment right to say whatever they want. That argument was rejected, and is significant to continued claims by radicals of some First Amendment right to say whatever they want. Indeed, MAPS didn't contest any of the facts asserted. Those facts justified a Temporary Restraining Order. As a matter of legal procedure, a Temporary Restraining Order can only be granted if, after assuming all the facts asserted to be true, the case can succeed. A TRO is an important test of the merits of the case. The rest of a case is then a dispute over the facts and the defenses to them. Two legal teams (one for Vixie, one for MAPS) could only find a frivolous First Amendment defense, which was rejected. MAPS choice was clearly to settle or lose. MAPS attorney was chastised for the frivolousness of the dispute. This is a message to the attorney's of other blacklists, and was reported in many legal journals. I include a quote from one of the the Exactis V. MAPS briefs below, which is illuminating of anti-trust law. Besides antitrust law, there are state electronic communications privacy laws that apply. State laws broadly prohibit any interference with communciations, which is broad enough to include the blacklist. There are also a number of torts that can be brought, but I won't go in them here. Exactis V. MAPS is clearly a reference for blacklist cases. Of course, MAPS isn't an ISP, and while ISPs are also subject to anti-trust law either by contracting with blacklists or by becoming a member of the group, there are some differences in what laws apply to ISPs, and thus the legal constraints that ISPs operate under. Pretty much everything(torts, anti-trust, state law) that applies to a blacklist also applies to an ISP, and there are some more things that apply to ISPs. You can fairly say that if a blacklist can't win on this issue, an ISP doesn't have even a prayer---even God would chastise an ISP's lawyer for being frivolous. :-) The federal Electronic Communications Privacy Act (ECPA) applies to ISPs. There are number of cases in which claims were made under the ECPA. The closest case to ISP email issues is Konop V. Hawaiian Airlines. In Konop V. Hawaiian Airlines it was held that a password, giving access to a website obtained in violation of an agreement not to give anyone else access, did not represent the necessary authorization to access stored communications. Similarly, an ISP has passwords to mailservers and routers, and the authorization from customers to do certain things, but not to do other things. Merely having the root password does not mean that you have authorization to do whatever you please. On Fri, 12 Mar 2004, Vernon Schryver wrote: Your right to send mail stops at the border routers of your ISP. No, your right to send mail stops at the recipient's ISP and not before, and then only to the extent the recipient has granted some permission to the ISP. The Congress writes reports representing the intent of Congress and explaining complicated legislation. In the absence of specific case law binding the court, such reports are used to guide the court as to the intent of Congress when resolving any ambiguities on how to apply statutory language to specific sets of facts. House Report 99-647 reported on the Electronic Communications Privacy Act. There is also Senate Report 99-541. Radicals often try to mislead people into thinking that no laws apply to email or the internet. That is totally false. Regarding your privacy rights from House Report 99-647 says at page 33; Similarly, where a user has interconnected its own equipment into a private network, communications carried on the network are fully entitled to the provisions of Section 2511. The intent of Congress is pretty much dead on to the question of whether an ISP can do whatever it pleases. Your ISP has also connected its equipment to other private networks, which are subject to 2511, and so on. Email is frequently mentioned in both the House and Senate Reports. The following quote is from Statement of [Senator] Patrick Leahy on the Introduction of the Electronic
Re: Principles of Spam-abatement
I posted my original message to the IETF list for a reason instead of replying to Paul and Vernon privately. My question is really directed to all of you: This is the IETF - an organization that sets some of the standards for the Internet. What should the IETF be doing and NOT doing be in the fight against spam. Yakov P.S. For the record, I am one of the ASRG chairs. Dean Anderson wrote: Perhaps you should ask this question of someone who actually _has_ studied the problem for a number of years, and has reviewed the numerous legal cases and the full text of their legal decisions, and sometimes even the motions and briefs in the case, and has reveiwed the congressional reports, and even the congressional testimony on the record.
Re: Principles of Spam-abatement
On 12 Mar 2004, Paul Vixie wrote: ultimately it was found that no law or regulation required carriage, and that an ISP (whether in the US, Canada, or EU) could subscribe to any blackhole list they wanted, and the only recourse any of their customers had was whatever was explicitly spelled out in their contracts. No such thing was ever found. And just the opposite was proved to you in Exactis V. MAPS. That lawsuit was settled out of court, and MAPS proponents like to pretend it didn't happen. However, before it was settled, there were some preliminary decisions made regarding the case. MAPS tried to have it dismissed on the grounds that MAPS had a first admendment right to say whatever they want. That argument was rejected, and is significant to continued claims by radicals of some First Amendment right to say whatever they want. Indeed, MAPS didn't contest any of the facts asserted. Those facts justified a Temporary Restraining Order. As a matter of legal procedure, a Temporary Restraining Order can only be granted if, after assuming all the facts asserted to be true, the case can succeed. A TRO is an important test of the merits of the case. The rest of a case is then a dispute over the facts and the defenses to them. Two legal teams (one for Vixie, one for MAPS) could only find a frivolous First Amendment defense, which was rejected. MAPS choice was clearly to settle or lose. MAPS attorney was chastised for the frivolousness of the dispute. This is a message to the attorney's of other blacklists, and was reported in many legal journals. I include a quote from one of the the Exactis V. MAPS briefs below, which is illuminating of anti-trust law. Besides antitrust law, there are state electronic communications privacy laws that apply. State laws broadly prohibit any interference with communciations, which is broad enough to include the blacklist. There are also a number of torts that can be brought, but I won't go in them here. Exactis V. MAPS is clearly a reference for blacklist cases. Of course, MAPS isn't an ISP, and while ISPs are also subject to anti-trust law either by contracting with blacklists or by becoming a member of the group, there are some differences in what laws apply to ISPs, and thus the legal constraints that ISPs operate under. Pretty much everything(torts, anti-trust, state law) that applies to a blacklist also applies to an ISP, and there are some more things that apply to ISPs. You can fairly say that if a blacklist can't win on this issue, an ISP doesn't have even a prayer---even God would chastise an ISP's lawyer for being frivolous. :-) The federal Electronic Communications Privacy Act (ECPA) applies to ISPs. There are number of cases in which claims were made under the ECPA. The closest case to ISP email issues is Konop V. Hawaiian Airlines. In Konop V. Hawaiian Airlines it was held that a password, giving access to a website obtained in violation of an agreement not to give anyone else access, did not represent the necessary authorization to access stored communications. Similarly, an ISP has passwords to mailservers and routers, and the authorization from customers to do certain things, but not to do other things. Merely having the root password does not mean that you have authorization to do whatever you please. On Fri, 12 Mar 2004, Vernon Schryver wrote: Your right to send mail stops at the border routers of your ISP. No, your right to send mail stops at the recipient's ISP and not before, and then only to the extent the recipient has granted some permission to the ISP. The Congress writes reports representing the intent of Congress and explaining complicated legislation. In the absence of specific case law binding the court, such reports are used to guide the court as to the intent of Congress when resolving any ambiguities on how to apply statutory language to specific sets of facts. House Report 99-647 reported on the Electronic Communications Privacy Act. There is also Senate Report 99-541. Radicals often try to mislead people into thinking that no laws apply to email or the internet. That is totally false. Regarding your privacy rights from House Report 99-647 says at page 33; Similarly, where a user has interconnected its own equipment into a private network, communications carried on the network are fully entitled to the provisions of Section 2511. The intent of Congress is pretty much dead on to the question of whether an ISP can do whatever it pleases. Your ISP has also connected its equipment to other private networks, which are subject to 2511, and so on. Email is frequently mentioned in both the House and Senate Reports. The following quote is from Statement of [Senator] Patrick Leahy on the Introduction of the Electronic Communications Act of 1985', September 19th, 1985 (the law was not passed until 1986) At this moment phones are ringing, and when they are answered, the message that comes out is a
Re: Principles of Spam-abatement
On 12 Mar 2004, Paul Vixie wrote: ultimately it was found that no law or regulation required carriage, and that an ISP (whether in the US, Canada, or EU) could subscribe to any blackhole list they wanted, and the only recourse any of their customers had was whatever was explicitly spelled out in their contracts. No such thing was ever found. And just the opposite was proved to you in Exactis V. MAPS. That lawsuit was settled out of court, and MAPS proponents like to pretend it didn't happen. However, before it was settled, there were some preliminary decisions made regarding the case. MAPS tried to have it dismissed on the grounds that MAPS had a first admendment right to say whatever they want. That argument was rejected, and is significant to continued claims by radicals of some First Amendment right to say whatever they want. Indeed, MAPS didn't contest any of the facts asserted. Those facts justified a Temporary Restraining Order. As a matter of legal procedure, a Temporary Restraining Order can only be granted if, after assuming all the facts asserted to be true, the case can succeed. A TRO is an important test of the merits of the case. The rest of a case is then a dispute over the facts and the defenses to them. Two legal teams (one for Vixie, one for MAPS) could only find a frivolous First Amendment defense, which was rejected. MAPS choice was clearly to settle or lose. MAPS attorney was chastised for the frivolousness of the dispute. This is a message to the attorney's of other blacklists, and was reported in many legal journals. I include a quote from one of the the Exactis V. MAPS briefs below, which is illuminating of anti-trust law. Besides antitrust law, there are state electronic communications privacy laws that apply. State laws broadly prohibit any interference with communciations, which is broad enough to include the blacklist. There are also a number of torts that can be brought, but I won't go in them here. Exactis V. MAPS is clearly a reference for blacklist cases. Of course, MAPS isn't an ISP, and while ISPs are also subject to anti-trust law either by contracting with blacklists or by becoming a member of the group, there are some differences in what laws apply to ISPs, and thus the legal constraints that ISPs operate under. Pretty much everything(torts, anti-trust, state law) that applies to a blacklist also applies to an ISP, and there are some more things that apply to ISPs. You can fairly say that if a blacklist can't win on this issue, an ISP doesn't have even a prayer---even God would chastise an ISP's lawyer for being frivolous. :-) The federal Electronic Communications Privacy Act (ECPA) applies to ISPs. There are number of cases in which claims were made under the ECPA. The closest case to ISP email issues is Konop V. Hawaiian Airlines. In Konop V. Hawaiian Airlines it was held that a password, giving access to a website obtained in violation of an agreement not to give anyone else access, did not represent the necessary authorization to access stored communications. Similarly, an ISP has passwords to mailservers and routers, and the authorization from customers to do certain things, but not to do other things. Merely having the root password does not mean that you have authorization to do whatever you please. On Fri, 12 Mar 2004, Vernon Schryver wrote: Your right to send mail stops at the border routers of your ISP. No, your right to send mail stops at the recipient's ISP and not before, and then only to the extent the recipient has granted some permission to the ISP. The Congress writes reports representing the intent of Congress and explaining complicated legislation. In the absence of specific case law binding the court, such reports are used to guide the court as to the intent of Congress when resolving any ambiguities on how to apply statutory language to specific sets of facts. House Report 99-647 reported on the Electronic Communications Privacy Act. There is also Senate Report 99-541. Radicals often try to mislead people into thinking that no laws apply to email or the internet. That is totally false. Regarding your privacy rights from House Report 99-647 says at page 33; Similarly, where a user has interconnected its own equipment into a private network, communications carried on the network are fully entitled to the provisions of Section 2511. The intent of Congress is pretty much dead on to the question of whether an ISP can do whatever it pleases. Your ISP has also connected its equipment to other private networks, which are subject to 2511, and so on. Email is frequently mentioned in both the House and Senate Reports. The following quote is from Statement of [Senator] Patrick Leahy on the Introduction of the Electronic Communications Act of 1985', September 19th, 1985 (the law was not passed until 1986) At this moment phones are ringing, and when they are answered, the message that comes out is a
Re: Principles of Spam-abatement (fwd)
On Sat, 13 Mar 2004 17:03:14 -0500 (EST), Dean Anderson wrote: No such thing was ever found. And just the opposite was proved to you in Exactis V. MAPS. That lawsuit was settled out of court, Dean you have expressed your case well but in the end you must agree none of this is persuasive because the case was never litigated on its merits. We have only he said, she said; maybe MAPS folded for lack of money or some other reason unrelated to the merits; happens all the time. I have been hoping for this issue to be litigated to a judgment but this has not happened to my knowledge. It may be significant (someone who knows more correct me) that even though there is more blocking now than then, no one affected has ever seen fit to sue on like grounds since them. Please correct me if I am wrong. Jeffrey Race
Re: Principles of Spam-abatement
Vernon Schryver wrote: From: Yakov Shafranovich [EMAIL PROTECTED] Since the IETF is a standards organization, can both you and vsj tell us in your opinion, if there is anything the IETF should or should not be doing in the spam arena (changing existing standards, making new standards, etc.)? I have the lucky or unlucky task of being one of the two chairs of the ASRG (together with John Levine). We also tried to reduce many of the problems the original ASRG had including the large signal/noise ration, etc. All of this got me thinking about the larger question of what the IETF should be doing about fighting spam, which is why I am asking the question here. draft-crocker-spam-techconsider-02.txt listed some opportunities for IETF documents. I vaguely recall they included: - codifying common sense for blacklist operators I thought ASRG time working on such a BCP, but it seems to have gone underground. The two folks working on that ran out of free cycles and stopped their work. Nobody else has been willing to pick up the slack and none of the blacklist operators that I have spoken to were interested either (perhaps I just don't know enough of them). There was also talk about documenting the existing lookup protocol for blacklists as an informational RFC, and perhaps work on extensions to this protocol. The BCP work in the ASRG has migrated to a closed subgroup but hasn't seen enough interested parties willing to actually do some work. - improved forms and formats for DSNs. - improved mechanisms, forms, and formats for logging mail rejections. - mechanisms for sharing white- and blacklists among MX servers for a domain. Some of the other things that have been proposed outside the draft are standards for abuse reporting, BCPs for handling hijacked machines and blocking port 25/allowing SUBMIT, standards for exchanging filtering information and decisions between MUAs and MTAs, standards for creating a web of reputation for MTAs, etc. It is interesting to note that many of these efforts are solely focused on areas where standards can make some difference as opposed to seeking the silver bullet for solving the spam problem. That the spam problem involves TCP/IP does not necessarily imply that the IETF has a major role in dealing with the problem, any more than the fact that guns contain metal implies that the American Society for Testing and Materials (ASTM) has a major role in the search for world peace. Regardless of the ambitions of individuals to make a difference or become famous, the IETF should strive first and foremost to do no harm outside its charter in primarily non-technical arenas such as the fight against spam. It is interesting to note that the current version of the IETF mission statement states something similar along these lines (http://www.ietf.org/u/ietfchair/ietf-mission.html): It is important that this is For the Internet, and does not include everything that happens to use IP. IP is being used in a myriad of real-world applications, such as controlling street lights, but the IETF does not standardize those applications. The problem is that many parties see the IETF as the caretaker for email standards and accuse these standards as one of the root problems for causing spam. Obviously the problem has way too many aspects to be purely technical and has not real technical solution (FUSSP or silver bullet). Another aspect of that is that many of the technical solutions to some aspects of the problem such as filters are not even relevant to the IETF's goal as a standards organization except where standardization is needed (Sieve for example). Yet the media and some of the industry players have accused the IETF of foot dragging and not addressing the problem, when this is clearly out of scope for the IETF. This discussion got me thinking about the need to state clearly that the IETF's goal is not to solve the spam problem. I begun writing a draft on this (http://www.shaftek.org/asrg/draft-irtf-asrg-ietf-role-in-fighting-spam-00.txt). Yakov
move to second stage, Re: Principles of Spam-abatement
Yakov Shafranovich wrote: This discussion got me thinking about the need to state clearly that the IETF's goal is not to solve the spam problem. Inadequate design cannot be corrected? The *possibility* of spam is due to an Internet design based on an honor system for the end points. The model being that the connection was less trusted than the end points. Access to the end points was granted under an honor system and usage rules were enforceable. Reality showed that the model was upside down for commercial operation. The end points cannot be controlled and are in fact less trusted than the connection. Anyone can connect to the network. There is no honor system. Usage rules are not enforceable -- users can hide and change their end points. What I read above is denial that the spam problem was made possible by a design developed under the auspices of the IETF. This is good but can I motion that we now move to the second stage of problem solving? Cheers, Ed Gerck
Re: Principles of Spam-abatement
From: Nathaniel Borenstein [EMAIL PROTECTED] ... When each ISP makes its own rules and metes out its own vigilante-style punishment, that's not civilization, it's anarchy. And I find it considerably scarier than the underlying offense of spam itself. -- Nathaniel Your repeated misrepresentation of the use of blacklists by one party in a prospective SMTP transaction as vigilantism is as offensive as it it is a familiar complaint of senders of unwanted mail, including spammers and kooks. Regardless of what governments or anyone else might do about spam, and regardless of whether you and anyone else other than the targets of your mail consider it spam, your implicit claim to a right to send is wrong and scarier than any sort of Internet vigilante-style punishment. Some of us are bothered a lot more by the notion that you might be able to appeal to any third party to force the target of a prospective communication to shut up and eat your [mail]. Your right to send mail stops at the border routers of your ISP. Whether your mail gets any farther depends entirely on the sufferance, whim, and caprice of others. If prospective targets of your mail reject it because your IP address is divisible by 91, that is entirely fair, appropriate, and not for anyone but the owners of your targeted mailboxes to judge. Customers of ISPs that want to receive your mail but can't for any reason, whether the use blacklists, the prime factors of your IP address, or standard incompetence, have and should have only one recourse, changing mail providers. If the targets of your mail reject it because you have chosen a spam friendly ISP or an ISP with the wrong number of letters in its domain name, your only recourse is and should be to change mail service providers. The consequences of your choice in hiring an ISP that subsidizes its rates by serving spammers are no one's concern but yours. The incredible notion you have repeatedly, albeit indirectly advanced, that you have a right to have your mail delivered that should be enforced by governments or at least the IETF, would surely apply to backhoe fade, power problems, misconfiguration, and all of other things that cause mail to be lost or bounced. Having governments or the IETF dictate rights of mail senders to be be heard by their targets would be BAD! Next you'll be telling me that if you telephone me, I can't hang up on you. not that I would, but I reserve the right. Vernon Schryver[EMAIL PROTECTED]
Re: Principles of Spam-abatement
Vernon, Much as I am reluctant to get into this debate, let me try to make some distinctions that might be at the root of where you and Nathaniel are not communicating... * Your analogy to the phone system is exact as long as the system is end-to-end (see below). You have no obligation to accept a call from Nathaniel (or anyone else) and can be as rude as you like --within extremely broad limits -- if someone manages to ring your phone whom you don't want to talk with. But your carrier is generally required to accept a connection from Nathaniel's carrier: except in very rare and highly selective circumstances, neither is permitted to decide that you and Nathaniel should not communicate. * I run my own mail server(s) as, if I recall, do you. What I choose to accept or reject at that server is my business and my problem only. As you suggest, I don't believe that anyone has the right to tell me what I must accept, or how I am permitted to make those decisions. I also pay my ISP extra (relative to their cheapest accounts that offer essentially the same bandwidth, etc.) so that they don't get in the way of my servers or filter my incoming or outgoing traffic (at either the IP or applications level). I resent paying extra, especially since I am painfully aware that their base operating costs are lower for the kind of static-address, no-filters service I am buying than they are for various protect the users or drive up the price arrangements, but, until someone comes along with a better deal, that is how it goes. * But, when the victim^H^H^H^H^H^H consumer is essentially faced with a monopoly --buy the ISP's service with whatever conditions it comes with or be stuck with dialup-- and is not permitted to run mail servers, has no real control over whatever filters the ISP decides to install, etc., the situation is a lot closer to the classic middlebox with no control by either endpoint one (and produces variations on the same arguments). At least in the US, at bandwidth levels lower than a fractional-T1, there is typically very little choice of providers (or at least of terms and conditions). In the Boston area, as far as I know, there are a number of consumer aDSL providers, but none of them provide fixed addresses and most prohibit servers of any sort, etc., without upgrading to much more costly business services. Few, if any, will permit outgoing mail except through their servers, so, if they get blocked, all of their customers get blocked ... and have little choice in the matter. For SDSL, several ISPs offer the product but, as far as I can tell, they all do it through the same last-mile provider. And cable... well, not a lot of choices there, at least choices that don't require changing one's residence, either. Go 100 miles north of here, and the options get even fewer -- buy the cable modem service (if it is even available) at whatever terms and conditions (and incompetence) the cable provider wants to offer, or put in a DS0 or above at (last I checked) $6 / air mile/ month, for 30 or 50 miles above and beyond whatever the ISP charges. Switch carriers is a possibility, but only a theoretical one. Where the disagreement you and Nathaniel are having leads, I think inevitably except for timing, is into the state that you assume Nathaniel is assuming: sufficient governmental intervention to turn anyone who operates a mail relay into a common carrier, without the right to filter mail except in response to government-approved rituals. For many reasons, I hope we never get there, regardless of its potential advantages for controlling spam and various other sorts of bad behavior. But we don't have a free market here, with consumer choice options among ISPs who filter and ISPs who don't, at least with reasonable price differentials. regards, john --On Friday, 12 March, 2004 07:22 -0700 Vernon Schryver [EMAIL PROTECTED] wrote: From: Nathaniel Borenstein [EMAIL PROTECTED] ... When each ISP makes its own rules and metes out its own vigilante-style punishment, that's not civilization, it's anarchy. And I find it considerably scarier than the underlying offense of spam itself. -- Nathaniel Your repeated misrepresentation of the use of blacklists by one party in a prospective SMTP transaction as vigilantism is as offensive as it it is a familiar complaint of senders of unwanted mail, including spammers and kooks. Regardless of what governments or anyone else might do about spam, and regardless of whether you and anyone
Re: Principles of Spam-abatement
John C Klensin wrote: In the Boston area, as far as I know, there are a number of consumer aDSL providers, but none of them provide fixed addresses and most prohibit servers of any sort, etc., without upgrading to much more costly business services. Check out Speakeasy; they don't filter. Their basic package is dynamic IP, but you can get multiple static IPs, without going to SDSL. -- /=\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com| |Centive |My opinions are my own. | |=| |I'm off to wander the streets aimlessly. I'll be taking my usual| |route. -- Lillith, _Cheers_ | \=/
Re: Principles of Spam-abatement
On Mar 12, 2004, at 9:22 AM, Vernon Schryver wrote: Your repeated misrepresentation of the use of blacklists by one party in a prospective SMTP transaction as vigilantism is as offensive as it it is a familiar complaint of senders of unwanted mail, including spammers and kooks. I'm not talking about any party to the real end-to-end email transaction. I'm talking about intermediaries. I have no problem at all with user-controlled filters that do whatever they want. It's when an ISP starts doing these things on behalf of a user who doesn't understand or want them that the problems arise. Regardless of what governments or anyone else might do about spam, and regardless of whether you and anyone else other than the targets of your mail consider it spam, your implicit claim to a right to send is wrong and scarier than any sort of Internet vigilante-style punishment. I don't claim any such right to send. In fact, I agree with you about your right to block. But that right belongs to the you as the recipient of the communication, not to a third party intermediary that is not acting with the explicit approval of the recipient. Just as you have the right to choose only opt in email, I have the right to choose opt out email blocking. We need to preserve BOTH of those rights. Eliminating the latter right is simply not the best way to fix the problems with the former right. Your right to send mail stops at the border routers of your ISP. Bzzt. Not in most Western countries it doesn't. In telephony, equal access regulations have long ensured that telephone companies are required to interconnect their systems and NOT make third party decisions to block calls. But that doesn't stop you personally from using caller-id information to filter my calls, or even from buying a box that subscribes to a private blacklisting service. It's your decision, not your ISP's. Whether your mail gets any farther depends entirely on the sufferance, whim, and caprice of others. Read your history. This is more or less what the 19th century phone companies argued, and it's what governmental regulation of communication in a democracy is *for*. The ISP's like to claim common carrier status when it's in their interest, but they should bear the same responsibilities as well. If prospective targets of your mail reject it because your IP address is divisible by 91, that is entirely fair, appropriate, and not for anyone but the owners of your targeted mailboxes to judge. That is certainly one opinion, but the history of telecommunications policy in the US and elsewhere is based on a rather different opinion. Customers of ISPs that want to receive your mail but can't for any reason, whether the use blacklists, the prime factors of your IP address, or standard incompetence, have and should have only one recourse, changing mail providers. This is precisely where your argument falls apart: ISP's are consolidating and becoming more and more like common carriers. Fork example, at my home in a modern American city, I have precisely two reasonably priced options if I want broadband: Cable and DSL. Ultimately it is becoming a duopoly, and while that's better than a monopoly, it just doesn't leave enough options for a fully laissez-faire position to be realistic. Next you'll be telling me that if you telephone me, I can't hang up on you. not that I would, but I reserve the right. You have that right, and also the right not to answer the phone when my name comes up on caller-id. But your phone company doesn't have the right to make the decision, on your behalf and without your consent, to not cause your phone to ring. And no, acceptable use policies aren't an adequate answer because the decreasing number of consumer-level alternatives means I'm likely to be stuck with a AUP that I find unacceptable. I don't see any difference between this situation and the situation where, say, China uses its governmental/monopolistic powers to block all email from Taiwan. It's an abridgement of a fundamental human right to communicate, which I think trumps the rights of monopolistic ISP's to cut their spam-related expenses. -- Nathaniel
Re: Principles of Spam-abatement
From: John C Klensin [EMAIL PROTECTED] * But, when the victim^H^H^H^H^H^H consumer is essentially faced with a monopoly --buy the ISP's service with whatever conditions it comes with or be stuck with dialup-- and is not permitted to run mail servers, has no real control over whatever filters the ISP decides to install, etc., the situation is a lot closer to the classic middlebox with no control by either endpoint one (and produces variations on the same arguments). ... The major error with potentially catastrophic consequences in that that thinking is the notion of ISPs as monopolies. No ISP in the world has a monopoly on real Internet service, with the exception the bad situation in totalitarin states. servers of any sort, etc., without upgrading to much more costly business services. Few, if any, will That many so called ISPs are not selling Internet access is as irrelevant as the fact that many grocery stores don't sell alcohol. The lies customers of those services providers are told and tell themselves about what they are buying and using are also irrelevant. The services those providers offer are some kind of limited data services that happens to use TCP/IP and portions of the Internet. I'd like to see those providers forced to label their services honestly, but that has nothing to do with monopolies, natural or otherwise, except that monopolies seem more likely to violate truth in labelling. That there are parts of the world where you cannot buy Internet access from local providers may disappoint you and me, but it implies nothing about monopolies on Internet access. There may be monopolies on those limited data services, but that is as irrelevant as monopolies on plain old telephone service. People whose only available data services are those non-Internet access services or POTS can always use those data services or telephones to reach a real Internet service provider. Whether or not they could afford real Internet service is also irrelevant here. Where the disagreement you and Nathaniel are having leads, I think inevitably except for timing, is into the state that you assume Nathaniel is assuming: sufficient governmental intervention to turn anyone who operates a mail relay into a common carrier, without the right to filter mail except in response to government-approved rituals. For many reasons, I hope we never get there, regardless of its potential advantages for controlling spam and various other sorts of bad behavior. But we don't have a free market here, with consumer choice options among ISPs who filter and ISPs who don't, at least with reasonable price differentials. NO! In fact we do have a fairly free market. That many service providers choose to not provide Internet service is evidence that the market is free and that no monopolies for Internet Access prevail. That those service providers charge less than providers that do provide real Internet service is interesting is more evidence that monopolies do not exist. Perhaps governments should crack down the dishonesty of providers that mislabel their non-Internet access services, but that has nothing to do with monopolies. No one should have any sympathy for savvy technicians who choose to pay for a service that is not Internet access, don't get Internet access, and then complain about terrorist and vigilantes who keep them from getting services they've not paid for. That Internet service no longer costs several $1000/month is great but irrelevant. That it costs more than $30/month is also irrelevant. I think it's too bad that Internet access is not cheaper than it is, but just now I'd rather worry about the costs of food and water for most people on Earth. Vernon Schryver[EMAIL PROTECTED]
Re: Principles of Spam-abatement
From: Nathaniel Borenstein [EMAIL PROTECTED] ... I'm not talking about any party to the real end-to-end email transaction. I'm talking about intermediaries. I have no problem at all with user-controlled filters that do whatever they want. It's when an ISP starts doing these things on behalf of a user who doesn't understand or want them that the problems arise. That would be relevant to your situation if you had any contract with those intermediaries, or if you had deigned to buy real Internet access instead of some sort of data service that happens to use TCP/IP and parts of the Internet. Your trouble is that you are unwilling or unable to buy real Internet access. The fact that what you get for $30/month is not Internet access has nothing to do with evil intermediaries. ... I don't claim any such right to send. In fact, I agree with you about your right to block. But that right belongs to the you as the recipient of the communication, not to a third party intermediary that is not acting with the explicit approval of the recipient. Just as you have the right to choose only opt in email, I have the right to choose opt out email blocking. We need to preserve BOTH of those rights. Eliminating the latter right is simply not the best way to fix the problems with the former right. That is a straw man. Other than some governments, no third parties are interferring with your mail. There are ISPs acting in accordance with contracts with their customers to block your mail. You are demanding that ISPs violate their agreements with their customers and pass your mail. Whether the customers of those ISPs know what they are buying in terms of DNS blacklists is irrelevant. It is also irrelevant whether those customers are getting reasonable SLAs, floride in their water, and honest government. Your right to send mail stops at the border routers of your ISP. Bzzt. Not in most Western countries it doesn't. In telephony, equal access regulations have long ensured that telephone companies are required to interconnect their systems and NOT make third party decisions to block calls. But that doesn't stop you personally from using caller-id information to filter my calls, or even from buying a box that subscribes to a private blacklisting service. It's your decision, not your ISP's. While PTTs do regulate telephone service, Internet service is not regulated that way in for most citizens of Western countries. Besides, equivalents of the filtering you are complaining about is available from telephone companies. Qwest sells various kinds of call blocking. By your reasoning, it is ok for Qwest to block telemarketing calls with inevitiably grossly inaccurate CID filters but not for Qwest to block email with much more accurate mechanisms. Whether your mail gets any farther depends entirely on the sufferance, whim, and caprice of others. Read your history. This is more or less what the 19th century phone companies argued, and it's what governmental regulation of communication in a democracy is *for*. Yes, please do read your history, but not just the fairy tails of early 20th Century equivalents of Microsoft and their pet government regulators. The Communications Act of 1933 is widely seen outside PTT marketing departments and naive socialists as a marketing coup by the consortium that was ATT and unrelated to real problems. The ISP's like to claim common carrier status when it's in their interest, but they should bear the same responsibilities as well. In fact almost all service providers do not claim common carrier status. The few that do are not offering real Internet access. If prospective targets of your mail reject it because your IP address is divisible by 91, that is entirely fair, appropriate, and not for anyone but the owners of your targeted mailboxes to judge. That is certainly one opinion, but the history of telecommunications policy in the US and elsewhere is based on a rather different opinion. Your claim would be right if you limited it to telephone and telegraph services. The last 30 years of data services are differ. For example, the PTTs often escaped government regulation by claiming their data services differed from telephone services. This is precisely where your argument falls apart: ISP's are consolidating and becoming more and more like common carriers. Fork example, at my home in a modern American city, I have precisely two reasonably priced options if I want broadband: Cable and DSL. Ultimately it is becoming a duopoly, and while that's better than a monopoly, it just doesn't leave enough options for a fully laissez-faire position to be realistic. You are misrepresenting the services you from your local providers as Internet access. It is not. You are also misrepresenting DSL services. You can often buy DSL based Internet access from
Re: Principles of Spam-abatement
On Mar 12, 2004, at 1:07 PM, Vernon Schryver wrote: That would be relevant to your situation if you had any contract with those intermediaries, or if you had deigned to buy real Internet access instead of some sort of data service that happens to use TCP/IP and parts of the Internet. I don't care to argue over terminology, but when I say Internet I am explicitly including the consumer-level services that are what 99.99% of human beings think of as the Internet. That is a straw man. Other than some governments, no third parties are interferring with your mail. There are ISPs acting in accordance with contracts with their customers to block your mail. You are demanding that ISPs violate their agreements with their customers and pass your mail. And *that* is disingenious. A take-it-or-leave it contract from a near monopoly is not a meaningful contract. While PTTs do regulate telephone service, Internet service is not regulated that way in for most citizens of Western countries. Besides, equivalents of the filtering you are complaining about is available from telephone companies. Qwest sells various kinds of call blocking. By your reasoning, it is ok for Qwest to block telemarketing calls with inevitiably grossly inaccurate CID filters but not for Qwest to block email with much more accurate mechanisms. If they sell it to me and I *choose* to buy it, that's one thing. If I'm given no alternative it's something else. -- Nathaniel
Re: Principles of Spam-abatement
From: Nathaniel Borenstein [EMAIL PROTECTED] That would be relevant to your situation if you had any contract with those intermediaries, or if you had deigned to buy real Internet access instead of some sort of data service that happens to use TCP/IP and parts of the Internet. I don't care to argue over terminology, but when I say Internet I am explicitly including the consumer-level services that are what 99.99% of human beings think of as the Internet. I think you're numbers are wrong, but that's irrelevant. The label used by 500,000,000 users don't change the nature things. That 400,000,000 point point to a monitor and talk about the computer doesn't change difference between a CRT and a CPU. What you are calling Internet access is not. It differs from the real thing by both price and features. That is a straw man. Other than some governments, no third parties are interferring with your mail. There are ISPs acting in accordance with contracts with their customers to block your mail. You are demanding that ISPs violate their agreements with their customers and pass your mail. And *that* is disingenious. A take-it-or-leave it contract from a near monopoly is not a meaningful contract. You are equating $30/month whatever-you-call-it with Internet access. Then you claim that since the real Internet access available to you costs more than $30/month, it is not available. I think that is not just disingenious but dishonest. from telephone companies. Qwest sells various kinds of call blocking. By your reasoning, it is ok for Qwest to block telemarketing calls with inevitiably grossly inaccurate CID filters but not for Qwest to block email with much more accurate mechanisms. If they sell it to me and I *choose* to buy it, that's one thing. If I'm given no alternative it's something else. -- Nathaniel You are misrepresenting your situation when claim that you have no alternative. You do have a choice, but it it is not only between nothing and $30/month not-Internet-access. You could buy real Internet access, although it would cost as much as $400/month. You compound your misrepresentations by implicitly claiming that the same outfits that sell you $30/month not-Internet-access won't sell you real Internet access. Some of them won't, but many will. If you can get DSL, then you can get real Internet access. That 200 kbit/sec or more of Internet access generally costs more than $100/month does not justify your complaints about whatever you get for $30/month. I don't owe you the subsidies for your Internet access that are demanding. You want me to subsidize your access with my money and in my spam loads. If you were willing to pay what broadband Internet access reall costs, your ISP could afford real abuse instead of just letting the spam flow from your fellow $30/month lusers, and it could afford to give you spam filtering than the worst DNS blacklists. Vernon Schryver[EMAIL PROTECTED]
