Re: Acceptability of in-kind donations [was RE: Last Call Comments on draft-iasa-bcp-04.txt]
> From: "Wijnen, Bert (Bert)" <[EMAIL PROTECTED]> > To: Carl Malamud <[EMAIL PROTECTED]>, Scott Bradner <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], ietf@ietf.org > Subject: Re: Acceptability of in-kind donations [was RE: Last Call Comments > on draft-iasa-bcp-04.txt] > Seems we forgot to send issues as ONE ISSUE per EMAIL PLEASE > and use a proper SUBJECT line, so that we can easily check > all mail/postings related to one single issue. That's fine for you people who are continuing to do what you promised weeks ago to stop doing. What about those of us who are growing weary of dozens of such messages per day? Shouldn't the dozen or so of you have already retired to a special purpose mailing list as you promised? It's bad enough that many of your messages consist of thousands of bytes saying no more than "Me too" or "I agree." Now you would multiply them several fold? Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The process/WG/BCP/langtags mess...
> From: Sam Hartman <[EMAIL PROTECTED]> > No, currently this draft is in Ted's hands. It makes no sense for > people to withdraw drafts or to make any hasty decisions at all. That's fine, but does suggest some questions: - Is the Last Call over? - If so, was its result "no supporting consensus"? - If the result was "no supporting consensus", will the current document nevertheless be published as a BCP? - If the result was "no supporting consensus", will a revision of the document be published as a BCP without a new Last Call? Last week I saw a comment that seemed to answer first question with Yes. If the answers to the other questions are not Yes, No, and No, then as others have said, the IETF has far more serious process problems than how to account for the expenses of the to be hired help. If Last Calls are meaningless exercises in noise, then the honest thing to do is shut down this mailing list or redirect it to the old TCP-IP list that some time ago became the comp.protocols.tcp-ip netnews hierarchy. If outside groups can publish IETF BCPs without the let, leave, or hindrance of the IETF, then the honest thing to do is to get rid of all of that tiresome WG stuff. The IETF meetings could continue, but as part of NetWorld+Interop. On the other hand, if the answers are Yes, Yes, No, and No, then contrary to the other person's request, there is no good reason to talk about the language tags document here and now. That would sound like a decision to me, but I'm not sure I'd call it hasty even as committee clocks count time. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The process/WG/BCP/langtags mess...
> From: "Addison Phillips [wM]" <[EMAIL PROTECTED]> > In fact we feel that we've been very considerate > and open in the development of this draft in the language tagging > community and continue to be open to comments and criticism, no > matter the source. Based on what I have seen in this mailing list, I disagree. > I would like the community at large to consider this specific > I-D--both the requirements for it and the technical merits of our > solution--attempt to understand our choices and provide (objective) > feedback that will allow us to achieve consensus for or against it > (or a slight revision thereof). We are trying to work within the > confines of the IETF's process to achieve what we see as the necessary > progress on this issue. If the advocates for this I-D were really trying to follow the IETF's processes, they would have taken one of the suggestions for the next step and temporarily (or permanently) retired from the field. It is clear that there is no consensus to advance this document. Even its authors have admitted that by talking about a new version. As has been said repeatedly, a new version would require a new Last Call. Last Calls are on documents, not promises to produce a new document that might address objections to the current document. Long time spent in IETF processes is not a reason to ignore the clear answer from the IETF processes of "No Consensus," even when the long time actually is spent in the IETF processes. The IETF process involves official IETF Working Groups and official IETF WG mailing lists. Time spent in an unrelated mailing list is not part of IETF standards process any more then the time spent by an Informational RFC author thinking about things is part of the IETF standards process. Besides, isn't the Last Call officially over? Isn't the topic of the language tags BCP closed, dead, kaput, finished, and done until the IESG and the individual submitters of the document choose the next step? I can't see any significance for Mr. Phillips comment except as yet more evidence that the default answer for individual submissions must be "ABSOLUTE NO!" He is basically saying "You must publish our BCP because we followed all of the steps as we understood them and the default result of that is surely to publish." Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: individual submission Last Call -- default yes/no.
> From: Misha Wolf <[EMAIL PROTECTED]> > vs> unless the incredible "I'm gona tell the Liason on you" > vs> threat was the vacuous, standards committee politicing > vs> as usual that it sounded like. > > That appears to be a rather paranoid reading of my: > > mw> Now the IETF is, of course, free to do whatever it likes, > mw> but I would urge that any course of action which would > mw> cause a parting of the ways between the IETF and the W3C > mw> (and other Industry Consortia) should be avoided. I > mw> suggest that it may be time to escalate this matter to > mw> the IETF/W3C Liaison group. > > Where is the threat? I was suggesting that as the IETF and > the W3C have a liaison group and as there appear to be > disagreements as to how to move forward, the matter be raised > at the liaison group. Is that not what such groups are for? Please credit some of us with understanding the meaning of "escalate" in the intended sense of "evoke to an authority that will issue a writ of mandamus." Other words in Mr. Wolf's message including "any course of action which would cause a parting of the ways" were not lacking in forcefulness. Then there was the awesome list of authorities that the IETF list members is ignoring at its peril. See http://www1.ietf.org/mail-archive/web/ietf/current/msg33563.html When I read Mr. Wolf's message the first time, I was reminded of an IETF slogan about rejecting kings and presidents as well as ancient friction between the DDN protocol designers and users and the ISO. I suspect that the language tag saga is not as bad as it seems and that some good new IETF documents might come of it. It should also serve as a red flag for another instance of the general problem of the quality of IETF documents. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: individual submission Last Call -- default yes/no.
> From: Juergen Schoenwaelder <[EMAIL PROTECTED]> > [I do understand what people are concerned about here but I also find > it important to remind myself from time to time how we are all working > towards raising the bar, and once raised, someone will speak up to > raise it even further. Why are we not trusting the system that has > worked remarkable well most of the time so far? Perhaps thats human > nature - if I look what it takes to release a new Linux kernel these > days or how difficult it is to make the next Debian release, I may > conclude that raising the bar is a normal part of such societies.] That is seriously wrong. The issue does not involve rising bars, but falling bars that need to be caught or at least seen to be falling. The IETF is, as it has been for 10 or 15 years, under attack from those who use it for ends not consciously chosen by the IETF. 15 years ago there would have been blank looks of incredulity to the suggestion that an outside, sometimes ostensibly ad hoc and other times supposedly offical standards organization should push through a document with as official a designation as "BCP" without the let, leave, or hindrance of IETF consensus. However, that is the case today. 10 years ago no one would have considered the notion that individual submissions should become official standards (of course I include "Proposed" as an offical IETF standard) of the IETF with a yes vote assumed from everyone outside the IESG. Of course, 20 years or 25 years ago, things were nominally different. In practical terms, the bar was higher still. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: individual submission Last Call -- default yes/no.
> From: Ted Hardie <[EMAIL PROTECTED]> > And the point I'm trying to make is that there are multiple records. > When we have >a mailing list like "ietf-types" or "ietf-languages" where there is a long term > community of interest around a specific issue, should a discussion there > be taken into account when assessing an individual submission? I think >the answer is "it depends" and certainly may be "yes". It should not over-ride > ... I'm bothered by the talk of "community of interest" and "support" as if they were fungible, as if every community of interest is the same as the IETF. That is a potentially catastrophic slippery slope. There are very good reasons for IEEE PARs. Turf is the most fought over commodity of standards organizations. Turf is more highly valued than any single document. Letting random groups of people call themselves "communities" and so automagically give themselves the IETF imprimatur is a very bad thing. Whether the random group has a mailing list that includes the string "ietf" in its private part should be obviously irrelevant, but judging from recent cases, isn't. Whether the group's mailing list happens to use an ietf.org domain name is close to irrelevant. Whether the supposed "community" includes leaders of other standards organizations should also obviously be irrelevant, but evidently isn't. Instead of a "default no" for BCPs or standards track RFC from individual submissions, it would be better to make it a simple "no." If the IETF does not feel like investing the substantial effort and delays to form a WG and the rest of the tiresome, formal IETF dance, then that in itself is proof that the issue is unworthy of the IETF's official seal. Previous efforts to borrow the IETF's printing press and official seal have involved "Informational." Evidently the many forces that want to borrow the IETF's seal have figured out that "Informational" is not valuable enough and are trying a new tactic. Giving BCP or standards track to individual submissions is evil on more than one front. It's not just that it risks blessing non-standards and deluting the value of BCP and the standards track. It is evidence that the IETF as an organization is getting lazy about its real work. If every I-D were worth publishing, there would never have been a need for WGs, Last Calls, and the rest. The whole "community consensus" thing is absolutely required for anything that deserves the word "standard." You can't have a worthwhile standards publisher without the work of editing. Other standards bodies use voting. Book publishers use editors. The IETF uses "consensus". Letting the editors off the hook for jobs will have results as bad in their own way as results we saw from letting the directors of Enron and MCI sleep on their jobs. The IESG, IAB, and ADs are not the IETF and do not define the IETF consensus. They might gauge it, but if it does not exist outside them, then it does not exist. It is definitely not good that the IETF is spending so much time writing a job description and paying so little attention to ostensibly important Internet standards like language tags. It's not only true that "A [standards committee's] gotta know [its] limitations," but it must also know what it doesn't care about enough to work on. If the IETF doesn't want to work on language tags by having a WG and the rest of those delays and work, then so be it. Let the standards body that evidently does care do it...unless the incredible "I'm gona tell the Liason on you" threat was the vacuous, standards committee politicing as usual that it sounded like. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Excellent choice for summer meeting location!
> From: Jari Arkko <[EMAIL PROTECTED]> > First, I tend to find tourists and MFLD rather harmless. > In fact, I think they are good for our financing. Some > might say necessary. And they usually stay out of the mike, > don't disturb presentations, and don't comment on the mailing > list where the real consensus is verified. But if some of > them do, that's even better - then we have attracted new > contributors. And we DO need new contributors. >From my perspective as someone with a decades long perfect non-attendance record at the IETF parties, I think that is wrong on all counts. There are WGs that exist only because it is the go-ers who feel the greatest need to prove to the folks back at the factory or to the readers of their trade rag inter-ad filler that their contributions to the Standards Process are vital to peace, prosperity, and the continued existence of the Internet. But then I have the archaic and obsolete notion that the IETF needs good and useful standards more than it needs contributors. > In short, I wouldn't worry too much about the touristy nature > of a location. Judging purely from good and bad results in the WG mailing lists, I think that is right and wrong. Venues that are too hard to reach are attended by only the most dedicated and so produce agreements that do not reflect the consensus of the WG mailing list; recall the "agreement" to pick the ISO OSI Protocol Suite as IPng. Venues that are extremely popular also produce bogus agreements by not drawing a representative sample of the WG as defined by the mailing list, albeit not quite as bad. If had been asked years ago, I'd have said the IETF WG meetings should be abolished in favor of the WG mailing lists supplemented by ad hoc telephone calls among at most 2-4 people to hammer out the relatively few issues that need "high bandwidth." I've no doubt that administrative groups such as the IAB and IESG need real meetings, but in decades of watching WGs, I cannot think of single case where an IETF WG meeting was necessary. Judging from the effects on documents I've watched but often not contributed to, WG meetings have only neutral or negative effects. Good specifications require thinking and understanding. The heat of battle in a conference room or any meeting of more than 3 or 4 essentially always precludes anything that might honestly be called deliberation. This is true even when you have 3 or 4 people playing to a silent audience. Abolishing the WG meetings would also end the silly political correctness games in the choice of venues. Of course, I don't expect anything of the sort to happen. The opposite of ever more emphasis on meetings and the form of the IETF and less on useful protocol specifications will continue. The IETF of 10 years ago would not have spent a fraction as much time writing RFCs about accounting and job descriptions as it has in recent months. Such stuff would have been flatly inconceivable for the IETF of the 1980s. However, it's best to acknowledge and deal with such irresistible changes. They're the stuff of life and death. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: List of Old Standards to be retired
> From: Eric Rosen <[EMAIL PROTECTED]> > I see this exercise has already reached the point of absurdity. > > How can it possibly be worth anyone's time to look at each telnet option and > determine whether it is deployed? What possible purpose could be achieved > by changing the standards status of some telnet option? Is there some > chance that someone is going to implement one of these by mistake somehow? > > A similar comment applies to the FDDI MIB. Are we trying to make sure that > no one implements that MIB by mistake? Or that no one implements FDDI by > mistake, just because he thinks there's an IETF standard about it? > > Let me echo Bob Braden's "if it's not broken, why break it?" query. Spending time revising old RFCs of living protocols is unlikely to do much good and has potential for plenty of harm. It's hard to avoid the temptation to fix things (parts of RFC 1668 and RFC 1661 tempt me), but such fix-it efforts usually produce incompatible protocols. The IETF definition or RIPv1 was compatible only because it was a strict subset of the real protocol. The IETF version of the printer protocol was just plain broken. Other targets of this exercise describe protocols that were never implemented and should never have been allowed on the standards track. Why not scale back the exercise to attack only obvioulsy dead or stillborn protocols? Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: New Last Call: 'Tags for Identifying Languages' to BCP
> From: John Cowan
> ...
> > For example, I'm
> > unhappy about an apparent sentiment that would put ABNF on a lower
> > footing that the English text. I think I'm like most implementors and
> > perhaps unlike non-engineers in reversing that precedence. Whenever
> > I read an RFC, I rely first and foremost on the ABNF. I use the English
> > only for hints, and follow the ABNF instead of the English whenever
> > there is a conflict.
>
> Then you would be incapable of implementing any programming language compiler,
> or an XML parser, for the specs for these things include literally hundreds
> of constraints that are specified only in technical English and not in the
> BNF. As far as the BNF is concerned, this is good sound C:
>
> main(argv, argc) {
> float Argv;
> int* Argc;
> print(32);
> }
In contexts other than UNIX applications with modern compilers,
that fragment is perfectly sound, if not something I'd write. An
example context is before typing of formal args and in what ANSI/ISO
9899-1990 calls a "freestanding environment" where main() is not
special. I've suppressed most of the memories, but I seem to recall
that what Microsoft calls threaded WIN32 applications are such
things, or were before the POSIX additions.
Besides, I didn't say that one should ignore the English, but that
implementors give precedence to the ABNF. When you are writing an RFC
that you hope will be implemented, you MUST remember that programmers
are lazy. We transliterate the ABNF to build the parser and so implement
the syntax and read the English to figure out and so build the semantics.
As I said, if you must have contradictions between your ABNF and your
English, you must accept the fact that most technical people will
assume your ABNF is right and your English is wrong. That fact seemed
to me to conflict with statements in this thread, and that suggests a
problem in your working group and your RFC.
Vernon Schryver[EMAIL PROTECTED]
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
Re: New Last Call: 'Tags for Identifying Languages' to BCP
> From: "Peter Constable" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > This is a multi-part message in MIME format. > > --===1521567419== > Content-class: urn:content-classes:message > Content-Type: multipart/alternative; > boundary="_=_NextPart_001_01C4E16C.40BF0707" > > This is a multi-part message in MIME format. > > --_=_NextPart_001_01C4E16C.40BF0707 > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > Bruce Lilly has posted comments on the IETF list in response to the > last-call announcement for a proposed revision to RFC 3066. His comments > were generally negative, raising a number of concerns. I and others > involved in preparation of the revision have discussed Bruce's concerns > with him, but they were not made available on the IETF list since those > of us other than Bruce were not subscribed to this list. I wish to > briefly summarize the outcome of that discussion for the benefit of > people here. > > =20 > ... > In conclusion, I think that some of Bruce's concerns were valid, and > suggestions for changes have been presented to the authors accordingly. > I believe all of these changes can be considered to be for clarification > purposes, rather than technical changes. (No changes affecting the set > of valid tags have been made.) > ... > --_=_NextPart_001_01C4E16C.40BF0707 > Content-Type: text/html; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > > > > charset=3Dus-ascii"> > >
Re: Sunshine Law
> From: John C Klensin > Two additions to Brian's comment, with which I agree... > > (1) The type of discussions he describes are especially > important in situations in which an alternative is to try to > make large structural or procedural changes in order to solve > problems with personalities. Such changes almost never succeed > if the relevant personalities are still in place, and they can > add serious additional friction to the process while solving > problems that don't exist and not solving those that do. Gordian Knots are hard unless you are a mythic hero. It sounds better deal first with the personality problem and then fix the structural problem. I think conflating the two even in private is bound to lead to serious errors and distortions in the procedural repairs. But sometimes that's impossible and you can't cut the knot. I trust this is not directly relevant to the reorganization stuff. > Perhaps I'm just getting too old, but while I think IETF > benefits from clear discussions in frank language, I don't think > the nit-picking, out of context, abuse, especially that which is > based on long-ago comments, benefits anyone. Yes, but much of that comes from letting everyone have a say as opoosed to letting everyone see what is said. I have big problems mustering any interest in whether the IETF is incorporated in Elbonia or whatever the reorganization is really about, but doing things in secret is always expensive. Sometimes the costs of secrecy are less than the alternatives, but they always exist. In this case, I'm now convinced that the reorganization stuff is less boring than I assumed. I still prefer to let you and others deal with it in private than to read those minutes. But please see those costs. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Sunshine Law
> From: Brian E Carpenter > >> Private discussions > >>> are sometimes a necessity, as is the ability to float what might > >>> be stupid ideas without having them quoted for years as one's > >>> firm position. > > > > I have trouble imagining such tender feelings in anyone who should be > > allowed to participate. > > That's not quite the point. Both in an ad hoc group like Adminrest, > and in the IAB and IESG, it is entirely possible that in a discussion > of the real issues, something like the following would be said: > > A: The real problem here is X, who simply can't do his/her job. > ... That misses what I tried to say as well as the objections that have been raised. All of the various state sunshine laws have exceptions for personnell, legal, and other matters that truly must be discussed in private. > I won't reply in more detail to Margaret's note, except to say > that if the confidentiality clauses she quotes are used *except* > for the above sort of discussion, they're being misused IMHO. As I wrote, since the Colorado Sunshine Law was enacted decades ago, there have been many mini-scandals in which government officials have been accuser of lying, often justly, about what they're talking about behind closed doors. People who want political power often also want to be gatekeepers of any and all information that they happen to find, as well as needing to avoid having their decisions examined. If you are saying that deliberations involving the administrative reorganization should as secret as people seem to be saying they were, because they included statements like "real problem here is X, who simply can't do his/her job," then it sounds like one of those mini-scandals. As far as I can tell, "X" in those discussions would have been agencies instead of people. Besides, even if some Xs were people, one of the uncomfortable parts of jobs serving public committees is that performance reviews and so forth do not get nearly as private as jobs elsewhere, even governments with sunshine laws. > Truth in advertising: I drafted the confidentality clause > in the IAB charter, which was of course last-called as a BCP. > Harald borrowed it for the IESG charter. RFC 2850 says The IAB publishes minutes of all its meetings on the Internet, and conducts an open meeting at every IETF meeting. It publishes all its findings as RFCs, Internet Drafts or messages to the IETF mailing list. However, discussion of personnel matters and possibly legal and financial matters may sometimes be required to be kept confidential, and the chair may, with the consent of the full members, exclude liaison and ex officio members from such discussions. Those words in RFC 2850 giving the power of participants to close doors are wrong, if only because they are not specific enough. You cannot rely on committees to keep themselves open; that's why there are sunshine laws and why you put that paragraph in RFC 2850. That those words passed a last call does not mean that they are not subject to reconsideration. Perhaps the NonCom should examine each claimed need for confidentiality. Feel free to call me stupid, but I cannot relate this reorganizaing to personnel matters. You don't re-organize because an employee is sluffing off. There are evidently financial matters, but those particular financial matters also seem inappropriate for confidentiality. I don't care about bureaucratic organizing and almost certainly would not read published minutes of whatever. I don't see any issues that aren't better handled by people other than me. Or until the supposed need to keep stuff secret was invoked, I assumed there were no such issues. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Sunshine Law
> From: John C Klensin > Now, the reasons the discussions and mailing list archives were > not made public. I don't think we really discussed it, but all > of us who are familiar with the IETF process, yourself included, > have noticed how rapidly the S/N ratio can deteriorate in > "public" discussion of things for which the "public" doesn't > take the time to understand the details. Discussions that are made public can differ from discussions by the public. Publishing a mailing list archive is not the same as letting the peanut gallery contribute to it. If knowing that the archive for a mailing list is public would make contributors as noisy as professional politicians, then you need different contributors. > Private discussions > are sometimes a necessity, as is the ability to float what might > be stupid ideas without having them quoted for years as one's > firm position. I have trouble imagining such tender feelings in anyone who should be allowed to participate. Besides, that reasoning would justify keeping everything private except the final conclusions, and often even those. The fear of looking foolish seems to be a major reason why governments try to keep everything secret including their firm positions. Anyone who fears looking foolish should stay out of the kitchen, or learn to phrase ideas tentatively until they've become firm positions. Or follow the old advice to never write anything that would seriously embarrass you if reported by CNN or read in court. > When issues that either involve people's jobs, > that can get highly emotional, or that may involve legal claims > are at issue, the importance of holding private discussions > becomes even greater (and we have seen all of those things in > various pieces of the Admin restructuring/reorg process).I'd > actually favor changing the rules to make that more explicit. I think Colorado's old Sunshine Law allows private personnel discussions. There are periodic mini-scandals about abuses of exceptions to the law, but it generally seems to work. Judging from http://www.google.com/search?q=sunshine+law other states' sunshine laws are similar. However, that old advice about not saying dumb things even in private holds, as demonstrated by Microsoft and SAVVIS. See http://www.google.com/search?q=savvis+spam+memo > I think there is a huge > difference between "We are going to discuss X with Y. Those > discussions need to be private because they touch on sensitive > issues, but a summary of conclusions and justifications will be > made available as soon as that is possible consistent with that > level of sensitivity" and "the community isn't entitled to know > that the discussions are being held". True. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Shuffle those deck chairs!
> From: [EMAIL PROTECTED] (scott bradner) > see http://www.wordiq.com/definition/Prior_art > > prior art is still useful but not necessarily in naive, open compilations that do patent holders the most good. I was told by participants in the XOR-cursor court battle that it was lost because the opposition learned of the killer prior art in time to weave a defense. Recall the results of the re-examination of the LZW patent. Prior art is not nearly as effective as it is supposed to be according to people who've never spent time and money with patent lawyers. The notion that the IETF can do anything about bogus patents is at best the obverse of the bad coin that let Motorola-Codex mess up CCP and try to attack Van Jacobson Compression in the PPPEXT WG for years starting about 10 years ago. The IETF administration professed to take those patents seriously. A list of relevant patents without pretensions of prior art lets people use their own judgement. If you are competent to implement a protocol, then you probably have a fair idea of the readily available prior art. The important data are the names of the patent holders. When you look at patents, you should not be trying to decide whether your lawyers can use prior art to break them in court, even in the unlikely case that you are competent to have legal opinions. You should be deciding whether the patent holders would want to block the sale or use of your implementation. If the patents are only defensive or if you are writing open source, then you might choose to go ahead no matter what you think of the validity of the patents. If by virtue of their owners, the patents seem likely to be used for extortion or to enforce a monopoly, then the bogosity of the patents and prior art are also irrelevant, since a successful court battle would cost years and zillions of dollars. You also have noticed that court attacks on patents are rarely successful. At worst the notion that the IETF can do more than say "these IPR claims are known" is a mechanism for people who claim to be spokesmen for large communities to inflate themselves. If the Open Source Community were much more real than Jeff William's "INEGroup LLA. - (Over 134k members/stakeholders strong!)" and able to work with the IETF to fix the patent mess, then it could fix the patent mess without help from the debating society that is the IETF. The power and the glory of the IETF is that it is literally just a debating society. In that supposedly monolitic Open Source Community, users, particularly redistributors and packagers, have far more compelling reasons than authors of open source to care about patents. The calls for the IETF and open source authors to get involved in patent fights can be seen as efforts by politicians and redistributors of our work to shift even more of the burden of making their profits and reputations to us. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Shuffle those deck chairs!
> From: "Eric S. Raymond" <[EMAIL PROTECTED]> > Let's put an end to these far-reaching interpretations of > "representation", which are a product of Mr. Schryer's fevered brain > overinterpreting my original statement. > > Originally, somebody asked that the open-source community get its act together > about what acceptable patent-license terms would be. > > I said this: if IETF wants to know what form of patent license will be > acceptable to the open-source community, the people to ask are Richard > Stallman (representing FSF) and myself (representing OSI). > > Between us (and especially if we agree), I believe we can speak *with > regard to this question* for 95% of the open-source community. This > does not make either of us power-mad dictators intent on domination, > just most peoples' recognized experts on what constitutes an > acceptable open-source license. > > If either Mr. Schryer or yourself chooses not to be considered part > of that "most people", fine -- the fact remains there are an awful damn lot > of developers expecting RMS and myself to *do* *this* *job* so they don't > have to. If it existed, that job would conflict with the way the IETF works. No contributor to an IETF WG or mailing list is supposed be presenting anything but personal opinions. When Mr. Raymond writes here about acceptable patent-license terms, his views get careful reading, but not because he represents anyone but himself. If the IETF were to make an exception and count votes on this issue, then it should weight votes based on relevant open source, since concerns about patents on parsing C matter less to the IETF than patents on address prefix lookups and compression. However, any kind of voting would be bad. More and larger (including commercial) organizations would declare themselves champions of open source and demand votes in proportion to their programmers, customers, or market shares. > Cripes. It'd be easier trying to serve a gang of baboons, sometimes... Many people besides baboons and refuseniks consider it unseemly to demand gratitude for unwanted gifts, and not only because some political activites are painfully obvious and familiar. Being recognized as the official spokesman for the open source community by the IETF would help Mr. Raymond's efforts to get the world to believe the phrase "open source community" is not silly nonsense like "netizen," that it has spokesmen, and that he is one. Vernon Schryver[EMAIL PROTECTED] P.S. I don't entirely agree with Mr. Vixie's patent suggestion. Requiring that WG participants make such disclosures would be very nice in theory, but seems as realistic as the IETF simply declaring that it has opted-out of the patent extortion game. However, that's all been said before more than once. P.P.S. I think this started with concerns about quoting parts of RFCs. Is there more fire than smoke there? ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Shuffle those deck chairs!
Someone wrote me privately: ] For an open source guy he ] has some pretty funny legal language: ] ] http://www.catb.org/~esr/copying.html That page includes this restriction: } You may not make or redistribute static copies (whether print or } online) without my express permission. HTML and English are not C, C++, asm86, perl, or even php and I don't expect anyone who writes some open source to write only open source. I would also like a way to stop my perpetual problems with people using and redistributing ancient or distorted and preverted versions of my epistles in C. Still, someone who claims to represent refuseniks like me in negotiations concerning open source with an organization in which I've been particpating for decades ... Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Shuffle those deck chairs!
n source users than authors, but there is plenty wrong with appointing yourself to represent people outside your organization. If you truly understood and supported the notion of open source, you would not be doing as you are and have been doing. What you are doing is the political realm's equivalent to the theft that some corporations commit or attempt with open source. (e.g. AT&T and the BSD TCP/IP code, except I think AT&T made an almost innocent mistake in that case). You are trying to "leverage" the reputations and work of open source programmers for your personal gain and political power without even deigning to give us credit. And save the stuff and nonsense about being trustworthy and not having power over me. Don't insult my intelligence. Your efforts here to be named co-negotiator for open source authors are intended to exercise power over me. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Shuffle those deck chairs!
> From: "Eric S. Raymond" <[EMAIL PROTECTED]> > Your two people to go to on this would be RMS (representing the FSF) > or me (representing the OSI); between us I believe we can speak for > over 95% of the community. I hate it when elected politicans presume to speak for me. I will not sit quietly and let self-appointed individuals try the same. *DO NOT* tell me to my face that you are negotiating on my behalf or even just for 95% of the other people who write or have written software that might be called "open" by virtue of being freely redistributable and in use by lots of people until you can can point to the results of a real plebiscite. Even then, you won't be speaking for me until I personally and explicitly say so. If you and Mr. Stallman want to speak for your respective organizations, then peachy. If you want to speak based on what you consider your own great experience and deep thoughts on the issues, then that's also good. If you want to pretend that you speak for me out of my earshot, then I'll do my best to not hear. Just don't stand in front of me telling me that you have my best interests at heart and that I must trust you. It's been many years since I came to expect such behavior from the FSF. I had a better image of/delusions about the OSI. I guess I should know better. Just as the self-named Internet Society attracts people far more interested in politics and telling me how I should view the Internet than designing, implementing, deploying, and maintaining what I think of as network stuff, any self-described open software organization will be run by people telling me whether I'm really writing free code and where my best interests really lie. The appareance of such stuff in proximity to the IETF administrative reoganization...uh...negotiations is not really irony. Such things tend to attract each other. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Shuffle those deck chairs!
> From: Harald Tveit Alvestrand > the MARID WG was shut down because it was unable to reach consensus. > > That is, indeed, a failure of the IETF. But not the one you argue. On the contrary, recognizing the hopeless lack of consensus and refusing to continue dancing to the tune of various interests was an outstanding success of the IETF. The failure by the MARID WG to reach consensus can be viewed as a failure or a success. Neither the IETF nor any other voluntary standards organization can force standards on the world, as the ISO and governments demonstrated with the OSI protocols. When consensus cannot be reached, it is wrong to continue, as the ISO also demonstrated with the OSI protocols. One of the worst things that committees (not just standards committees) can do in such binds is to produce kitchen sink non-designs. The essence of designing consists of making choices, and that consists of saying "yes" to one or maybe few things and "no" to almost everything. When consensus is impossible for making choices, the right response is to stop spinning. As has long been true, a bigger danger to the IETF than patents are the special interests that try to use the IETF for ends unrelated to ensuring the interoperability of network protocols. The baloney started by some SPF advocates and widely repeated by others about the reasons the MARID WG was shut down are more harmful to the IETF than embrace-extend-and-patent games, even if such games were in play, which is not at clear. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Behavior Engineering for Hindrance Avoidance
> From: [EMAIL PROTECTED] (Noel Chiappa) > It's not at all clear to me that this was the wrong engineering choice on > their part. If they didn't GC dead connections after some sort of timeout (and > would it make any significant different whether it was 5 minutes, or 1 hour) > it would consume resources and perhaps lead to problems. > > Although I suppose they could impose an LRU algorithm on state blocks, > instead. I'd have to think about it for a while, to see if there were other > problems caused by not GC'ing inactive mappings. Problems in doing it right? hph. More recent boxes from some of the same vendors that have killed my ssh sessions do not kill my ssh sessions despite days of inactivity. That's not to say the newer boxes don't still have problems that can only be solved--er--attacked by power cycling when they stop responding every week or so. My current tactic involves solid state relays that driven by taking less than 5 ma from an RS-232 pin 20 and simple code that looks for signs of illness in the junk. (Yes, I know of far better, UL certified implementations. They cost more than the NAT junk.) Besides, if "GC" refers to "garbage collection," my prejudice is that you don't garbage collect active data. I've had the junk kill active ssh sessions. Whether they run a timer or just have bugs that appear after an hour or two, only someone with access to source could say. > Furthermore, it's relatively easy to avoid the SSH session problem - my > default login on Unix boxes has for many years now included starting this > shell script in the backgound: > > while 1 > echo " " > sleep 600 > end > > precisely to avoid having them shut down due to NAT timeouts (no matter how > long I go without typing on them). I try to avoid building failures into anything, especially if the failures are obscure and intermittent. That might keep an ssh session alive despite boorken NAT junk, but depending on imponderables including tty "driver" output buffering vs. application context switching on the ssh server side, it will also occassionally break curses programs including `top`, `sysstat`, `vi`, and `emacs`. Having a standards committee write more documents that say "DON'T BE STUPID!" sounds unlikely to solve many problems in NAT boxes, even if committee "solutions" weren't the hallmark of the design and implementation of garbage, probably including the junk NAT boxes at issue. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)
> From: Pekka Savola <[EMAIL PROTECTED]> > To: Harald Tveit Alvestrand <[EMAIL PROTECTED]> > > Well my house was behind 2 levels of NAT until last week. > > Once i got rid of one level (the one I don't control), some of my > > operational problems with keeping SSH sessions up simply went away. > > And SSH is a client-server protocol. > > > > Don't underestimate the capability of badly implemented and/or configured > > NATs to make things go boom in the night. > > FWIW, I don't think this is something that can be fixed whatever > guidance the IETF would give. NATs will always need to keep some > state for all the protocols, including TCP, and that state must be > removed after a timeout. Who said anything about necessary state and reasonable timeouts? I've seen more than one brand of consumer-grade box with NAT features that could not be turned off, and that even in their most permissive settings kill ssh sessions after an hour or two whether the ssh sessions had been active or not. Then there are notions of "DMZs," "game playing mode," and "VPN support." What you might guess from feature-list bullet items probably sound reasonable, but you'd probably guess wrong about what the bullet items really mean in products delivered to users. Harald misstated his injunction. You should never underestimate the capabilities of people to build things that make you say "no one would do that!" and then defend their braindamage as valuable features. Perhaps more NAT RFCs would help; they couldn't hurt much. They'd be a lot of work and would certainly be ignored by many people who consider themselves designers. I can't personally get enthused about telling people things that are obvious and that will be ignored, like much of what would go in new NAT RFCs. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: archives (was The other parts of the report....
> From: Scott W Brim > WG status or become RFCs, people have to work very hard to find out if a > particular draft is outdated. This is a major factor in their depending > on wrong information. So, instead of trying to suppress information, > which we can't, we should create and offer the meta-information people > need to avoid mistakes. That should include the meta-information that the draft being sought expired without being advanced. Today it is hard for the uninitiated to distinguish expired drafts that led to BCPs or standards track RFCs from the expired drafts about encoding more than 4,294,967,296 addresses in 32 bits in order to avoid the hassles of IPv6. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: How IETF treats contributors
> From: "Olaf M. Kolkman" > I'd like to expand on what Dean said: "Credit and attribution is about > intellectual honesty [ and _courtesy_ ] not about copyright law". Ok, but in the case at hand, - None of the versions of Mr. Danish's proposal that I've seen credited Mr. Vixie's document or some others than preceded Mr. Danish's work. I think that was due to ignornance and disinterest instead of malice, but it does reduce Mr. Danish's standing to more credit than he already receives. - Mr. Danish's proposal was always an obvious non-starter for various reasons, including the requirement for defining new DNS RR types before it could be deployed or even tested. - Mr. Vixie's proposal is a lot closer to what I understand of the current MARID mechanisms than Mr. Danish's proposal. - It is ironic or something that few people who are openly concerned about credit for their work have enviable reputations. They tend to be inventors of such as IPv8. - As far as solving the spam problem is concerned, RMX, SPF, the commercial proposals, the MARID proposals, and all other sender authentication mechanisms are more like IPv8 than IPv6. Squashing the current modes of spam forgery will have just as much effect as the squashing years ago of the forgery of 8-digit user names @aol.com. The new anti-forgery mechanisms are more general than the old regular expressions, but sender forgery is not a required aspect of spam. Some large spammers have long been using domain names that they register, use for literally a few days, and discard. For example, some time ago I grew bored with accumulating the domain names of one such operation in http://www.rhyolite.com/anti-spam/bin/group.cgi?group=151 Some of the domain names of smaller (in counts of names) operations are in http://www.rhyolite.com/anti-spam/bin/group.cgi?group=197 http://www.rhyolite.com/anti-spam/bin/group.cgi?group=30 http://www.rhyolite.com/anti-spam/bin/group.cgi?group=140 and http://www.rhyolite.com/anti-spam/bin/group.cgi?group=165 Spammers can deploy sender authentication mechanisms far faster than their victims. - This thread has the wrong subject. It should be more like "How some would-be contributors treat the IETF." Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'The APPLICATION/MBOX Media-Type' to Proposed Standard
> From: "Eric A. Hall" <[EMAIL PROTECTED]> > To: Tony Hansen <[EMAIL PROTECTED]> > > The information about the mbox format being anecdotally defined is > > incorrect. The mbox format has traditionally been documented in the > > binmail(1) or mail.local(8) man pages (BSD UNIX derivatives) or mail(1) > > man page (UNIX System 3/5/III/V derivatives). > > I checked each of those and none of them seem to adequately describe the > message or database format. > Do you have a specific URL to a specific man page that you think would be > appropriate and authoritative? There are plenty of man pages and documentation for UNIX mbox formats. Outfits such as Netscape have figured the stuff out (painfully simple as it is) to make libraries to deal with local mailboxes. However, that seems irrelevant unless an auuthority ceeds change control for the UNIX mbox format to the IETF. Never mind that the notion of an authority that could exercise any authority over any UNIX mbox format other than in its own source trees would be crazy. There's no law that says Dragonfly, NetBSD, FreeBSD, OpenBSD, Linux, IRIX, HP/UX, AIX, etc. and so forth and so on must have a common mbox format or that they cannot switch to something better, not withstanding things like that Netscape library. The old mbox formats are fine for a VAX-750 or 3B2, but are very bad ideas for more than a few hundred messages. The most you could do is define your own interchange mbox format that would by coincidence be extremely similar to one format such as the System V or 4.3 BSD (I think I recall small differences between those two), and tell implementors of your MIME type to convert into and out of your format. There is an overriding question. Where is the market demand for an IETF standards track RFC defining a UNIX mbox interchange type? Who would use it? I can imagine "importing" and "exporting" mboxes, but not via SMTP. Is anyone thinking about new code to convert among Netscape, Exchange, and UNIX mbox mailboxes? Doesn't enough of that code already exist, and doesn't all of it use transport mechanisms other than SMTP? Isn't the IETF supposed to be about on-the-wire bits and keep its noses out of host data structures? Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'The APPLICATION/MBOX Media-Type' to Proposed Standard
> From: "Eric A. Hall" <[EMAIL PROTECTED]> > > > If there are no defined semantics for the content of an application/mbox > > part, how does the type differ from application/octect-stream? > > It provides an identifier for the content, so that transfer agents can > perform specific tasks against the data (such as importing or searching a > remote mailstore, or handing the data to an agent that knows what to do > with it). The agent still needs to deal with content-specific issues like > determining the EOL markers, applying default domains to relative > addresses, and so forth. That's a pretty common separation of powers; > application/postscript doesn't relieve the system from needing a > postscript interpreter, and we leave things like ~version tags for the > content agent to worry about instead of the transfer agent. > > > [regarding creating a spec for a mailbox file format] > > > >>I'd like to see one, and I'd like to see whatever *NIX consortium is > >>responsible for such things get together and define one. > > > > At that point, would application/mbox be updated to refer to said spec, > > rendering non-compliant some chunk of the previous uses, or would a new > > content-type be specified? > > Given that the current proposal specifies minimal formatting (essentially > being limited to the likely presence of some kind of From_ line), I'd > think that a reasonably authoritative spec could be referenced in an > update to this proposal. It would depend in large part on the depth and > comprehensiveness of the specification, I'd imagine. I cannot understand that except as saying that this document explicitly and intentionally does not provide enough information for the recipient of a message defined by the document to decode the message. I understand that statement as saying that the data is essentially opaque. Isn't the point of any RFC on the standards track to promote interoperability? What good is an RFC that says "consult as yet unwritten specifications from undetermined sources to handle the data standardized by this RFC"? Isn't the first sanity test of a standard whether one can determine if an implementation is compliant? As far as I can see, Eric Hall is saying that compliance of senders and receivers of such messages could not be determined until some. Aren't there already enough opague application data MIME types? Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: Email account utilization warning. (Final)
> From: "Jasen Strutt" > Would you give it a rest already? Take your issue(s) up with the appropriate > person(s) in a separate, mutually exclusive thread, and stop blasting the > IETF list. I would rather not offend you, but please consider that good advice. Please do not respond to those whose only interest is provoking a response, any response from anyone and so being reassured they exist and that people care about them, even if those concerns are negative. Many of us know of their messages only when people respond to them, and would rather not have that particular clipping service. The differences among trolling, trollbaiting, countering trolls, and everything else related to trolling are almost entirely in the minds of the players. To the rest of the world it is all useless, costly noise. As for the Internet experts who still don't recognize phishing or Microsoft worm noise when it hits their mailboxes, the Secretariat should interpret complaints sent to the thousands of readers of this list as requests to be unsubscribed with prejudice from all IETF mailing lists, particularly when their complaints are double-encrypted in base64 and HTML. Such people are better served reading IETF mailing lists through archives such as http://www1.ietf.org/mail-archive/web/ietf/ I promise to try to apply that policy to the minor, non-IETF lists that I run. I don't intend any criticism of those who choose on their own to use archives instead of subscribing. That's how I follow some mailing lists that for various reasons I choose to not give my address. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: non-solution
> From: Bill Sommerfeld > Substantially similar capabilities are present in all of the SMTP > MTA's I'm familiar with. If a message delivery attempt is rejected > early, only envelope information is logged, but if the message was > rejected in error, that's generally sufficient to identify what needs > to be whitelisted. Yes, but after you've had them, you find that facilities that log the fewest few dozen KBytes of SMTP bodies are very valuable. SMTP envelope logs are unitelligible to most users, not only because they are terse but because the SMTP envelope is a mystery to the fewer users that know about it. Delaying filter rejections until the SMTP DATA command and so capturing the message body resolves a lot of complaints of the form "Why did your idiotic spam filter reject that perfectly good mail message?" That can significantly reduce whitelisting requirements. Logging bodies involve some obvious privacy hassles. You must keep the logs private. The logs can have only censored copies of the envelope so that recipients can't know who else was sent the same message. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: What exactly is an internet (service) provider?
> From: Markus Stumpf <[EMAIL PROTECTED]> > If you want to buy a car and ask if it has air bags and nobody can > give you a definite answer, would you buy the car if it is important to > you to have an air bag? Buging a car with a feature with well defined characteristics is quite different from buying Internet services which don't even have common names. Air bags, at least in the U.S., must do exactly what they do even if that is known to kill people who are short. Your "private use" Internet service is basically whatever you feel like selling. That you apparently call it "private use" instead of one of the more common names is yet another symptom of the problem. > If the ISP can't answer the question about improtant product details, > why do you sign a contract with that provider? Because he is cheaper > than others? Now what would most probably be the reason? I'm in the insignificant minority that can ask the right questions about IP service and recognize when I'm not getting answers, but I can neither ask good questions about air bags, nor recognize nonsense answers. I don't know much about air bags except that they are bombs in bags, which is as much as most sales people. Still, I can buy a car with an air bag and know I'm getting something that might do some good (unless I'm short or sit too far forward) and meets a standard. Without the standardization of "air bag," I could not. We have a classic standardization problem that is affecting interoperability. The market has gotten ahead of the IETF and is buying and selling a many quite different things all called "Internet service." It is more the job of the IETF to define standards including a taxomony in this area than to define yet another MIB. It is not the job of the IETF to try to stop anyone from selling services that differ from what we used to get via NSF any more than it is the job of the IETF to prevent the sales of NAT boxes and PPPoE, no matter how nasty and evil NAT, PPPoE, and slum IP services are. It is right, proper, and necessary that the IETF has NAT and PPPoE standards. We should also have standards for your "private use Internet service" as distinct from the services I bought 20 years ago, even if you agree with me that "slum IP service sold by virtual slumlords to fools" is as accurate and more clear than "client only, private address." > > Since there are always providers, you can't sue simply because you > > bought an account with limits you failed to clarify. > > This is the important part: "you failed to clarify". Unless you are among the insignificant minority who knows the difference between an ICMP Port-Unreachable and an ICMP Administrative-Prohibited, you are incapable of clarifying. Worse, unless you know more than all available employees at many Internet services providers, you are incapable of knowing whether you're being told nonsense. Standards for the various flavors of "Internet service" would solve those problems for both users and service providers. > > - which of the classes in > > http://www.ietf.org/internet-drafts/draft-klensin-ip-service-terms-02.txt > > is closest to a "DSL Surf Accounts"? > > It is probably something like "Web connectivity" or "Client connectivity > only", but I find the terms in the draft *very* fuzzy and overlapping. > And no I haven't yet thought about it long enough to make suggestions ;-) What about adding explicit lists of the packets that are (not) filtered, frequency of DHCP reassignment, DSL PPP disconnections, and whatever? The draft currently gives the equivalents of "driver's side", "passenger," "side impact air bags," for consumers but does not include the technical stuff equivalent to the rules for air bags. Something like the "Client connectivity only" now in the draft is needed by consumers and front line technical support people, but it is not sufficent for a provider (or a government) to determine compliance. Maybe this needs a WG. > In general I support all what you said to some extent. In that case it would be nice if you would not write as if you vehimently opposed the notion of standardizing terms for classes or kinds of Internet service. Except for that single sentence, I have the impression that you agree with the individual from Japan that the whole idea of the draft is entirely wrong and destructive. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: What exactly is an internet (service) provider?
> From: Markus Stumpf > You have a contract. This should be listed in the contract and you > can read it before signing it. If the contract doesn't talk about > limits and they do limit you, sue them. Sue on what grounds? Who says that Internet service has no limits? All reputable service providers have terms of service that include limits, starting with something about network abuse. (Never mind how well those limits are enforced.) Many service providers limit their users to not running "servers," but good luck finding someone who knows what they mean by "server." Since there are always providers, you can't sue simply because you bought an account with limits you failed to clarify. Trying to find first line technical support people (never mind sales) at a consumer grade ISP who knows has any idea what sort of filtering their employer does is hopeless. It's generally foolish to expect to find someone who even understands the question. > (And, btw, some of the statements are incorrect. > > - Some providers intentionally cut their customers > > off after 24 hours in order to force them to have > > a new IP address. (Some "DSL modems" including the Actiontec 1524 kill TCP connections after an hour or two all by themselves) > You have to look at what they sell. They sell "DSL Surf Accounts". > Surfers usually aren't online for 24 hours without interuption and > they don't have problems with the interupt in "normal use". If you get a > "business access" you will not have the problem in most of the cases. I've not seen anyone selling "DSL Surf Accounts," but I've never looked, and certainly not in Germany. In any case, - which of the classes in http://www.ietf.org/internet-drafts/draft-klensin-ip-service-terms-02.txt is closest to a "DSL Surf Accounts"? - Should one of those four categories be renamed "DSL Surf Accounts"? - Should a new class named be "DSL Surf Accounts" be added? - exactly what filtering is imposed on a "DSL Surf Account"? Is port 25 filtered? 22? 135 and 138? Some or all UDP? ICMP? - and the same questions for "business access." Telling people to read contracts ISP today is disingenuous. If the IETF would define "DSL Surf Accounts" and "business access," then you could hope to ask for one or the other. You might then sue if you didn't get whichever you wanted. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: What exactly is an internet (service) provider?
> From: Ole Jacobsen > assigned something that looked like a "real" routable IP address, but > as a consumer of paid-for Internet service (that works) is there any > reason (apart from religion) that I should care?? If you have no reason to care, then you shouldn't, except that Full Internet connectivity is significantly more expensive to provide. It's not the bits that are more expensive, but the people who deal with the naughty bits that come with Full Internet Connectivity. If you have a technical reason to care, perhaps because you need to run an application not understood by the NAT systems of your hotel, then you ought to be able to distinguish what you need from what you are getting while talking to people who have never heard of the IETF. Perhaps you would like to run applications that talk to systems back at the factory and that use protocols that don't always play with NAT. Maybe you are a system admninistrator who needs to check your DCC servers (anti-spam system), despite your hotel's filters against UDP port 6277. Perhaps you need to check your DNS servers despite your hotel's filters and redirection of port 53 or all UDP. Maybe you just need SSH and didn't remember to set an sshd listening to port 443 before you left. Maybe you need to talk to port 25 on your SMTP server to see if it is sick. Talk about ALGs, UDP, TCP, and even NAT is cybercrud noise to a hotel desk clerk. However, you might someday be able to say "please upgrade the Internet service for room 1234 from Web Connectivity to Full Internet Connectivity." You don't expect airline ticket agents to understand or care what you're talking about if you go on about stall speeds, rates of sink or climb, and so forth, but asking for a ticket on a "communter airline" instead of a "wide body" can be useful. There is absolutely no chance of less filtering in hotels, 802.11 hot spots, etc. There will be terms that distinguish those kind of Internet service from what many of us consider the real thing. The issue is whether we must wait for the market to provide equivalents to "ham radio," "CB radio," "satellite radio," "AM," "FM," "TV," and "cell phone." Arguing against the idea of draft is like saying "the term 'electormagnetic radiation' is good enough." Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: What exactly is an internet (service) provider?
> From: Masataka Ohta <[EMAIL PROTECTED]> > As you introduce "Web connectivity", such people (including > mobile operators in Japan) claim that they are ISPs, because > they are offering web connectivity over X.25 without IP. WebTV is functionally the same as web connectivity over X.25 without IP. Most of the world thinks that part of Microsoft is an "ISP." Nothing the IETF or even governments could do would change that. > That > is, "The definitions proposed here are clearly of little value > if service providers and vendors are not willing to adopt them." Those involved call the services of WebTV either "WebTV" or "Internet service." Professionals (including salespeople) who are not employed by Microsoft in the WebTV operation, especially competitors, would be happy to call it "Web Connectivity" instead of "WebTV." Even Microsoft might like "Web Connectivity" to limit dilution of its "WebTV" trademark. Thus such concerns are irrelevant to "Web Connectivity." You'd do better attacking one of the other categories. > A major mistake is that you are forcing people within IETF > use your terminology even though you are fully aware that > "some members of the IETF community that some of these > connectively models are simply "broken" or "not really an > Internet service"". No, the major mistake is thinking the various classes of IP service do not exist or that you can keep people from naming them with short English words or phrases. As the various classes become more popular and widely recognized, the world will invent and use terms for them. No one but pedants and marketers will care which words or phrases are ultimately chosen. The IETF can speed up and slightly steer the choice, but no one can prevent it. We got to choose the word "Internet" but did not entirely control the definition (recall small 'i' "internet"). We lost on "intranet" "catnet" and many other terms. The useful things that this draft might accomplish are: - make the choice of terms happen within or a year instead of the years that the current definition "Internet" needed. - make the people who have more control than the IETF over the choice of terms for the emerging clases Internet service think about the words they want. They are in marketing organizations. Consumer ISPs are not offering the kinds or classes of IP service that I would want. It is insane to ignore that reality. It would be little better to insist that governments will not eventually get involved or that there will be no common terms for the various common classes of IP services and ISPs. ] From: Masataka Ohta <[EMAIL PROTECTED]> ] > But if we had a precise definition and a taxonomy of the ] > different classes of ISPs, ] ] Then, all the IP and non-IP providers can now leagaly (some ] illegaly a little beyond the scope of so generous RFC) say ] they are ISPs and most end users have no chance to know the ] differences of the taxonomy. No, - Whatever happens with this draft, it will not have anything like the force of law. The IETF does not have powers over terms equivalent to the groups that name species, chemical compounds, and astronomical bodies. - all the IP and non-IP providers in most of the world can now legally call themselves "ISPs." The IETF could not change that. - The terms the world eventually uses for the various classes of IP service and types of ISPs will differ from the consensus of the IETF. This draft can only crystalize the choices. Seed crystals influence the shape of a solid, but do not control it. - the main reason "end users have no chance to know the differences" delineated by the taxonomy is that the taxonomy does not yet exist. When it exists, users will know as much of it as they care to, just as they now know or don't know the differences among "web," "Internet," and "telephone." Users who do not distinguish between "web" and "Internet" also think "WebTV" is Internet service. IETF cannot change that. That VoIP, text messaging, and cell phones are changing the definitions of "telephone" and "telephone company" is part of my point. Much of the good this draft might do will be done simply by discussing in public differences among IP service classes and choices of terms. After the taxonomy is crystalized, it will be out of the IETF's control. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: What exactly is an internet (service) provider?
> From: Mark Smith <[EMAIL PROTECTED]> > > So it would be good to have some kind of > > standard or definition, what exactly an > > internet provider has to do and what to refrain > I tend to come up with the answer to your question the following way : > > (Q) What is the "Internet" ? I prefer the definitions of various kinds of "Internet service" in http://www.ietf.org/internet-drafts/draft-klensin-ip-service-terms-02.txt Today, providers that sell sevices to users of Microsoft systems and do not pay exquisite attention to which of them are infected with the latest worms and viruses must block and redirect port 25 to their own SMTP servers and so not provide what that draft calls "Full Internet Connectivity." Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Response to complaint from Dean Anderson (fwd)
> From: "Stephen Sprunk" > While I disagree with Dean in general and also with most of his current > argument, I think it is a reasonable request that IETF "officials" be given > an @ietf.org email alias and that those aliases be published for use in > situations such as this. Exactly what is this situation? Why can't Mr. Anderson say whatever he needs to say to Mr. Austein here or via a relevant working group mailing list? > It's probably going too far to require sending mail from those aliases; > despite Dean's faults, he's smart enough to use the published alias if he > gets a bounce from someone's personal or work address. How would Mr. Anderson use a private IETF alias belonging to Mr. Austein? If sending a polite, IETF-relevant private message from one IETF participant were important to Mr. Anderson, he would have long since sent his message in public via an IETF mailing list. Any complaints or other thoughts Mr. Anderson has about a working group, an AD, other IETF participants, or whatever would have long since been forwarded via a friend, sent to this mailing list, the IAB, or via the official appeals process. There is an important issue here separate from Mr. Anderson's concerns. Why hasn't Mr. Anderson been told to say whatever he wants to say in an IETF mailing lists or to the relevant IETF role accounts? Why has the notion that individuals have rights enforced by IETF rules to send private mail to other IETF participants been consistently supported or at least never refuted? Mr. Alvestrand's recent message only disavows the IETF's interest private filters. What RFC imposes an obligation to receive private (not to mention unfriendly) mail on ADs, WG chairs, or any IETF participants? Private IETF aliases for IETF officials would be invitations for harassment and abuse, and it is important that IETF participation not be contingent on tolerating harassment or abuse. Harassment and abuse must be defined by the targets of mail for deciding whether to accept future private messages. IETF participants must be allowed their own definitions of acceptable private mail, no matter how wrong they seem to mail senders or third parties. Filtering messages to IETF mailing lists is justifiably controversial, but private mailboxes are none of the IETF's business, and not merely because of scaling problems. I care about this issue because other individual IETF and ASRG participants have threatened or started attacks on me similar to Mr. Anderson's attack on Mr. Austein, because my mail systems are configured to reject their private (not sent via IETF reflectors) mail. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Problem of blocking ICMP packets
> From: [EMAIL PROTECTED] (Mike S) > So the fact is, by blocking ICMP, such ISPs have broken IP connectivity, > and can no longer claim to be providing Internet (IP) service. I agree, but which flavor of other than "Full Internet Connectivity" would it be? Does http://www.ietf.org/internet-drafts/draft-klensin-ip-service-terms-02.txt need a category of "Public address, stupid filtering"? Or is "Client only, public address" close enough? Many people who install or defend such stupid filters are offended by the observation that they are not doing real IP. Labelling such filtered access as what it is or at least something other than "Full Internet Connectivity" would reduce its popularity. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
> From: Andrew Newton <[EMAIL PROTECTED]> > To: Paul Vixie <[EMAIL PROTECTED]> > > If there's a more blatant example of rubber stamping in the history of > > IETF, then I hope a better historian than I can share the archives with > > me. > > If there's a more blatant example of mischaracterization in the history > of IETF Whether it is an example of rubber stamping can't be determined until we see the I-D. Besides, the implication that rubber stamping by the IETF is a bad thing is wrong. When the IETF has worked well, it has applied its stamp of approval to things developed, tested, and initially deployed outside the IETF. IETF working groups that try to design things never do better than can be expected of standards committees, and that's a step below the sad results of ordinary committees. The IETF is often competent to determine and publish the choice of the market; it is incompetent at inventing. MARID will provide good service. For years, the unthinking and snake vapor oil vendors insisted that "redesigning" SMPTP with authentication would solve the spam problem. Now that we have SMTP-TLS, SMTP-AUTH, S/MIME, and PGP, they have changed their songs to praise sender authorization. Sender authorization cannot fix the spam problem, but MARID will soak up a lot of their noise for months (or years). When an official sender authorization protocol fails to end spam by the Sept. 2004 (see http://ietf.org/html.charters/marid-charter.html), maybe we'll get to hear a new chorus. Maybe a few will stop praying for the salvation of business models that depend on abusing the commons and switch business models. (e.g. actually deal with abusive users) Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
> From: Mark Smith <[EMAIL PROTECTED]> > > Yes, spam filtering can be quite effective. > > Not using spam filtering ... I don't like the chances of false > positives or negatives. Today either you filter spam, or you get practically no mail from strangers. If your address is exposed for legitimate mail from strangers, then lots of spam will be sent your way. At least 50% and by some accounts more than 80% of all mail is spam. If you get the 10 legitimate message/day typical of a non-technical user, and your spam load is 80%, then you also receive 40 spam/day. My various layers of filters averaged 521 spam/day for the last 40 days. Either your computers filter using blacklists, whitelists, various content filters, and/or other mechanisms, or you filter spam manually. 40, not to mention 521 spam/day are too many to filter manually without frequently overlooking legitimate mail. Those are false positives. Thus, if your mailbox is open to legitimate mail from strangers, then you have false positives, whether they are human or computer errors. > My idea is similar to the idea of abandoning a phone number if > you get too many prank calls. Similar to abandoning a phone > number, when I abandon an email address, I don't even see the > spam traffic - I'm not filtering it out. On the contrary, legitimate messages sent to your abandoned mailboxes are false positives. They are filtered out. > > > I would find not be able to run my own MTA, > > > unfortunately on a dynamically assigned IP ADSL service, as > > > that is all I can afford, to be far more costly than the very > > > negligable reduction in spam I would receive if TCP port 25 > > > was blocked by ISPs. > > > > I cannot understand that as other than a demand that I > > subsidize your Internet service. > > > > If you think that everyone has the right to run their own MTAs, > > why don't you insist that Full Internet Connectivity be free? > > I struggle to understand how you make such a dramatic jump in > "position" (I can't think of a better way to describe it at the > moment). I can't see the logical progression from being able to > run an MTA, to getting Internet connectivity for free. I thought you were repeating the too familiar whine that it would be Wrong and Evil to be forced to choose between paying for Full internet Connectivity and having port 25 blocked. The familiar claims from others about unblocked port 25 for $30/month being a fundamental human right of communication are irritating. Those making those claims want only a price they can afford, instead of the $0.00 price appropriate for a fundamental human right. } From: Mark Smith <[EMAIL PROTECTED]> } I'm just waiting for the next Outlook based (or alternatively, a } socially engineered executable based) worm that uses legitimate } email addresses and "legitimate" (in the sense of } "legitimate because TCP port 25 is not blocked") MTAs to send out } spam. That is such an obvious countermeasure that you must assume it it probably is already in use. } Blocking TCP port 25 on dialup accounts (or any other } Internet service) will have no effect in mitigating these types } of attacks. That is mistaken. Spam, worms, and viruses sent through ISP mail systems can be filter. I understand that worm and virus filtering is quite effective, but don't really know. Filtering spam from an ISP's own customers can be extremely effective. For example, an ISP can rate-limit customers to 10 or 20 messages/day, and require customers to make arrangements for higher rates. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
> From: Nathaniel Borenstein <[EMAIL PROTECTED]> > This is a remarkably reasonable proposal, and I would have no objection > to it (just a fear that ISPs might make it unnecessarily hard to get it > opened, but they tend to make everything hard). Heck, I might not even > mind paying an extra dollar or two per month to have it open. As long > as consumers have an option, I'm fine with this as a default. Good > idea. -- Nathaniel > > I think the easy solution is just to block port 25 unless someone asks > > for it to be opened. Average users have no idea what > > port 25 does or even what TCP is, so they won't care. and how does that proposal differ from what I wrote Thursday?: ]block port 25 for all types of IP ] service except the one that draft-klensin-ip-service-terms-01.txt calls ] "Full Internet Connectivity." Mr. Borenstein recently wrote the following apparently about that: } ... Grocery stores probably have the right to require their } customers to wear formal attire, but if they don't have a good } reason to do it, they're going to drive away customers no matter } what the outcome of any philosophical debates. My expectation is } that ISP's who implement anti-spam measures that are both intrusive } and ineffective are going to drive away customers as long as there's } a better alternative out there, and I'd be inclined to simply let them } do it unless they're in near-monopolistic market positions. The latter } exception is important, however; I'd certainly be upset if my cable } provider did it, because I don't have any good alternatives. I don't mind in the least if Mr. Borenstein has changed his mind but does not wish to say so. I also don't care if he prefers the ancient statement of the old idea offered by Perry Metzger. I will mind if Mr. Borenstein resumes his campaign against the supposed evils of blocking port 25. Such unfounded complaints give aid and comfort spammers and to marketing departments resisting blocking port 25 for customers who aren't competent to use it. Until consumer grade services providers such as Comcast do something to stem the floods of spam they are sending, other organizations will stem their incoming floods with bad tactics such as rejecting mail from IP addresses with reverse DNS names containing "dsl". Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
> From: Nathaniel Borenstein <[EMAIL PROTECTED]> > > On May 30, 2004, at 2:27 PM, Vernon Schryver wrote: > > > So what ISP was blocked? > > What are you, the ISP police? Not that it's any of your business, it > was X0 DSL Your repeated, unprovoked public complaints about the blocking that affected you made XO's identity not the business of everyone who cares about such issues. Then there were your comments about "near monopolies." >and I paid just under $100/month and hosted my server at > home; it was blacklisted as part of a larger block of IP addresses > beyond my control. When I moved physically, I took the opportunity to > move my server to a hosted service for guppylake.com, and NOW am on a > normal cable modem at home. I've been associated with the domain > guppylake.com for almost twenty years, however, and I rather like to > continue sending mail from that address even though I now obtain my > bitstream from Comcast. > > But I imagine that X0 is also on your list of ISP's-that-are-evil, so > it was my fault for using them in the first place. That reference that any list of mine of evil ISPs is disingenuous. Besides, I bet you know as well as I do that RoadRunner probably blocked that larger block of addresses because of lots of spam. For a while XO was having difficulty acting against its spamming customers. I've not noticed such complaints for a while. It does sounds as if you have made a habit of hiring ISPs without exercising due diligence. If that is true, you might blame your parents but not me. I don't blame you for the fact that until recently I've always paid much more than $100/month to host my vanity domain, but then it has not been blacklisted. I have moved it more than once when I lost confidence in an ISP. > > Why do I suspect you are being disingenuous > > and that it was a $30/month account? > > I don't know, perhaps because you have a suspicious nature and are > quick to assume the worst about people? Instead of using ad hominem, you might recall your own words such as ] ... near-monopolistic market positions. The latter exception ] is important, however; I'd certainly be upset if my cable provider ] did it, because I don't have any good alternatives Then there is your coyness about XO's identity. Why didn't you come out and name it at the start? > I am not really the sort of > person who tells lies on an IETF list just to make a point. Where have I lied? For your part, you have repeatedly intentionally misrepresented my words and generally been disingenuous. For example, your words above imply that I had no business asking which ISP was involved in the blocking you have repeatedly complained about. You made the identity of the ISP a relevant point by your demands that I stop "random speculating" as well as by your repeated complaints about RoadRunner's blocking. > For my part, I am sufficiently paranoid to fear that ISP's might > advocate port 25 blocking because they hope it will lock people into > email addresses that are less portable (e.g. [EMAIL PROTECTED]). But > when they give other reasons, no matter how irrational I may think they > sound, I try at least to give their sincerity the benefit of the doubt. That is also disingenuous. While I share concerns about locking people into addresses, you know that blocking port 25 is unrelated if people use some flavors of what you called "a more spam-resistant infrastructure for SMTP message submission," such as SMTP-SUBMIT, or simple "web mail." Why don't you give RoadRunner's sincerity the benefit of the doubt about the blocking of your XO address? Did you check any of the well know resources such as news.admin.net-abuse.sightings for evidence of spam from your neighbors or did you just start complaining about evil "near-monopolies"? Do you have any substantive responses to my counters against your claims that port 25 blocking is useless and harmful? I claim - port 25 blocking by $30/month providers would block little more than the spam that might someday be blocked by Caller-ID, SPF, etc. - the legitimate mail blocked or false positives caused by port 25 blocking is similar or less than that for Caller-ID, SPF, etc. - port 25 blocking can be implemented today piecemeal by individual providers on the sending side in routers and on the receiving side using blacklists, while Caller-ID, SPF, etc. must wait at least 5 or 10 years until most of the Internet implements them. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
> From: Nathaniel Borenstein <[EMAIL PROTECTED]> > Please stop this random speculating. The ISP that was blocked is not > my current ISP (I moved last fall), so none of this is relevant. So what ISP was blocked? Why do I suspect you are being disingenuous and that it was a $30/month account? > And > if I'm dealing with Hurricane now, well, that's the first I'd heard of > it, since I'm downstream on a hosted service and never bothered to > check who all my upstream providers are. As always, the buyer must beware. Adopting the terminology in draft-klensin-ip-service-terms-01.txt or similar would help. Hurricane Electric could say that its IP addresses may not be optimal for SMTP clients but are useful for SMTP, HTTP, and other servers. > Are you seriously asserting > that I deserve to be blocked if I don't confirm that all my upstream > ISP's are complying with J. Random Blacklist? That is a obviously an intentional distortion of my point. However, now that you "ask," then yes, you do "deserve" to have your mail blocked if you buy service from a provider with a reputation for being friendly to spammers. Your failure to exercise due diligence does not impose an obligation to accept more spam on others. You "deserve to be blocked" more than the rest of us "deserve" to receive the spam that helps support Hurricane Electric. > However, you are right that my current laptop configuration is one of > many that won't work when Caller-ID or SPF records come into use for > the domain guppylake.com. At that point, obviously, I will change my > laptop's configuration. My sincere hope is that by the time that > happens, I will have a better option for smtp submission. Blocking > port 25 will most assuredly *not* help that problem. On the contrary, Caller-ID and SPF would not stop as much spam without collateral damage as blocking port 25 from TimeWarner, Comcast, and other $30/month service providers. Caller-ID and SPF cannot have significant effects against spam for at least the 5-10 years before most domains support them. Caller-ID, SPF, and the rest would in effect block port 25 about the same IP addresses as simple port 25 blocking of $30/month accounts, in the unlikely event that Caller-ID etc. ever have any effects. If you would switch to SUBMIT, you would not care if your TimeWarner account is port 25 blocked, except that you might expect TimeWarner's prices to drop for needing even less abuse-desk staff. On the other hand, port 25 blocking can be done today and has immediate good effects against spam, as well as worms and viruses. Of course, port 25 is not a panacea for spam, worms, or viruses. Of course, some viruses and spammers would adopt the obvious countermeasure of using the ISP's servers, but many would not. Besides, the ISP is could filter or at least rate limit, and there are no easy countermeasures for spammers against that. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
> From: Mark Smith <[EMAIL PROTECTED]> > > people to monitor and deal with their abusive customers. That > > is why many of the providers of those $30/month accounts submit > > their own IP address blocks to various "dynamic" backlists or > > block port 25 themselves. > > Do you have more information or references regarding your > statements above? I'm interested in any studies etc. The easiest study is to look at your own spam load. The most recent public study or reliable comment I'm aware of was the statement from Comcast about how much spam they send in http://news.com.com/Attack+of+Comcast%27s+Internet+zombies/2010-1034_3-5218178.html See also http://www.senderbase.org/?searchString=comcast.net&searchBy=domain and http://www.senderbase.org/ (I do not believe SenderBase's numbers are accurate to better than several percent of total Internet mail or tens of millions of msgs/day. I know that their numbers for the domain names and IP addresses I control are nonsense, but my domains and addresses are directly involved with 5 or 6 orders of magnitude less mail than those listed in http://www.senderbase.org/ ) > I would find TCP port 25 being blocked by my ISP to be > unacceptable. It isn't the Internet anymore. The Internet's job > is to shunt around IP packets, irrespective of what is in them. That is inaccurate. From ancient days it has also been the job of people running things to prevent traffic that would violate various agreements, AUPs, TOS, and so forth. > My anti-spam measures are so effective that I can't remember the > last spam I received. Yes, spam filtering can be quite effective. I say this based in part on the results of the DCC, which handled about 136,000,000 mail messages on May 26. However, the effectiveness of input filtering is irrelevant to the need to deal with spam at its sources. > I would find not be able to run my own MTA, > unfortunately on a dynamically assigned IP ADSL service, as that > is all I can afford, to be far more costly than the very > negligable reduction in spam I would receive if TCP port 25 was > blocked by ISPs. I cannot understand that as other than a demand that I subsidize your Internet service. If you think that everyone has the right to run their own MTAs, why don't you insist that Full Internet Connectivity be free? Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
>Received: from mail.optistreams.net (206-169-2-196.gen.twtelecom.net [206.169.2.196]) >by calcite.rhyolite.com (8.12.11/8.12.11) with ESMTP id i4UG8bio077225 >for <[EMAIL PROTECTED]> env-from <[EMAIL PROTECTED]>; >Sun, 30 May 2004 10:08:38 -0600 (MDT) > From: Nathaniel Borenstein <[EMAIL PROTECTED]> > > Mr. Borenstein and others like him expect the rest of us to subsidize > > their $30/month connectivity by dealing with the network abuse of his > > fellow customers, because they find $30/month comfortable. > > Just for the record, I spend plenty more than $30 per month on Internet > connectivity, as does my employer. My views on this have nothing to do > with the cost of my Internet service, which is why I said nothing about > such costs. Since your message seems to be based entirely on a > misguided assessment of my motives, there's not much else in it that > needs to be answered. (We could argue forever about what constitutes a > monopoly, but I doubt any minds would be changed.) > > Port 25 blocking may be sometimes necessary simply to preserve the > integrity of a network under heavy spam attack. Perhaps I am mistaken, but I believe that Mr. Borenstein has mentioned his costs in the past. His recent talk about the supposed "near monopolies" of "cable providers" makes absolutely no sense except in the context of $30/month services. The copy of his message appears to have been sent to my SMTP server from one of those $30/month accounts. Mr. Borenstein certainly has complained about some sort of blocking of his mail. I think that blocking involved a cable provider account. However, if the blocking that bothered him was not from his TimeWarner acocunt, then perhaps this is relevant: traceroute to guppylake.com (64.71.173.70), 64 hops max, 44 byte packets 11 ix-8-0.core1.SanJose.teleglobe.net (66.198.97.18) 59.309 ms 12 pos2-3.gsr12416.pao.he.net (66.220.13.42) 119.297 ms 13 pos2-0.gsr12012.fmt.he.net (64.62.249.121) 61.106 ms 14 64.71.173.70 (64.71.173.70) 62.479 ms traceroute to thehideout.net (64.71.176.110), 64 hops max, 44 byte packets 13 pos2-0.gsr12012.fmt.he.net (64.62.249.121) 60.953 ms 14 64.71.176.110 (64.71.176.110) 61.028 ms Hurricane Electric has earned a reputation as a provider that avoids dealing with reports of spam sent by its customers except by forwarding them reports to its customers. See http://groups.google.com/groups?scoring=d&q=+%22he.net%22+group%3A*email http://groups.google.com/groups?scoring=d&as_epq=Hurricane%20Electric http://groups.google.com/groups?scoring=d&q=+%22he.net%22+group%3A*abuse* Juging from http://spews.org/html/S2100.html 64.71.173.70 is currently listed by SPEWS at level 2. (I do not use or advocate SPEWS' list; I'm pointing out SPEWS' data only to support my point about the supposed unfairness of the blocking of Mr. Borenstein's mail.) > But I believe that a > long-term solution is possible that will be both more effective and > less restrictive. My own focus is on that long-term planning, and I > just can't see port 25 blocking as anything more than a rather > problematic stopgap measure in advance of a more spam-resistant > infrastructure for SMTP message submission. People have been talking about such ideas since Cyberpromo's day. The closest thing that has ever been implemented and proven effective is blocking port 25 SYNs from blocks of IP address that have a better than 99.9% probability of sending only spam and worms, namely the IP addresses of spammers and of "dynamic address." In practice the latter is synonmous with block port 25 for $30/month accounts. Blocking port 25 from $30/month accounts does not affect SMTP-SUBMIT, which is the IETF standardized "spam-resistant infrastructure for SMTP message submission." One must wonder how Mr. Borenstein's mail could be blocked by the sort of blocking he has repeatedly complained about if he used SMTP-SUBMIT to reach reputable MTAs. Note also the disconnect between the reverse-DNS of Mr. Borenstein's SMTP client and his envelope Mail_From and header From: values, and the lack of DNS RRs supporting any of the proposals for DNS-based sender authentication. According to the advocates of those mechanisms, Mr. Borenstein's is "forging" his messages. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
> From: Nathaniel Borenstein <[EMAIL PROTECTED]> > This would be a very interesting philosophical argument if in fact what > we were discussing was something that could take a significant bite out > of spam. In the absence of such an ability, however, the real question > is whether user accounts should be crippled in the name of spam > fighting when the crippling *isn't* going to help significantly with > the spam problem. And that's not a philosophical debate, just a matter > of common sense.Grocery stores probably have the right to require > their customers to wear formal attire, but if they don't have a good > reason to do it, they're going to drive away customers no matter what > the outcome of any philosophical debates. Grocery stores frequently requires shirts and shoes. A better analogy is that grocery stores that sell alcohol or other regulated drugs are required to pay substantial extra costs. Complaints about monopolies in the beer and wine trade are laughed at, as are demands that pharmacies in grocery stores not charge prices high enough to pay their pharmacists. As Mr. Borenstein knows, a substantial fraction and probably most spam is current sent using $30/month consumer accounts. The spam that is not sent using such accounts is very easily blocked. As he knows, if providers of those services would either filter port 25 or terminate customers running trojan zombies, that spam would stop. Providers of those $30/month accounts have made clear that they cannot afford to hire the people to monitor and deal with their abusive customers. That is why many of the providers of those $30/month accounts submit their own IP address blocks to various "dynamic" backlists or block port 25 themselves. Stopping trojan zombies would not end the spam problem, but it would be a major improvement. You can see the truth of that in the results of UUNet's imposition of port 25 filtering on its dial-up resellers. It would also significantly improve security problems caused by Microsoft systems, because viruses and worms could be filtered by ISP SMTP servers from outgoing mail. >My expectation is that ISP's > who implement anti-spam measures that are both intrusive and > ineffective are going to drive away customers as long as there's a > better alternative out there, and I'd be inclined to simply let them do > it unless they're in near-monopolistic market positions. The latter > exception is important, however; I'd certainly be upset if my cable > provider did it, because I don't have any good alternatives. -- It is dishonest to imply that cable TV providers have near-monopolistic market positions in providing Internet service. They often have near or true monopolies in providing cable TV service. However, in no U.S. market do cable TV providers have anything like monopolies in providing Internet service. They may have monopolies in providing some of services at $30/month, including "Web connectivity," "Client only, non-public address," and "Client only, public address." Mr. Borenstein can buy Full Internet Connectivity from many service providers, although not at $30/month. Mr. Borenstein and others like him expect the rest of us to subsidize their $30/month connectivity by dealing with the network abuse of his fellow customers, because they find $30/month comfortable. That position would be less despicable if they would demand free Internet connectivity, since that is the only price that billions of other people can afford. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
> From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= <[EMAIL PROTECTED]> > > > block port 25 for all types of IP > > service except the one that draft-klensin-ip-service-terms-01.txt calls > > "Full Internet Connectivity." > I have a *very* hard time seeing an IETF document (or discussion on the > list) coming even close to endorsing this blocking malpractice. It does not > scale (forcing people to use central, probably misconfigured, relays, and > it is IMNSHO thorougly bad engineering to try solving L8 problems on L3/4. So say each of you who feel you have a right to pay less than what providing full internet connectivity costs. Full connectivity is priced at about $100-$250/month, and plausibly and apparently costs less to provide. The $20-$30/month services provided by the providers that cannot afford real abuse desks or local technical support are not really Internet service, no matter that you might wish. What I find really strange thing is the price point chosen for this divinely ordained right. Why is $300-$400/year ok but $200/month is a violation of your fundamental human rights? Why is paying what Full Internet Connective costs evil and wrong, but it is ok to pay more than the $300/year that people in some parts of the world live on for a whole year? The scaling argument is obvious nonsense. If having $30/month customers use SMTP servers provided by their ISPs did not "scale", then it would not "scale" to have those same customers use the routers provided by those same ISPs. If your ISP is incompetent at configuring an SMTP server, then whose fault is it that you continue to buy bad service? Why don't you treat your incompetent locl provider of "Client only, non-public address" or "Client only, public address" as a provider of those services and use them only to connect to a system where you get competent Full Internet Connectivity? If ISPs and their customers were willing to deal with spam, including immediately and permanently terminating customers that send any spam, regardless of whether they are paid for their efforts (e.g. operators of trojan zombies), then there would be no spam problem. Why should the rest of us subsidize your ISP and your connectivity by accepting SMTP/TCP/IP SYNs from your neighbors that are more than 99% likely to be spam from trojan zombies that your ISP cannot be bothered to terminate? Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: spoofing email addresses
> From: "Christian Huitema" <[EMAIL PROTECTED]> > > 1. block port 25 to external IP addresses for all of your customers > > except those with what draft-klensin-ip-service-terms-01.txt calls > > Full Internet Connectivity. > > ... and receive a flood of complaints because 10% of your users are > using a mail service provided by someone else than you. That's a significant problem, but so what? Stopping spam is not without costs. The spam problem exists only because service providers sell other than Full Internet Connectivity and cannot charge enough for the other flavors to squash abuse. The reason spam is a problem is that ISPs are unwilling or unable to pay the costs necessary to zap spamming customers. If spam were a certain path to termination with prejudice, there would be no significant spam. If ISPs would immediately and permanently terminate all spamming customers and refuse to exchange STMP/TCP/IP with other ISPs that fail to terminate spammers, there would be no spam problem and no need for blocking port 25 and so forth. If Microsoft would have been willing to pay the costs to ship secure software for the last 10 years, than the spam distribution mechanism currently favored by the worst spammers would not exist. > > 2. Do not sell Full Internet Connectivity to anyone running Microsoft > > software exposed to the Internet. > > Regardless of whether Microsoft's software can be secured (it can), As we all know, that is true in Microsoft marketing liturature and plausible theories but false in practice. As I said, practically all desktop Windows XP and NT installations have users running browsers and MUAs as "administrator." Contrary to the knowingly misleading statements from Microsoft appologists, that fact makes Windows a hopelessly insecure system. Then there are the versions of Windows not related to Windows NT that cannot be secured even in theory. > this > is a big no-op as a PC behind a "home firewall" is still at risk from > e-mail viruses and questionable web downloads. A PC running Microsoft software behind a "home firewall" for most meanings of that phrase including Microsoft's is not protected. It must not be exposed to the Internet. > > 3. The effects of #1 and #2 include forcing all mail from the usual > > suspects through your own mail systems so that you can do as the > > credit card companies do. Track SMTP envelope Mail_To values or > > other characteristics for each customer. When you see a change, > > contact the customer by voice to check. > > So the solution to Spam has to be a massive surrender of privacy! This statement is disingenous. No existing privacy is lost. It is just as false and dishonest to claim that the credit card companies reduce someone's privacy with their anti-fraud mechanisms. Exactly the same mail information is already present in ISP SMTP server logs. Privacy is not lost by people acting on your private information. It is lost when your private information is collected. Changing how computers manipulate your no-longer-private information does not reduce your privacy. Disclosing the fact that you do not have privacy does not reduce your privacy. If you want privacy, you must use cash instead of a credit card. You must also buy full internet connectivity, run your own SMTP client, and use at least SMTP-TLS, and of course, that's only a start toward mail privacy. > I am afraid that you are falling in the very trap that you often > denounce, present you personal definitive solution to Spam... My modest proposal would stop spam, but is not unique. As I wrote in words you did not quote, the spam problem results from service providers such as UUNet, Comcast, and Yahoo and software vendors such as your employer refusing to pay their shares of the costs to stop network abuse. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
> From: John Stracke <[EMAIL PROTECTED]> > >> (I've yet to see a proposal that works if the spammers start > >> utilizing zombie machines that snarf the already-stored credentials > >> of the user > >> to send mail) > > > > The question is whether spammers can obtain new credentials (stolen or > > otherwise) faster than others can blacklist them. > > And, if you had actually read the message you replied to, you would have > realized that the answer is yes. Send out a worm that makes N zombies, > have each zombie send one message under the local user's credentials, > and none of them will get blacklisted. Here's a defense for that scenario: 1. block port 25 to external IP addresses for all of your customers except those with what draft-klensin-ip-service-terms-01.txt calls Full Internet Connectivity. 2. Do not sell Full Internet Connectivity to anyone running Microsoft software exposed to the Internet. Possibly relax this with a $2000 bond forfeited along with connectivity at the first propagation of a worm or other spam. 3. The effects of #1 and #2 include forcing all mail from the usual suspects through your own mail systems so that you can do as the credit card companies do. Track SMTP envelope Mail_To values or other characteristics for each customer. When you see a change, contact the customer by voice to check. In practice, you could probably get by with detecting changes in mail volumes, since a spam spew of 1 message/zombie is at least 10 and probably 1000 times too low to be practical for high volume spammers. As far as I can tell, the typical user sends only about a dozen messages/day. Of course, the fatal problem with this spam defense is that it is not based on other people doing the work and paying the costs. It is not a coincidence that as far as I can tell Yahoo continues to be the most important U.S. host for Nigerian 419 spammers or that Windows XP practically requires or at least strongly encourages individual users to run their browsers and MUAs as "administrator." It is not a coincidence that sender validating systems including those Yahoo and Microsoft are based on the rest of the Internet doing most of the work. The howls from the Special People who feel that they are entitled to Full Internet Connectivity at prices and terms they find comfortable (and about the per capita income in large parts of the world) are also related to the fundamental cause of all spam. There would be no spam problem including worms if every ISP would look after its own problems by terminating all spammers including customers who let their machines be "owned" or if all users were willing to pull their own weight instead of expecting something for nothing. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
> From: [EMAIL PROTECTED] > > "The people who claim that something can't be done shouldn't get in the > > way of the people doing it." > > I didn't say it *cant* be done. I said there were known problems that any > successful solution would have to address. Another response is to point out that all of the sender validating systems are today only proposals that can be seen as getting in the way of effective tactics. The talkers trying to get in the way of the doers are, as usual, those who endless prescribe spam solutions that they themselves have not thought out, not to mention documented, tested, or deployed. The vast majority of the spam that sender validating systems might block after they have been installed in most SMTP clients 5 or 10 years from now is rejected today at any organization that really cares about spam using any of various tactics including DNS blacklists (e.g. the CBL or the so called "dynamic IP" lists) and greylisting. Essentially all of the spam that any sender validating system might someday block after large outfits like Comcast have installed validating code on their SMTP clients and servers would be blocked today at the source if those same outfits would block port 25 for all types of IP service except the one that draft-klensin-ip-service-terms-01.txt calls "Full Internet Connectivity." That is because current spam that would be blocked by sender validating comes "trojan proxies." The current state of the art in spam defenses reject more than 99% of spam with less than 1% false positives (or variations of those numbers such as 95% and 0.1%). No one who is actually do anything about spam is content with those numbers or confident that new tactics will not be needed, but please don't tell the experts who don't know the difference betwee an SMTP rejection and a bounce, lest they be encouraged to tell us some more what we really should be doing. As usual, the usual suspects who might someday get around to reading an RFC, any RFC, tell us that The Final Ultimate Solution to the Spam Problem is just around the corner. Their Finual Ultimate Solution is waiting for the obstructionists to get out of the way of those who will realsoonnow write the FUSSP RFC. Of course, the usual suspects can't be bothered to come down from Mt. Olympus to write a I-D or learn the relationship between I-Ds and RFCs. They don't care about the differences among documenting, testing, or deploying, or the chasm between practice and sidewalk superintendent theory. Probably the best response is to send people to the MADID mailing list. I've often said that the IETF is well served by working groups that do no more than absorb the energies of standards committee goers. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
out-of-office notifications
How many years must this stuff continue? If someone asked me, I'd say that the people responsible for the enclosed meant to ask the Secretariat to be unsubscribed with prejudice from all IETF mailing lists. Then there are people who send HTML out-of-office noise. This stuff is a tad ironic given the recently expressed concerns about bad guys checking the IETF attendance list. How about a Modest Proposal: no one be allowed to subscribe to any IETF mailing list without submitting evidence that Microsoft MUAs or MTAs are not in use. Those with sufficient clues to contribute usefully could doubtless arrange things so that even if they were using Microsoft virus, worm, spam, and OFN distrubution malware, their mail headers would lie. Vernon Schryver[EMAIL PROTECTED] > From: Eric Burger <[EMAIL PROTECTED]> > To: Vernon Schryver <[EMAIL PROTECTED]> > Subject: Out of Office AutoReply: spoofing email addresses > > Not reachable by e-mail or phone until 6/2, and then only by e-mail. > From: Paul Georgiou <[EMAIL PROTECTED]> > To: Vernon Schryver <[EMAIL PROTECTED]> > Subject: Out of Office AutoReply: spoofing email addresses > > Please note I will be out of the office from Friday May 21st to Tuesday May > 25th inclusive without access to email or Voicemail. For urgent matters > please contact Rosemary Hagholm, [EMAIL PROTECTED], 416-410-6050, or > David YoungPow, [EMAIL PROTECTED], 905-264-5785. > From: WaterCove Email <[EMAIL PROTECTED]> > To: Vernon Schryver <[EMAIL PROTECTED]> > Subject: WaterCove Email > > Hello, > > The watercove.com email address you sent to is no longer active. With the > recent acquisition of WaterCove by Alcatel, please contact the intended > recipient directly to get their updated email address. > > Thank you. > From: Joerg Reichelt <[EMAIL PROTECTED]> > To: Vernon Schryver <[EMAIL PROTECTED]> > Subject: Out of Office AutoReply: spoofing email addresses > > This message is in MIME format. Since your mail reader does not understand > this format, some or all of this message may not be legible. > > --_=_NextPart_001_01C4436B.0F91EDC0 > Content-Type: text/plain; > charset="windows-1252" > > I am currently out of the office and will be back on 6/14/2004. In case of > urgent matters, please contact > Eric Yuan > (408) 944-4928 >[EMAIL PROTECTED] > > Thanks, > Joerg Reichelt > > --_=_NextPart_001_01C4436B.0F91EDC0 > Content-Type: text/html; > charset="windows-1252" > > > > > > > Out of Office AutoReply: spoofing email addresses > > > > I am currently out of the office and will be back on 6/14/2004. In > case of urgent matters, please contact > Â Â Â Eric Yuan > Â Â Â (408) 944-4928 > Â Â [EMAIL PROTECTED] > > > Thanks, > Joerg Reichelt > > > > > --_=_NextPart_001_01C4436B.0F91EDC0-- > ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Request for comments on draft mail protocol
> From: James Denness > I am currently involved in a project to create an internet-draft for a > domain/key based system allowing mail domains to be validated using rsa > keys, distributed using the DNS system, with minimal modification to > existing infrastructure. Does a specification for such a system already > exist? I have many ideas for extentions to the existing SMTP protocol, as > well as plans for a derivative protocol incorporating this key-based > system as a more secure and verifiable method of exchanging mail. If > anyone is interested, I would appreciate being contacted off-list to > discuss the possible formation of a working group to discuss such ideas. what about http://ietf.org/html.charters/marid-charter.html ? It might be interesting to contact the author of draft-delany-domainkeys-base-00.txt or the authors of the at least half a dozen other proposals to use public keys or other mechanisms along with the domain name system to authenticate mail senders. My rather negative view of the area can be inferred from http://www.rhyolite.com/anti-spam/you-might-be.html Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
> From: Andrew Newton <[EMAIL PROTECTED]> > On May 24, 2004, at 1:49 PM, [EMAIL PROTECTED] wrote: > > > > In fact, there isn't any sane way to detect "inconsistent" header > > information > > without external hints - this is the reason why there's the SPF > > proposal, the > > Yahoo domain-keys proposal, and Microsoft's proposal. > > And MARID. I don't see any of those proposals and their competitors as sane. Some of them, such as SPF, do not even meet their own design goals as stated informally by their advocates. Others such as domain-keys do not seem to do anything that is not already done by SMTP-TLS, despite the goals in the I-D that seem to be closer to S/MIME. None of them have much to do with spam, but only with a currently popular mode of attack used by spammers. None have any hope of affecting even that particular attack mode for years, because none can have any significant effect until deployed on most SMTP clients. Many seem to be based on insufficient familiarity with the nature of SMTP (e.g. SPF's incredible source-routing scheme) and the urge to Do Something Now regardless of actual results. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Categorization of TCP/IP service provision types
> From: John C Klensin > ... > However, the above statement just isn't true unless the > collection of terms and conditions I've seen are a very odd > subset. "You will not run a server" is typical. "You are > required to use ours" is much less common, and is often > associated with a commercial motive, e.g., "you are required to > use ours, and our domain on your outgoing mail, unless you pay > us more money". I agree my words are wrong. I'd forgotten port 587. When they say "you will not run a server" they are also implicitly saying "you will use someone else's MTA instead of your own." You're right that they don't prohibit the use of SUBMIT, POP3, or perhaps even port 25 SMTP to reach an allowed MTA. However, when they say "you will not run a server," they do not mean "you will not run an SMTP server" in the sense I undestand "SMTP server." Most people think "mail server" is any MTA and not only a system that answers port 25 to receive mail. As I think you've said elsewhere, it is best to ignore service providers' motives. That allowing customers to run "servers" increases provider costs for bandwidth, technical support, and abuse handling is irrelevant. The document should not spell out business models any more than it should have a matrix of all possible combinations of offerings or technical details of how the limitations of the various types of services are implemented. Vernon Schryver[EMAIL PROTECTED]
Re: Categorization of TCP/IP service provision types
> From: John C Klensin
> ...
> > 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
> ...
> 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.
That's all true. The details of the reasons and excuses for not
dealing with abuse except when coerced by lawyers or badges vary
and are not germane.
> 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.
exactly.
> 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.
No, the rational reason to blacklist "dynamic" addresses is that
blocking them stops a lot of abuse while affecting very little legitimate
traffic. Whether the high true positive and low false positive rates
are because providers choose to ignore complaints or some other reason
is, or needs to be irrelevant in this document.
Perhaps it would be enough to say just that, along the lines of
... mail directly from the IP addresses of customers of X instead of
via MTAs run by service providers is rejected by much of the rest
of the Internet because it is almost certainly "spam" or otherwise
objectionable. The terms of service of X usually require the use
of MTAs operated by the service provider and prohibit the operation
of MTAs at the customers' IP addresses. Practically all legitimate
mail from users of X use their service providers' MTAs. Some service
providers use technical mechanisms such as "port 25 filtering" to
enforce their terms of service that require that their customers'
mail use the providers' MTAs.
("X" because I'm not sure about factoring that text into each
of the 1st three descriptions or having it one place.)
> 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.
That sounds right to me.
Vernon Schryver[EMAIL PROTECTED]
Re: Categorization of TCP/IP service provision types
> From: "Spencer Dawkins" > I like the idea, and your draft is more than a skeleton plus examples. quite true. > ... > - The client/server orientation doesn't explicitly handle peer-to-peer > connectivity (unless all the SIP clients have to be servers so they > can receive incoming phone calls). Saying "I want incoming phone > calls" is different from saying "I'm running my own mail server". So you say now, but wait until the ROKSO spammers discover the bonaza in VoIP. Instead of "owned" proxies pumping email, they'll use the same boxes to push pre-recorded voice messages. For mail, the filtering at issue here has not been against incoming mail to local SMTP servers but outgoing mail from local SMTP clients. An ISP might want to filter against incoming port 80 so customers can't use lots of the ISP's bandwidth on their HTTP servers, but against outgoing port 25 to minimize the ISP's abuse handling costs. The DUL DNS blacklist filtering that non-spammers whine about would be that if it existed but currently is entirely at third party ISPs and mail targets. It is entirely orthogonal to and independent of the filtering John wrote about. It is a reaction to the lack of filtering done by the low priced ISPs. Of course, none of those words belong in John's document. Of course, I'm not serious about VoIP spam. To start, the bandwidth needed for 10,000,000 5KByte spam is less than the bandwidth needed for 10,000,000 60 second phone calls. Vernon Schryver[EMAIL PROTECTED]
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: "Principles" of "Spam-abatement"
undamental 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 -- 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 No, simply forwarding completely and faithful copies is more than sufficient. > 17.76.215.200.in-addr.arpa domain name pointer > BrT-S4-1-2-22-bnuce300.brasiltelecom.net.br. I can't get a PTR RR for 17.76.215.200.in-addr.arpa. Whether you use reverse-DNS and whois or whois on the IP address is a minor, irrelevant technical detail. (Yes, I know Ralsky and others play games with PTR RRs.) > 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. We don't need any "chains of responsibility." EIther Brasiltelecom deals with its spam or it doesn't, just like the zillions of other outfits that do not have the reputation of a Brasiltelecom, Comcast, or UUnet. How Brasiltelecom manages that trick is none of our business, unless we are customers or employees. > I just don't think that the idea has been fully tested yet. To properly > test it, a certain amount of infrastructure would have to be built -- > not a horrible lot, actually, but some. And the process of complaining > in a standardized way would need to be made "one click easy". ... NO! If Duke or AOL want to do that for its users, then fine. If not, that's also fine. All that matters is that you accept responsibility for your own incoming spam and deal with it by cutting off the sources. You don't need any "infrastructure" to add to a sendmail access_db or a router firewall. (I've heard that AOL has a "this-is-spam" button.) > > The first part is nonsense spread by spammers and dishonest, spam-friendly > > ISP spokeslime. ISPs have no problems terminating customers with less > > than minimal evidence. > Yes, I don't quite understand why people keep talking about suits and > such. We all know why people go on about suits and such. It is because they have something personal to lose if spammers are routinely terminated. That is variously cheap services subsidized by the lack of an abuse desk at their ISP, services subsidized by revenue from spammers, a desire to get rich or at least famous by flogging a Final Ultimate Solution to the Spam Problem (FUSSP), a job at a spam haus of an ISP, or a job at a spammer. I realize this observation is impolitic, but it's past time to be honest about the motives for the persistent nosense about spam. Vernon Schryver[EMAIL PROTECTED]
Re: "Principles" of "Spam-abatement"
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 | > 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). True and relevant, but only in the sense that any outfit that might sell trust assurances might have trouble doing it for $30/month. | Your bank, OTOH, is probably | doing nicely on less than $30-per-month service charges. If that is true, then an ISP could do the same. I think it is true only in a facile and fundamentally false sense. My banks makes money on more than my explicit service fees, which are approximately $0/year. | Also, some | ISPs have no reason to worry much about their reputation, because | they have in effect a government-mandated near-monopoly. No matter how often anyone says that, it remains false. By now the base motives for that old nonsense should be considered. Outside some totalitarian regimes, there are no monopolies of any sort on real real Internet access. There are monopolies on some imitation Internet servcies at price points that some claim are related to basic human rigts, while expecting us to ignore the fact that the $15-$35/month point they claim necessary to protect their basic human right to send mail is 10 or 100 times too high for the vast majority of humanity. | > - 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? Currently the ISPs certified by your choice among your personal blacklists, the SBL, CBL, XBL, SPEWS, MAPS, ORDB, etc. | ... |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. The second part of that is relevant. An ISP that refuese to terminate a spammer for fear of lost revenue does not have any IP addresses that many of us want conencted to our SMTP servers, The first part is nonsense spread by spammers and dishonest, spam-friendly ISP spokeslime. ISPs have no problems terminating customers with less than minimal evidence. Within the last 10 days, I watched a business customer, not merely a home end-luser, get cut off by a major ISP with telco connections for some time because it failed to respond to a report of mine. Of course an ISP must be careful to avoid breaking contracts and so forth, but that does not prevent termination. Why else is the spam advertising "bulletproof hosting" common? Vernon Schryver[EMAIL PROTECTED]
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: 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: 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
> 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: Apologies for the irony (was Re: Principles of Spam-abatement)
> From: Nathaniel Borenstein >...you > can't afford an expensive connection ... > ... it's not > primarily about property rights, it's about our right to choose to > communicate with each other. If the second were true, the first would be irrelevant. That the first is relevant shows the "right to choose to communicate" is nonsense, except in the same sense as the costs of gasoline and real estate limit your right to travel, live, and work where you want. > PS -- Are you really rejecting all mail from comcast.net? Just > curious, that's a lot of people. And if it's guppylake.com, it would > have been nice if someone had told me when I was blacklisted, seeing as > how I'm the administrator. I suspect it is Comcast, but in the same hypothetical, contrary to facts spirit as your other questions, let's assume that it is guppylake.com. How would you be entitled to or even just expect notification? If I set my (non-existent) caller-ID filters to reject phone calls from you, would you be entitled to or expect a notice? Even if you were a telemarketer, why would you care? What if Qwest did the rejecting for me? I suspect your answers for the two media differ and that you have not considered your position on Internet access except from an emotional sense of entitlement and of hurt and outrage at being snubbed by various blacklists. Vernon Schryver[EMAIL PROTECTED]
Re: Principles of Spam-abatement
> 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.)? 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. - 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. On the other hand, it would be distructive to let the IETF seriously consider supporting claims of the unfettered right to send mail regardless of the desires of mail targets and their duly appointed agents including ISPs or of entitlements to real Internet access at less than $50/month. That would further the ambitions of many to convert the Internet into what PTTs and governments said we might be allowed 20 years ago. 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. Vernon Schryver[EMAIL PROTECTED]
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]
Re: Principles of Spam-abatement
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 distant providers, thanks to the wonders of ATM clouds and other mechanisms. It often costs more than the service you can buy locally, but that local service is often not Internet access. It is often (in my view) a strangely crippled imitation that is to Internet access as straw is to wheat. > 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. You are not stuck with bad AUPs for Internet access. You could always buy real Internet access elsewhere and use the data services of your local providers to reach your real ISP. That you would have to pay more than $30/month is just too bad. That I can't get $30/month imitation non-Internet/cable modem service because I live in the woods is also just too bad. > 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 That is offensive nonsense. The only right yours that is being abridged is your supposed right to buy Internet access for $30/month. Vernon Schryver[EMAIL PROTECTED]
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]> > ... > 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: paralysis
> From: Dave Crocker > Serious discussions about spam control acknowledge the fact of > limited, incremental benefit, significant deployment costs, potential > impact on basic modes of legitimate email, and the like. > > Unfortunately, serious discussion is rather rare. What is missing from > most proposals is any interest in such careful consideration about > ramifications. No, let's be honest no matter how impolitic. What's out of order from most anti-spam discussions is anything that might squelch the urgent, exciting, and positive talk. That certainly includes consideration of inconvenient ramifications and obvious technical issues. The taboos also cover any sentiment like "Ok, I'll implement this and report back soon with results." (Recent example technical issues: SMTP-TLS does not imply commericial PKI, except in the sense that commercial PKI is the only working(?) model of large scale key distribution. No law, standard, or anything else prohibits an SMTP relay from using the same authenticator on output that it used on input for a message.) > Instead, efforts to explore real costs and real efficacy are met with > the usual plea that this is an emergency and we have to do _something_. That's true only in the sense of urgent pleas that _other_ people to do something. Every month or so, I check the ASRG archives. If there has been a change in the last year, I can't see it. It's all urgent, and devoid of anything like reports of actions. Even survey and BCP documents start and then fade into the mist. I just now checked https://www1.ietf.org/mail-archive/working-groups/asrg/current/maillist.html to see if I'm being unfair. Of course this problem is endemic to the Standards Process. It's worse with spam because the problem hard verging on unsolvable and few if any of the participants are trying to ship a product before market window closes, graduate students trying to complete a thesis, others trying to publish papers before the grant runs out, or mail system operators trying to avoid drowning. There are vendors and so forth, but they see that it might make sense to ship, install, or test a white box with Linux and SA but it is silly to spend any salaries or time on "proposals" that can't have any effects before the spam problem is finished by other effects. > ... > The IETF MARID BOF showed that serious discussion is, in fact, possible. > One simply needs to insist on it and encourage it when it happens. If http://www.imc.org/ietf-mxcomp/mail-archive/msg00067.html is reasonably accurate, then I beg to differ. As far as I can see, it could be a summary of the most useful content of ASRG mailing list from March and April, 2003. = ] From: Paul Hoffman / IMC ] ... ] The majority of the "anti-spam" proposals being actively discussed ] are variants on the "prove the sender is who he says he is". None of ] these are perfect, yet: Given the shift of many major spammers from forging domain names to using their own throw-aways like xxcdfm1.com, pointlesstomovehere.com, and attractiveinternetnews.com, "not perfect" is an understatement. ] - they are being actively discussed in the ASRG Somehow "actively discussed" is doesn't quite convey "continually discussed round and round without any change." Vernon Schryver[EMAIL PROTECTED]
Re: paralysis
> From: Michael Thomas <[EMAIL PROTECTED]> > ... > So... instead of pointing out the obvious that > there is no silver bullet, wouldn't it be a lot > more productive to frame this debate in terms of > what incremental steps could be taken to at least > try to change the overall climate? To perhaps move > things in a direction that might be in our favor? > To perhaps be open to making some mistakes and/or > no-ops? Am I interfering with incremental debate framing, climate changing, or designing, implementing, testing, and deploying possible solutions that might be mistakes and no-ops? I hope not and I don't think so. In about 1997 Paul Vixie mentioned the notion of spam checksum clearinghouses. I pointed out the obvious problems, but 6 or 9 months later hacked a form of the idea into sendmail. The DCC is now resisting about 350,000,000 spam/week. When I heard about greylisting, I pointed out some obvious problems, but worked hard to add it to the DCC client code. That a problem seriously wants a solution does not imply that it has one. That personal immortality, matter transmission, and communicating consent to receive mail sound nice does not imply that they are possible or that they would solve more problems than they would create. Either way, lists of problems from wet bankets like me should not stop anyone from designing, implementing, testing and deploying, unless they need to sell a lot of stock beforehand. > We know spammers are smart and adaptable. The > problem is that in our paralysis, we are not. Whose paralysis do you mean, Kemo Sabe? Outside the mass media, mailing lists, and usenet, plenty is being done about spam. Some efforts have been more effective than others. Others such as laws have more future hope than past performance. Filter effectiveness above 95% is common. Reasonably spam free mailboxes that are open to mail from perfect strangers are more readily available today then they were 3 years ago. Nothing so far have been or will be a silver bullet. Unless you believe vague handwaving or swallow any of several brands of patent medicine, there is no prospect of a FUSSP (Final Ultimate Solution to the Spam Problem). By itself, framing debates is not productive unless you're only interested in debates. Few of those who do more talking and writing about spam than administrating anti-spam mechanisms, designing, writing or deploying code, enforcing laws, or anything else that directly affects spam in more than their personal mailboxes are contributing to solutions. Vernon Schryver[EMAIL PROTECTED]
Re: Proposal For Token-Based Authentication In Mail Submission As Anti-Forgery Effort
> From: "Sabahattin Gucukoglu" > ... > and important catch in this proposal, that being a modification to all > MUAs and MTAs to allow the acceptance and carrying of a password token > which should persist throughout the entire mail delivery, ... > My proposal is a scheme for anti-forgery, which makes use of a non-blank > token, or password, which can be verified by a recipient system ... How does your scheme prevent forgery better than SMTP-AUTH, SMTP-TLS, S/MIME, or PGP? Most MTAs support SMTP-AUTH and SMTP-TLS. The difficulties in preventing spam sender forgery are not in defining token protocols but in - defining forgery in a way that excludes common, legitimate practices. Why isn't sending mail with your Hotmail account as sender while sitting at your desk at work or with your work sender address while in a customer site, hotel room, or airplane "forgery" that would be prevented by the proposed sender-verifying mechanism? - key distribution. Verisign/Microsoft would be happy become the toll collecter for all Internet mail using the current or a variation of the current commercial PKI. Some of us are not keen on that idea. All other key distribution mechansims have their own substantial problems, including those that would use the DNS. - preventing spammers from buying as many tokens as they need. The major spammer that currently calls itself Zhang Jun and Qing Zhang has been burning several new domain names per day for the last 2 or 3 months. Why won't it be able to make or buy tokens to go with each of its domain names? Why won't domain2004.com, managernic.com, namelite.com, nicsimple.com, sitesadmin.com, and the rest of its DNS servers serve its SPF RRs or your password tokens as readily as they serve NS, MX, and A RRs? Why can't it replace those DNS servers as they become recognized with new DNS servers, as it has been doing for years? > 1. Sender MUA submits message through some host X, indicating token to X > using the stok extension to be defined in SMTP as an extention to its > "mail from:" command: > mail from:<[EMAIL PROTECTED]> stok=blorb > ... > 4. MX begins a password query. It must connect to some kind of password > query resource. The MX may connect to a designated MTA for a domain and > use the stok keyword to query for a password (>>"stok blorb" <<"250 Token > is tasty!") or some other simplified database query. ... > 5. Authenticated submitters are welcome, unauthenticated submitters > aren't, policy-dependent. ... Have you looked at SMTP-AUTH? What about SMTP-TLS with verified certs required? I hope you won't be too offended if someone points out http://www.rhyolite.com/anti-spam/you-might-be.html I wrote it during the first months of the ASRG mailing list. Vernon Schryver[EMAIL PROTECTED]
Re: Principles of Spam-abatement
> From: David Morris <[EMAIL PROTECTED]> > ... > Well, I don't read such mail if I can avoid it ... I have never received > email of value where there was no pre-existing 'connection'. People with > business opportunities with mutual value continue to take the time to use > the telephone even though email would be a viable alternative. > ... Your experience differs from mine and I think other people's. I'm talking about entirely non-bulk, purely private, I think unsolicited mail business proposals from strangers. If anything comes of the contact, telephone and face to face meetings often occur, but email is often the cheapest (not just in money or time) way for an initial contact. Vernon Schryver[EMAIL PROTECTED]
Re: Principles of Spam-abatement
> From: Paul Vixie > ... > unsolicited, uncoordinated communication is wonderful, and i miss it. let's > build a universal electronic trust hairball so that we can get it back again. > right now my choice is "deal with yahoo's endless unconfirmed spew" or "not > be able to join any of the mailing lists my neighbors have set up there" and > i would like a finer grained selection than that. What does a transitive/secondary/whatever trust protocol have to do with that? Yahoo! is already the outfit bonding/hooking/whatever all of that mail with its IP addresses. Changing the label on what they do to "transitive trust" will not by itself affect their policies and practices. As long as Yahoo! chooses to run mailing lists and domain names the way they do, no matter how many tokens of trust or crypto certs they slather on, their mail will remain what it is. If Yahoo! would impose real penalities for abuse of its current certificates of trust, the IP addresses of its mail systems, or do anything else that really ensures that those who sign up for new domains or new mailing lists are trustworthy, then there would also be no need for newfangled tokens or certificates. If Yahoo! would not always respond to reports of spam involving its domains with "It didn't come from us so it's not our problem" even with it did come from one of its IP addresses, then Yahoo!'s IP addresses could be certificates saying "This is not spam" as trustworthy as sa.vix.com [204.152.187.1]. I'm not arguing for IP addresses as security tokens. I'm only pointing out that issuing new identity cards to the usual suspects won't change anything. No IETF protocol can synthesize trust for organizations that are not trustworthy. Service providers that host spammers and expect spam targets to deal with abuse will never be trustworthy. Most of the TBytes/day of spam comes from such providers, whether cable modem outfits that turn blind eyes on "owned" boxes, free providers whose penalty for abuse consists of making the spammer sign up for a new drop box, or tier 1 providers that lie about the impossibility of determining which of their resellers is hosting a spammer. Vernon Schryver[EMAIL PROTECTED]
Re: "Principles" of "Spam-abatement"
> From: Paul Vixie <[EMAIL PROTECTED]> > ... > that's not an unreasonable question. and yet, the meatspace world copes. The real world copes only by having laws against enforced violations of trust. Until the first spammer goes to jail for breaking the laws that have long made most current spam illegal, all talk of trust fixing spam is academic. If the activities of the ROKSO 200 really get them real penalties, then talk of trust vs. spam becomes relevant, but only for as one among many fixes for what is currently a trivial part of the spam problem, the spam from people who are not criminals. > the thing cybertrust hasn't done is to take advantage of existing meatspace > relationships. ... >... meatspace world and its millenia > of traditions and mechanisms, trust clearly can scale. It is not trust that scales but police. There is no transitive trust in the real world. There are only bi- and sometimes trilateral contracts and lots of people with guns ready to punish those who break trust. If transitive trust were even in the real world, buying a house would not be such a big expensive ritual with escrow, title insurance, and so forth. If trust "scaled" in the real world, it would be a lot easier to get the title for your car converted from one state to another. Some might offer title insurance as a model for stopping spam, but only if they've never paid for it. > if your bond is only $30/year then i probably wouldn't trust you no matter > what my bank told me about your insurance company or what your insurance > company said about you. remember, i don't want to know who you are, i only > want to know who you know. if the world has no hooks into you then i would > withhold my consent. presumably there are others who would only give consent > if your religion was the same as theirs or if your identity was known -- but > that all fits under the "all communications by mutual consent" banner. There are problems there. First is that you are not talking about anything that might be called "transitive" trust. The word "transitive" is wrong and misleading. Please use something like "secondary trust" or "bonding" or "letter of recommendation." Second, as Dave Crooker wrote, your "hooks" are too nebulous. There's a cool and relevant article in the March-April 2004 issue "American Scientist." It concerns how religious groups manage to trust their members. The problem/analogy with your trust model is that mail is not worth $30/year to anyone, not to mention self-mutilation. How much does a "check guarantee card" or real estate title insurance or a jail bail bond cost? > ... > unpleasant distinction between the transport and mailbox, and it *will* get > replaced with something that can carry trust indicators and deal with > multilevel agency. but the real and larger work is the meatspace-sized trust > web, without which smtp is probably as good as e-messaging can ever get. I do not agree, but mostly because I doubt that vastly larger goal of "a meatspace-sized trust web." Whether SMTP disappears doesn't matter to me. I was using email long before it appeared. And I say again: every time you, with your standing, even whisper about replacing SMTP with a protocol that carries trust tokens, you give aid and comfort to spammers and the parasites using the spam problem. Regardless of what you mean, they translate your words as "Paul Vixie agrees that TOES/SPF/RMX/SMTP-AUTH/CalleriD/HashCash/E-postage/... is the Final Ultimate Solution to the Spam Problem." Vernon Schryver[EMAIL PROTECTED]
Re: "Principles" of "Spam-abatement"
> From: Paul Vixie <[EMAIL PROTECTED]> > ... > we are eventually going to be able to tell whether a message was generated > by someone who was present and gave consent, or whether it's just wormware; > and whether the owner of an ip-using device intends to act as a mail server; > and whether a bond has been posted by this present/consenting sender and if > so how much; and whether there exists or not a trust path from the sender, > through their bank or school or employer or insurance company to the > recipient. the internet doesn't care what your meatspace identity is and > anonymity is a necessary way of life -- but we do care very much whether > transitive trust exists. "who you are" matters less than "who you know", > and this is true not just for messaging but also for web service accounts and > passwords, for trading and payments, and for so-called "social networking." The trouble with that is that trust is not and cannot be made transitive. There is a finite chain of people that connects you with anyone you care to name, with each person asserting any sort of trust you want for the next person in the chain. The chain that connects you with Al Ralsky for the trust operator "the next person to corrently identifies people" is probably shorter than 6 people. The chain that connects you with Ralsky for "next person to does not spam" is probably longer than 6, but shorter than a couple dozen. Even worse, the chain the connects you to Al Ralsky for "the next person is not Al Ralsky" is probably shorter than the first, short chain. The notion of transitive trust makes as much sense as assuming that all of the keys on the key rings of the people who will be signing PGP keys at the IETF this week are of people who you can trust to not send you mail you'd not want. In the real world, there is nothing like transitive trust. That's why it is so hard to cash third-party checks. The closest you can get to transitive trust is something like the check clearing system, which has only about 5 parties, with three (the two banks and the Federal Reserve) so entangled that they can be considered a single outfit. And check forgery remains a major problem. If transitive trust could be made to work, then government security clearances would be easy. If it could work, we would have more than 3 credit reporting agencies, and we would not have so much machinery to deal with their errors. If transitive trust cannot be made to work for those cases where there are major penalties for cheating, how can you expect to make it work for mail, which no one values at more than $30/year/seat? You might say that you don't want fully transitive trust but only to trust the people who know people you know. If you want that kind of mail system that does not carry message between strangers, you've already got it with any of the many kinds of whitelisting. These problems with trust have nothing to do with the network protocols involved. They are fundamentally non-technical. Talking about replacing SMTP to implement transitive trust is at best a distraction. Vernon Schryver[EMAIL PROTECTED]
Re: Principles of Spam-abatement
> From: Paul Vixie <[EMAIL PROTECTED]> > ... > > And everyone else needs to move from the generic reference to > > "consent" on to something that is more concrete, as well as being > > integrated into a full range of human uses for email. > > i'm pretty comfortable with www.dictionary.com's definition of "consent". That is the fatal flaw in the calls for technical mechanisms "communicating consent" to fix spam. Webster's definition of consent also applies to keeping solicitors from knocking on your door and bandits from mugging you on the streets. What keeps enough of them from lying about having your consent are the non-technical protocols of the justice system. No matter what additional token of consent that you require spammers to present to demonstrate that you have agreed to their mail, either spammers will be able to forge it or legitimate strangers won't be able to obtain it without contacting you or your agents and ceasing to be strangers. The usual response to that (and one which I think you've suggested) is to have a third party act as your agent. But that is exactly equivalent to the Microsoft/Verisign crypto authentication FUSSP. Whether SMTP is involved is irrelevant; the fatal flaw of such agencies applies to any messaging scheme. It is that unless a mail identity is practically unforgeable thanks to $10,000 costs or enforced legal penalties, spammers will sign up for new identities as each is executed for spamming. If an identity costs less than $50/year and there are no enforced laws against having as many identites as the recent spurt of "Zhang Jung" and "Media Dreamland" domain names, it will be impossible for your consent/identity/reputation agency to ensure that 1000 of the next 1,000,000 applications are really Al Ralsky in disguise. There are other problems with the "consent" or "identity" or "reputation agencies" that are often talked about. One is that giving Microsoft/AOL a franchise to levy a $0.001 toll on or append an ad to every message in the Internet is a Bad Thing unless you are stockholder. These problems have nothing to do with SMTP. You give aid and comfort to the spammers and parasites on the spam problem by suggesting that a replacement to SMTP might solve these non-technical problems with "communicating consent." You are implicitly supporting the worse than snake oil being flogged as spam solutions by big outfits. Vernon Schryver[EMAIL PROTECTED]
Re: Principles of Spam-abatement
> From: John Leslie <[EMAIL PROTECTED]> > ... >But I, at least, am thinking in terms of an implementation where we > notify the SMTP-sending-server during the SMTP session, with a message > including a URL for more information. IMHO, this would tend to converge > to a situation where end-users understood the issue -- and learned to > route around it. ;^) Where is the business of the main IETF mailing list in that suggestion? It is already a de facto standard. Many and probably most well run SMTP servers include an appropriate message in their 5yz rejection messages when spam detection is the issue. Today an appropriate message is often a URL. There are details that could be officially standardized such as formats that MUAs could more easily recognize and present to end users. The bounces generated by the near-end MTA after a failed SMTP session are incomprehensible to many people. Some MTAs (e.g. Hotmail's when I last checked) include random text in their session transcripts apparently drawn from random SMTP sessions during that last several hours. However, this sort of standardization seems more appropriate for some SMTP WG or the ASRG than here. Vernon Schryver[EMAIL PROTECTED]
RE: digital signature request
> From: "Robert G. Brown" <[EMAIL PROTECTED]> > ... > It has been pointed out several times now that unless you are willing to > receive mail only from a small, closed group of individuals that all > agree to use digital signatures and whose mail you whitelist while > blacklisting EVERYTHING ELSE you are right back where you are right now. > ... If you are interested in that model, then you do not need any fancy cryptography, certs, pretty good encryption, S/MIME, or anything else not already present in all SMTP mail. You can whitelist using bits that are already associated with every SMTP mail message and in the body delivered to your MUA if your MTA is not broken junk. Ever mail message carries a practically unforgeable (for spammers) token identifying its source. That token is the IP address of the SMTP client. If your MTA is reasonable, it is included in the Received header it adds. You only need fancy extra stuff if you cannot arrange for your community to use only trustworthy MTAs or if your traffic is worth the thousands of dollars (or equivalent labor) that breaking security based on IP addresses requires. Yes, I've heard of Bellovin, Mitnick, RFC 1948, etc. so forth and so on and on. TCP ISN faking is harder now than it used to be. It was always incompatible with the "bulk" in "unsolicited bulk mail." The spam problem starts with accepting mail from strangers. Give up that design goal, and spam disappears. So does much of the justification for mail. Vernon Schryver[EMAIL PROTECTED]
Re: digital signature request
> From: Ed Gerck > ... > If we force strangers to jump some hoops before their email can reach > our mailboxes, it seems clear to me that we can still keep receiving > email from strangers. That is the e-postage and other...I'm sorry but the best phrase is "snake oil." There is no and can never be a hoop that is low enough to pass enough human strangers but exclude spammers' computers. If your hoop passes mail from - the deaf - the blind - those who don't understand the spoken form of your native tongue as well as a computer - those who don't use graphics (e.g. lynx) - whose whose computers don't play audio files (mine doesn't) - those who don't have computers made within the last 5 years - the tired, confused, or intoxicated - the lazy or disinterested - the mentally challenged or just plain stupid then it will also pass mail from spammer's computers. The idea of forcing your correspondents to jump through hoops that spammers' computers can't is fundamentally wrong and crazy. If there is one good characterization of the difference between human and mechanical minds it is that machines are far better at jumping through hoops than we are. Computers are happy to try a bazillion times until they get it right. We get bored. A spammer's computer will happily continue trying to guess the answer to your puzzle as long as you let it, or look for it in a crib sheet of 1,000,000,000 clues. We not only won't; we can't. Only the meta-hoop of fear of prosecution might work. 419 spam demonstrates its severe limitations. Vernon Schryver[EMAIL PROTECTED]
RE: digital signature request
> From: [EMAIL PROTECTED] > ... > false positives. even *one* false positive is > unacceptable. even if my filter accuracy was 99.99% i > would still need to trawl my spam folder to check for > false positives. and as the spam volume continues to > grow trawling the spam folder takes more and more > time. i need to stop false positives and digital > signatures are one possible solution. Digital signatures cannot stop false positives. Even if all mail were digitally signed, there would still be cases where the wrong key was used, the right key did not reach the mail recipient before the mail message, a cert expires, or something else hiccups. The underlying error rate for SMTP before spam appeared was worse than 0.01%. Do you think that 99.99% of HTTPS (HTTP over TLS or SSL) transactions work? If so, look again. If not, why would email be better? If you cannot afford even one false positive, then you had better give up on email. My spam load is more than 300 messages/day, counting only unsolicited bulk advertising. I receive 50-150 legitimate messages per day. It would be impossible for me manually filter that stream to 99.99% accuracy and so overlook fewer than 1 legitimate message per 10,000 or fewer than one per month. No one can look at 10,000 messages per month, never misclassify any as spam or not, and do any other work. Talk about not losing even one message makes sense only if you receive almost no spam. People who talk about 99.99% accurate spam filters as if they were possible - don't know how computers work in the real world (e.g. have no idea why the phrase "key distribution" makes some people cringe or assume the tooth fairy handles key revocation) - don't receive much spam - are innumerate - are charlatans. - are two or more of the above. At least weekly I'm told of yet another final ultimate solution to the spam problem with 100% accuracy. They are all frauds, like weight loss diets without hunger or any other inconveniences. Sometimes they have creative definitions of "spam" and "false positive." Usually they are merely obvious wishful thinking and nonsense, like the hoary old claim that authentication (including digital signatures) will stop spam. Vernon Schryver[EMAIL PROTECTED]
Re: digital signature request
> From: [EMAIL PROTECTED] > ... > > Having the latest tools means nothing, unless they are used right. Are > > i'm using them correctly I, for one, am unconvinced. I have had no trouble filtering unwanted mail from this list, thanks to procmail. My various filters have no trouble dealing with more than 99.9% of the unsolicited bulk mail including viruses and worms directed at my mailbox. For my mail, my filters have a total false positive rate (legitimate rejected divided by total legitimate) of less than 0.1%. Whether your filters are doing as well as you want them to does not seem like a concern of the IETF. > ... > the value in having the list processor sign all posts > is simple. guaranteed identification of the list > traffic for any recipient who decides to verify > signatures. I think it would be simpler for all concerned and in this case just as effective if the IETF list processor would offer to do SMTP-TLS and for an appropriate cert to be published on http://ietf.org/ However, I would not suggesting that for any practical or operational reason. It would merely set a good example. Vernon Schryver[EMAIL PROTECTED]
Re: How Not To Filter Spam
> From: Ed Gerck <[EMAIL PROTECTED]> > > If a complete stranger is the sender of an incoming message, then > > crypto keys are irrelevant to determining the message is unsolicited > > bulk. > > No. In PGP, for example, I accept a key based on who signed it and > when. If I can trust the signer(s), I may use a key from a stranger. That sounds like the old "authentication solves spam" hope. It was wrong before SMTP-AUTH and it is still wrong. If the sender is a stranger, then by the definition of "stranger" you can know nothing more than that the key works. You cannot know whether the stranger is one of Alan Ralsky's myriad of aliases delivering spam. > > The PGP mantra that a good key does not imply that the sender or the > > message is good applies here. > > Define "good key" and you'll define what the key is good for. The ancient PGP mantra refers to keys that "work," as in the results of decoding using the indicated public keys yield a valid messages. The key can be good, but a good key tells you nothing more than that the sender of the message knows the corresponding private key. Would you trust every PGP key from the IETF key signings to guarantee that a message is not spam? Some IETF participants have been unashamed senders of unsolicited bulk commercial advertisements. The person I'm thinking of objected to his entry in my blacklist by insisting that although he had sent the triggering message, it was not spam because he had not sent more than one copy per mailbox. He might have since changed his definition and stopped sending unsolicited bulk mail, but it would be silly to think everyone who gets a PGP key signed at an IETF key signing party is someone from whom you want to receive mail. Given who will pay certifiers, the IETF key signings are far less bad guarantors of non-spam than commercial certifiers. Consider privacy policy certifiers and see one of the several versions of http://enterprise-security-today.newsfactor.com/story.xhtml?story_title=Online_Privacy_Policies_Misleading ] An analysis of Web sites carrying those seals found that the ] companies running them ask for more personal information -- and ] protect it less -- than sites that have no seals. Vernon Schryver[EMAIL PROTECTED]
Re: How Not To Filter Spam
> From: Ed Gerck <[EMAIL PROTECTED]> > Yes. However, if your mailbox could automatically handle confirmation > requests based on messages that were actually sent by you (in much > the same way that NAT boxes work -- you only get a reply to a request > you send), then you would not be bothered by the C-R traffic at all. As long as you are wishing for things with no prospect of reality in the foreseeable future, why not wish for long jail terms for the ROKSO 200? Automatic C-R handling in MUAs would solve the spam problem much as NAT boxes have solved the address shortage and routing table size problems, by creating other problems that are worse in the long run. For example, C-R handling in MUAs would do nothing for the problems C-R systems have with mail that is not simplistic messages between individuals. Someone recently wrote that challenge/response systems would be practical if there were a way for C-R systems to identify and not challenge mailing list traffic. That made me choke, because all spam is mailing list traffic. Perhaps what was intended was making C-R systems recognize solicited mailing list traffic. If your C-R system could do that, there would be no need for any challenging or responding. You would challenge neither non-bulk nor solicited bulk mail, and would simply reject all unsolicited bulk or spam mailing list traffic. > Messages among complete strangers is a necessary feature, IMO, but > shouldn't it behave in cyberspace as we learned to do it in the > social space? Trust is earned. When a complete stranger calls me, > I usually ask who or what introduced me to him before I start any > conversation. If the complete stranger has no satisfactory answer, > I ask him to take me off his database and not call again. If that's good enough for you, then you already have it. The start of a phone call from a stranger corresponds to the initial mail message. The asking to be added to a DNC list corresponds to adding an entry to your email blacklist. You probably want PKI magic that will tell your MTA or MUA whether substantially identical copies of an incoming message from a complete stranger will soon be sent to 30,000,000 of your intitmate friends. That magic would happen before you do the equivalent of answering a phone call from a stranger. If you are among those who configure their telephones to reject calls with caller-ID values not in whitelist, then you can configure your email system to do the same with IP addresses. That will eliminate essentially all spam. It also eliminates messages from strangers. > > People who know each other's crypto keys are not strangers. > > It is possible for my MUA to automatically provide a complete stranger > with my PK if I receive an email from him. The barrier to have my > crypto keys does not have to be any higher than the barrier to have > my email address. If a complete stranger is the sender of an incoming message, then crypto keys are irrelevant to determining the message is unsolicited bulk. If the sender of spam is not a stranger, then you made a mistake in handling keys. The PGP mantra that a good key does not imply that the sender or the message is good applies here. Vernon Schryver[EMAIL PROTECTED]
RE: How Not To Filter Spam
> From: "Robert G. Brown" <[EMAIL PROTECTED]> > ... > If a message comes in incorrectly addressed, yes, it will bounce. It > should, shouldn't it? This has nothing to do with whether or not it is > spam or a virus or any other kind of message. If it is a bad thing, it > is a very fundamental bad thing... > ... If the envelope sender was forged as is common in spam, universal in worms, and practically nonexistent in legitimate mail, then your bounce will afflict third party's mailbox. My mailbox receives enough worm bounces to make me say it is an awfully bad thing. The only fix is to have your external MX servers know all valid addresses and so reject junk before it can be accepted and later need to be bounced. That fix is often impractical or impolitic. No, SPF, RMX, TOES, etc. etc. etc. cannot fix this problem unless you assume frictions (deployment resistence and delays) do not exist or you discard SMTP design goals including transporting messages among complete strangers. People who know each other's crypto keys are not strangers. If you could someday trust organizations to vouch for strangers and not sell spam-for-a-day certs to Ralsky/Ricther/&co, then today you could trust the same outfits to not sell spam-for-a-day/week/years IP bandwidth accounts. Vernon Schryver[EMAIL PROTECTED]
RE: How Not To Filter Spam
> From: "Tony Hain" > To: "'Vernon Schryver'" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> > So if you had received the mail sent here yesterday claiming to be from > Alain Durand would you block Sun or IBM? ... I should not have responded specifically (if at all) to the other gentleman's complaint about my blacklists. Whatever I do to mail directed at stuff I control is irrelevant here, provided I do not affect any third parties. My freedom to filter access to port 25 (SMTP) and port 23 (telnet) is equally and completely unfettered. Two groups oppose that principle. Some people demand SPEWS and other filters with what they consider too many false positives be outlawed, because those filters might affect their outgoing mail. They are unmoved by users knowingly choosing their own filters. They feel their right to be heard by whomever they choose overrides the rights of their targets to be left alone. Other people see nothing wrong in spewing junk at third parties if it might reduce their own spam loads. These people include users of systems based on challenge/responses, bounces after the initial SMTP transaction (sometimes from within MUAs), "bitch lists" that send complaints to dozens of third parties. These people feel their right to consent to whatever appears in their mailbox overrides the similar right of others. As I see it, both groups suffer the same pathology as spammers. . ] From: "Robert G. Brown" <[EMAIL PROTECTED]> ] ... ] In the department, where we do USE spam assassin, no bounce messages are ] generated except when mail fails for one of the standard reasons ] unrelated to filtering of any sort. ... On today's Internet, innocents are almost certainly receiving bounced spam and viruses from your system that could not be delivered for reasons unrelated to filtering, such as bogus target addresses. ] ... ] If that rejection occurred during the original transaction and generated ] a bounce -- well, that's the kind of thing we see above, a cure that can ] easily be worse than the disease, ... The idiotic messages from that stupid challenge/response system are not generated during the original SMTP transaction. It is possible to do challenge/responses that do not involve separate messages, but they suffer from MUAs and MTAs that do not handle SMTP rejections properly and users who cannot understand them. Somehow making SMTP rejections understandable to users is something that the IETF might attempt. I think that is something the ASRG is considering. I also think that is nearly impossible. such is life. ] If I understand what you are saying, perhaps there is a way to "do it ] correctly" -- reject the spam at the original smtp transaction but with ] a message that goes back to the original sender (only) in spite of the ] fact that both the From and Return Path header entries might well be ] forged and the message relayed through one or more open relays. ... Headers and the SMTP envelope, forged or not, are irrelevant to SMTP 5yz and 4yz rejections, as far as the rejecting SMTP server is concerned. If the spam came through an open relay, then a proper SMTP rejection might cause the relay to send a bounce to an innocent mailbox, but SMTP relays are out of favor among spammers compared to open proxies. Vernon Schryver[EMAIL PROTECTED]
Re: How Not To Filter Spam
> From: "william(at)elan.net" > > It is also a classic example of what is wrong with the MUA filtering > > You certain dont assume that there is nothing wrong with the filtering > system you use and others may try duplicate as well. Otherwise how would > you explain that you have Elan and completewhois.com listed as filtered > on your site. Do you honestly believe we ever sent you any SPAM? Or maybe > you're making certain assumptions about envelope from or normal "From:" > headers and complaining when others are making the similar assumptions? Mail from Elan and completewhois.com is unwelcome at rhyolite.com in patt because of a message that said: ] Elan.Net Internet ] T.1 T.3 Frame Relay ] If you need more information about us or are interested in network services ] (managed hosting, collocation, dedicated servers, t1, t3), please send email to [EMAIL PROTECTED] ] ] For More info ] http://www.elan.net ] [EMAIL PROTECTED] There are additional, independent, sufficient reasons for that listing that we do not need to explore. If you will read my web pages, you'll see that my list of unwelcome domains is not only about senders of unsolicited bulk email. An advantage of a vanity or other tiny domain is that it can use blacklists that would have intolerable false positive rates at other or larger outfits but that have 0.000% local false positive rates. Vernon Schryver[EMAIL PROTECTED]
How Not To Filter Spam
Thn enclosed example of how not to filter spam is offered for those who might want to preemptively add accuspam.com or downloadfast.com to their blacklists. It is also a classic example of what is wrong with the MUA filtering tactics Robert Brown advocates. I certainly did not try to contact anyone at 3dize.com. A few readers of this mailing list might recall that Shelby H. Moore III and I don't see eye to eye. I do not know what the From: header of [EMAIL PROTECTED] is about. Perhaps it was forged. Or perhaps someone at that address wired a subscription to this mailing list through an unusually braindea) challenge/response spam filter at DownloadFAST.com. If so, the Secretariat should blacklist accuspam.com and/or downloadfast.com from subscriptions to IETF mailing lists. (It would need to be unusually braindead to send me the challenge instead of the envelope sender.) Vernon Schryver[EMAIL PROTECTED] > From [EMAIL PROTECTED] Tue Feb 17 19:26:14 2004 > Received: from www.DownloadFAST.com (www.downloadfast.com [65.61.155.11]) > by calcite.rhyolite.com (8.12.11/8.12.11) with ESMTP id i1I2QDiM048994 > for <[EMAIL PROTECTED]> env-from <[EMAIL PROTECTED]>; > Tue, 17 Feb 2004 19:26:13 -0700 (MST) > Received: from www.downloadfast.com (localhost.downloadfast.com [127.0.0.1]) > by www.DownloadFAST.com (8.12.10/8.12.10) with ESMTP id i1I1hIQf002492 > for <[EMAIL PROTECTED]>; Tue, 17 Feb 2004 19:43:18 -0600 (CST) > Received: (from [EMAIL PROTECTED]) > by www.downloadfast.com (8.12.10/8.12.6/Submit) id i1I1hITA002491; > Tue, 17 Feb 2004 19:43:18 -0600 (CST) > Date: Tue, 17 Feb 2004 19:43:18 -0600 (CST) > Message-Id: <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: Re: covert channel and noise -- was Re: proposal ... > From: [EMAIL PROTECTED] > Reply-To: [EMAIL PROTECTED] > You attempted to contact us via email, and our anti-spam system is returning your > email below. > > Please kindly resend your email below, using our Contact Form on our web page: > > http://accuspam.com?kM,vbrJT > > After using our Contact Form only once, your future emails will not be returned. > > If you do not use our Contact Form to re-send your email below, then we can not read > it. > > __ > Powered by http://AccuSpam.com. Signup instantly for FREE! > > > Your Returned Message: > From: "Robert G. Brown" > > > ... > > Or, mark for later accept/reject decisioning AFTER the SMTP server per > > se, in the filter pipeline between the server and the mail spool of the > > addressee. Spam assassin does the right thing already (and this is > > exactly what it does). > > ***NO***! Except when run as a milter or otherwise during the SMTP > ...
Re: covert channel and noise -- was Re: proposal ...
; messages that are not correctly classified when they are rejected. > Important messages can be lost. Bad things can result. Who is > responsible when this occurs? Who do I get to sue? You don't get too sue anyone, because a reasonably designed system lets you choose to do all of your spam filtering manually or in your personal MUA. The only caveat is that your account should be terminated for network abuse if whatever mechanisms you choose bounce very much spam to innocents. That many filtering systems are junk including not allowing per-user preferences is as illuminating as the fact that spam flogging spam filters is common. All I can see from either is that hard problems attract charletans and would be gurus. > ... > It is perfectly reasonable for you to add content filters that YOU > control ABOVE this transport layer. If you want to hire a secretary to > open all of your mail for you and sort it and reject all the > advertisements, you can. You are welcome to require manual filtering for your mail, but you have no standing to dictate to others at other institutions. "Transport layer" seems like a misuse of the term. It certainly conveys nothing to me. > With that all said, there are tools that ALREADY provide the kind of > content level filtering mentioned above. The better ones do not > themselves discard or bounce any mail to any user. People with experience in this field never say never. > They simply SCORE > THE CONTENT with regard to its likelihood of being spam (or a virus) on > the basis of a whole battery of tests. Scores that exceed a given > threshold can easily and automatically be rejected or binned for a > ... All of that can be done during the SMTP transaction just as effectively as after. Rejecting spam after the SMTP transaction should be and in many quarters already is seen as network abuse requiring at least a stern warning. Vernon Schryver[EMAIL PROTECTED]
Re: covert channel and noise -- was Re: proposal ...
> From: John Leslie > ... > > - local administrative choices that keep bastion SMTP servers ignorant > > of per-user filter preferences > >This is a feature, not a problem. If the end user wants a filtering > process individualized that much, s/he should choose to use a SMTP > server which agrees to do so. That is a feature only if the user accepts the consequences of discarding mail without generating bounces, including not informing senders of false positives. Bounces from internal spam filters (either in MUAs or MTAs inside organizations) are a major source of unsolicited bulk mail or spam. > > - filtering at the DATA command requires either (1) rejecting for > > all or no targets or (2) accepting for all targets and siliently > > discarding the message for those targets that want it filtered. > >Alternatively, the receiving SMTP server could reject any multiply- > addressed email. People running SMTP servers that handle 100K or more msgs/day have been uniformly horrified when I've suggested that. I don't really understand why, but I have given up on the idea. >(Silently discarding _is_ a bad idea, when done by the SMTP server > itself. IMHO, it's better to mark for later discard -- which actually > could be done in such a way as to mark only for those recipients who > requested the more restrictive filtering.) A better positition is that everything should be logged, particularly including discarded mail, and in that case, enough of bodies to allow targets to identify senders and the nature of the discarded messages. Of course, one should assume users won't normally look at those logs. Spam you read is not filtered, but at most categorized and stigmatized. Vernon Schryver[EMAIL PROTECTED]
Re: covert channel and noise -- was Re: proposal ...
> From: "Robert G. Brown" <[EMAIL PROTECTED]> > ... > I agree. However, all of the observations made so far regarding > spam/virus filtering in general still apply to filtering at the SMTP > level. I would say that NO keyword filtering could take place. The > best that one could do at the protocol level would be to reject messages > that fail to meet a tighter criterion than is currently required. What is "the SMTP level"? Is that during SMTP transactions between MTAs? Is "the protocol level" the same or something else? If both of those "levels" refer to SMTP transactions between MTAs, then the conclusion is wrong. Except for local administrative hassles, all spam and virus filtering that can be done later can instead be done during SMTP transactions between MTAs. Your SMTP server may need to wait to until the end of the DATA command to object to messages containing viruses, missing or bad SMTP headers or other objectionable content, but that works fine. I know of many millions of spam that are filtred during the DATA command every day, and I don't claim to know about any really big sites. The only problems are: - local administrative choices that keep bastion SMTP servers ignorant of per-user filter preferences - filtering at the DATA command requires either (1) rejecting for all or no targets or (2) accepting for all targets and siliently discarding the message for those targets that want it filtered. In theory the second problem could be fixed if the DATA command could accept a vector of 250-OK/4yz-try-later/5yz-fatal responses, one for each target named with a Rcpt_To command. In practice the spam problem will be solved one way or another long before such a protocol change would be sufficiently widely deployed to matter. Vernon Schryver[EMAIL PROTECTED]
Re: The IETF Mission
> From: grenville armitage <[EMAIL PROTECTED]> > ... > then that's a problem we can fix without creating an indestructable I-Ds. > ... IETF rules to the contrary, I-Ds are indestructable for anyone who cares to look for them. Every several months I'm moved to point to classic I-Ds that should have been destroyed as proof that almost anyone can submit an I-D that says almost anything, no matter how...ah...controversial. I have never failed to find copies somewhere on the net. Today the only aspect of an I-D that expires after 6 months is the endorsement implicit in a copy at venera.isi.edu or www.ietf.org. Today an endorsement of some sort is the only difference between having your ideas heard by self-publishing and having them officially published. The web is taking us a major step forward to 400 or 500 years ago when good ideas were self-published and readers didn't need the moderation of a Rupert Murdoch or the IETF. I don't know what the academic publish-or-perish, RIAA, and other commercial and mass media worlds will do to replace their citation indecies, royalties, and advertising revenues, and I don't much care. I'm not saying anything against WGs producing Informational RFCs. I'm only pointing out that calls to have the IETF Mission Statement "broaden the scope and quantity of documents to be published" suggest ignorance of search engines or needs to have things endorsed by the IETF. ] From: Fred Baker <[EMAIL PROTECTED]> ] I don't know that we're changing anything in what the IETF does. What is ] happening is that the IETF is growing up and taking control of its own ] destiny in a variety of ways, and trying to clean up its own processes. In ] all the *other* problems it tries to solve, the IETF tries to say what ] problem it is solving sometime before finishing solving it, if for no other ] reason so that it can decide whether it did in fact solve it. Same here. The facilitators hired by H-R departments to run mission statement "off-sites" always say all of that. They are always perfectly sincere and well meaning. Those good intentions do not change the fact that trying to write a mission statement changes the organization. If an organization lacks an unstated consensus purpose, then writing a mission statement is unlikely to create one. On the other hand, trying to write one exposes any lack of consensus and turns into a race to the Dilbert Standard of advocating all virtues, condemning all vices, and creating new mandates such as "ad hoc WGs" and "archived I-Ds." You could be right and I might be wrong if much this thread were not filled with talk about turning the IETF an unfunded Reed Elsevier. ] ... ] Once we have decided that we did in fact solve the problem before us, I ] don't know that the bumper sticker gets us all that much further. But the ] bumper sticker can be helpful when we are asking the questions "what are we ] trying to accomplish?" and "are we accomplishing it?". It's one thing to consider those questions and something else to write a "mission statement." Mission statement facilitators always say the only purpose is to consider those to questions, but the results are what they always are. Those results are related to the fact that they're officiously titled "Mission Statements" instead of "ad hoc comments about what we're trying to do and how well we're doing it." I know many of you must have been through Mission Statement charades. Have you ever seen one that with 12 months hindsight was not a waste of time or worse? My personal experience suggests that "write a mission statement" means the same as "jump the shark." See http://www.google.com/search?q=%22jump+the+shark%22 Vernon Schryver[EMAIL PROTECTED]
Re: The IETF Mission
> > Not all important ideas enter the working group process and emerge > > as standards, and the fact that some working group chooses not to > > "capture" an document does not make it necessarily unworthy of > > preservation. ... > Another approach here is to allow for the creation of ad-hoc WGs. That > would provide a cleaner path for tangential documents that don't fit > ... Let's see if I've got all of this straight: - The IETF is working on a Dilbert Standard compliant Mission Statement. The Dilbert Mission Statement Standard requires foursquare support of all virtues and opposition to all vices, without unnecessary (read "any") limitations. - There are many wonderful ideas that are so awesome that if they were self-published, their publishers cannot be slashdotted and would never be indexed by Google. To remedy this unfair lack of publishers and de facto censorship, the IETF will go into competition with the ACM, IEEE, etc. in both the refereed academic publish-or-perish business (e.g. CACM or *Transactions) and the random research notes business (SIGCOMM). - Salescritters, marketoons, and trade rag espurts find it inconvenient to utilize the IETF imprimatur by submitting I-Ds (possibly pushed to Informational) and then advertising compliance. To fix this terrible shortcoming of the IETF Standards Process that hinders innovatation by Microsoft and other leading edge organizations, the new IETF Mission Statement will require that anyone who wants a WG can have one. I think those are excellent proposals, although perhaps not for the same reasons as other adovcates. I've been complaining about nonsense I-Ds and write-only RFCs for many years. The most effective way to relive the pressure for junk RFCs and nonsense IDs is to make IETF's stamp of approval meaningless by giving it to anything and everything that comes along. Within a matter of at most a year or two, RFCs might go back to what they were 20 years ago. To solve any funding problems or overwork of the IESG, http://www.ietf.org/html.charters/wg-dir.html will become an automated index of links much like http://reshmeat.net/ and we'll do away with Last Calls. Let's hurry up and advance or at least archive these IDs before they expire: draft-terrell-internet-protocol-t1-t2-ad-sp-06.pdf draft-terrell-iptx-dhcp-req-iptx-ip-add-spec-00.pdf draft-terrell-iptx-dns-req-iptx-ip-add-spec-03.pdf draft-terrell-iptx-spec-def-cidr-ach-net-descrip-01.pdf Vernon Schryver[EMAIL PROTECTED]
RE: Death of the Internet - details at 11
> From: John C Klensin <[EMAIL PROTECTED]> > ... > (1) As others have pointed out, the knowledge/skill level of a > typical ISP seems to be on a rapid downslope with no end in > sight. ... > ... > * The difference between those "business rates" and > whatever you are paying are mostly determined by a "what > they can get away with" mentality -- we know what the > marginal operational costs are. If those prices stay > high, it is either because there is no alternate > provider, or because there is (illegal) price-fixing > going on, or because no one sees a business opportunity > by operating a business service at a lower margin. The second segment seems to ignore the implications of the first segment. The marginal cost difference between "business" and "residental" is zilch only if you have the same people running things and interacting with customers. Front line tech-support droids that are dumber than the Windows boxes of residential customer cost a lot less than humans. If your front line support people know have a clue about the LSRR IP option, then either your rates are higher than $30/month or you have customers like us who do most of our own support (and cost our employers or ourselves a lot more than $30/month for that support). > Many > of us can remember when the solution to "no viable > Internet dialup service" was "go form a consortium with > a few friends"... There are some surviving ISPs that were started and still run that way least in geographical areas I know about. Their prices seem to be higher than the organizations in that race to maximum stupidity. It is not a coincidence that they have very few internal spam problems. They are never blacklisted, not even by the second tier spam blacklists, even when they rent straight modem dial-up ports. (Third tier DNS blacklists are kooky 32-bit random number generators.) > perhaps it is time to do something > similar with DSL. I know people who have done that sort of thing with DSL and 802.11. However, I fear that idea is generally killed for now by the fact that IP bandwidth pricing is set by those outfits racing for ultimate stupidity. They see IP bandwidth as a loss-leader. > Or maybe we would rather whine than > do something, perhaps because what we have been fed is "good > enough". Until people like the individual complaining here that his cable-modem is listed as a dynamic address are willing to pay for the costs of real IP service, including the costs of doing more against your spamming customers than asking blacklists to list your own addresses, there's not much hope. We could accept the fact that people who are not willing pay more than $10-30/month are not interested in the Internet and stop listen to their whining. Detroit laughs as people who expect to get Mercedes for Chevrolet prices. Why can't we laugh at people who expect to get real IP service for $10-30/month, or least stop taking their demands literally? If cable-modem IP is good enough for you, then you're not interested in multihoming or even running your own VoIP system. You might be happy to have your phones connected to the email and web browser demark/appliance maintained by your telco/cableco, but you're not really interested in the Internet. You lack the interest to be allowed to run your own servers for anything. Vernon Schryver[EMAIL PROTECTED]
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
> From: Nathaniel Borenstein <[EMAIL PROTECTED]> > > You might be ignorant instead of dishonest. > > How very kind of you to consider two possibilities, thank you. My original words that you felt labelled you dishonest explicitly included that possibility. Most people have strong opinions about spam, but have not really looked at it, and are quite wrong about it. > ... > (And, by the way, I consider *any* false positives unacceptable if > there's no suitable mechanism for detecting and correcting them.) That wisdom applies to a lot more than spam defenses. However, it is worth noting that many and perhaps most email users value avoiding false negatives more than avoiding false positives in their spam defenses. That is one reason why the blunt, high false positive blacklists are popular. One also must not try to reduce false positives from spam filters much below the error rate of SMTP in the real world (e.g. not just bounces but blackholes). > This discussion is going nowhere, so I'm going back to more serious > work on comprehensive spam control. That's fine, but it would be wise to recognize the overall situation while developing those comprehensive controls. Railing against the evil conspiracy of big monopolistic ISPs using blacklists against themselves isn't productive. Except for organizations that run their own private blacklists, public anti-spam blacklists will remain quite popular. MAPS used to claim 45% of the Internet used the RBL. I suspect that at least that much uses the RBL+, CRL, XBL, SBL, and/or SPEWS. Public blacklists are here to stay, because they work. The only likely tactic for reducing the use of blunt blacklists such as those listing dynamic IP addresses is to convince ISPs to take network abuse seriously. As long as big ISPs make listing their own IP adddresses "dynamic" lists their main response to their own bad customers, those blunt, high false positive blacklists will remain popular. Talk about transition plans to IPv6, comprehensive spam controls, the evils of NAT, the evils of blacklists, media conglomerate ISPs distributing NAT boxes to break VoIP, and monopolisitic ISPs using blacklists is one thing. Actually doing something is something else. Vernon Schryver[EMAIL PROTECTED]
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
> From: Nathaniel Borenstein <[EMAIL PROTECTED]> > ... > > Mr. Sauve could rent an IP address that is not on dial-up or dynamic > > blacklists and run his systems there. > > In other words, because some ISP with whom he has NO relationship has > deemed his own ISP spam-friendly, he should abandon his ISP, whether > *he* thinks they are spam-friendly or not. The words that come to mind > to describe this sort of arrangement are "cartel," "blackmail," and > "extortion." It is also a perfect example of an assertion I made > before, which is that blacklists are being used by the large ISP's as a > tool for consolidation in the ISP market. When RoadRunner blocked my > ISP, the *only* thing they were helpful about was offering to help me > get "better" Internet service by changing ISPs. Exactly the same charges can be made about taxis, pizza delivery services, and so forth that refuse to deliver to "bad" parts of the real world. Perhaps in some cases you are right, but in the vast majority you are wrong. Is a simple, undeniable fact that the sources of spam are concentrated in a small fraction of the IPv4 address space. For example, the last numbers I saw about SPEWS had it listing a tiny fraction of 1% of the IPv4 address space. There are other problems with your theory. The biggest is the link between the big ISPs and the blacklisters. Besides the undeniable spammers (e.g. the ROKSO members), it is the big ISPs that are most likely to be blacklisted, particularly in "dialup" or "dynamic" blacklists. According to your theory, Charter Communications is part of a conspiracy of big outfits to drive away their own customers by blacklisting their own IP addresses. How sane and honest is that? If you are saying that blacklists and boycotts are dangerous weapons, then you're certainly right. That's why contrary to my naive reading of the U.S. Constitution, there are federal laws that limit or outlaw boycotts in some circumstances that I don't understand. See http://www.google.com/search?q=%22secondary+boycott%22 Exactly what do you want? - a U.S. Federal law against IP address blacklists? - a test for social responsibility and good sense given prospective IP address blacklist opererators administrated by the IESG? - a U.N. regulation prohibiting stupidity and foolishness by users and ISPs while choosing blacklists? Pardon me, but it seems you want the IETF to declare that all blacklisting and spam rejecting by IP address wrong and nasty. As far as I can tell, you would require me to accept mail from 69.6.0.0/18 because you fear I might refuse mail from you. Or perhaps you would allow me to reject Wholesalebandwidth spam provided I not tell anyone. > >> Blacklists also, quite clearly, don't work to eliminate spam. > > > > No honest person who actually looks at spam agrees with that. > > As I've made clear, *I* agree with that. Given the exchanges that > preceded this, it sounds like you are asserting that I -- and all the > other people who have argued against you in good faith on this list -- > are dishonest. Is everyone who disagrees with your conclusions > necessarily dishonest? If so, why are you wasting time talking with > us? You might be ignorant instead of dishonest. If you have not looked any blacklists except those that have affected your mail, then you have not, in my words, really looked at spam. Are you calling me and those who point out that some blacklists detect 70-90% of spam with false positive rates below 1% liers? It your words could be read that way. Vernon Schryver[EMAIL PROTECTED]
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
> From: [EMAIL PROTECTED] (Mike S) > ... > >Instead of paying the extra cost to hire an ISP that cares > >enough to not have spamming customers, people complain about the evils > >of blacklists. > ... > I can't do so because my IP address is on a blacklist. I have > cable modem, but the world thinks I'm a dial-up. For that reason > alone, having nothing whatsoever to do with spam, I'm forced to > give up privacy and control of my communications. Mr. Sauve could rent an IP address that is not on dial-up or dynamic blacklists and run his systems there. A remote co-lo or hosting service would cost more than the $30/month or whatever slum rate he is paying for cable modem service. Or he could convince his correspondents to whitelist his IP address or stop using the relevant blacklists. Either he has not tried that, his correspondents also pay slum rates for slum service, or they don't want enough to hear from him to increase their spam loads. Perhaps I should ask if Mr. Sauve is violating the terms of service of his ISP. What does Charter say about "servers"? Did Charter give Mr. Sauve's IP address to the blacklists that bother him? Or perhaps he has already rented an IP address that is not dynamic. But if he has done that, where is his complaint? Is it just Interveloce/GO International's rates? > "Anti-spam" initiatives that are based on such blacklists are > quite simply the failed results of irrational, fascist thought. In that he is calling his correspondents irrational fascists, because it is they who have chosen to reject his mail. Never mind that facism has something to do with "centralized autocratic government headed by a dictatorial leader, severe economic and social regimentation, and forcible suppression of opposition" and that seems like the opposite of the anarchy of blacklists. Also ignore the fact that a taxi or pizza delivery service refusing to go to dangerous parts of town is no more irrational than refusing mail from the IP address neighborhoods that are major sources of spam. Any individual is unlikely to be a spammer or mugger, but the statistical risk/reward ratio is too high. By all accounts, the odds that the the next SYN to your port 25 from a "dynamic" IP address involve spam are very high. > Regardless of your exact definition of spam, all reasonable ones > I've heard have one thing in common - it's based on CONTENT, not > IP address. Blacklists couldn't care less about content That's nonsense. Blacklists do care about content in a statistical sense. If blacklists don't care about content, then neither do so called Bayseian filters. I've often said that lists like the DUL bug me, but not because they are useless. Lists like the DUL catch a lot of spam and little legitimate mail. > - legitimate > email or spam, out it goes, to the detriment of communications, > which is the Internet's raison d'etre. I take that back, it used > to be that way. Now the Internet is meant to make big corporations > lots of money. I've been around for a few years (TIP-25 (DOCB) in 1972), but I don't recall that Communication in the sense Mr. Sauve means was ever the Internet's raison d'etre. 15 years ago, would be communalists were bemoaning the commercialization of the net and interference with capital-C-Communication, by which they meant they deserved free bandwidth. Their successors complain about the free ride they never got. Back in Mr. Sauve's golden era, his perfect unfiltered IP bandwdith was either not available to small or commercial outfits like Alientech LLC or it would have cost 2000% more (>$5000/year) for 10% as many bits/sec (56K). > Blacklists also, quite clearly, don't work to eliminate spam. No honest person who actually looks at spam agrees with that. Good blacklists (e.g. CRL) are better than 70% effective with false negative rates that large, very conservative corportations can tolerate. Vernon Schryver[EMAIL PROTECTED]
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
> From: Bill Sommerfeld <[EMAIL PROTECTED]> > ... > One problem with dropping suspected spam into a spam cesspool as > opposed to rejecting it outright in the SMTP session is that many > people (myself included) have neither the time nor the inclination to > wade through our spam cesspools on a regular basis looking for > misclassified messages. That's too true. Since the spam collected/rejected by my real mailbox and personal spam traps exceeded 1000 spam/day, I can only skim envelopes. If I count duplicates, my average for the last 40 days is 3516/day. > An SMTP-level reject at least gives the sender a real-time indication > that the recipient will not be seeing the message any time soon.. There may be a false dichotomy there. You can reject a message during the SMTP transaction and so give the sender a real-time indication while also capturing the entire message in a spam cesspool. All 787 MBytes now in my 40-day rolling cesspoll were rejected with a 5yz or 4yz SMTP response. That many systems don't capture what they reject implies nothing about anything except those SMTP servers. I'm flummoxed by criticism of external DNS blacklists based on the lack logging by SMTP servers. That's predictable among the general public, but not here. This thread is related to the nearby thread about the end of life announcement for SpeakFreely. The problem in both cases is less with evil media conglomerates converting the Internet into TV than with people who won't feed themselves. Instead of getting their code and networks running IPv6, they install NAT boxes and complain about the RIAA. Contrary to the whines from ISPs with major spam problem, those that have real (including enforced) anti-spam policies don't have spamming customers. Instead of paying the extra cost to hire an ISP that cares enough to not have spamming customers, people complain about the evils of blacklists. Instead of taking the extra trouble to use an operating system or at least an MTA that is not a worm delivery and spam facilitation system, they send mail to random, spam-obsessed strangers like me asking how to add spam filtering to Outlook. Vernon Schryver[EMAIL PROTECTED]
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
> From: Nathaniel Borenstein <[EMAIL PROTECTED]> > ... > I also have to say that I fear your approach would help the larger ISPs > use spam as an excuse to kill off smaller ISP's... How so? Exactly what is my approach? Please note what I've said too many times: - I don't currently use a public blacklist and have never used one for non-trivial mail. - I'm flogging spam defenses that compete with blacklists. > and I question the > fundamental legitimacy of blocking all of an ISP's customers before > there's a fair due process to establish the ISP's culpability. "Fair due process" and "free speech" and even "legitimacy" are none of your concern unless you own the mailbox that would *RECEIVE* the blocked mail. No one has any right to send anyone any mail. We have only privileges granted by targets of our mail. If our targets are foolish and hire ISPs with long histories of both permitting a lot of outgoing spam and blocking a lot of incoming legitimate mail (see recent complaints about RR's false positives), then that's just tough and perhaps we should convince our correspondents to switch ISPs or find new correspondents. Good or bad spam filtering is merely a part of the rest of good or bad SMTP or any other ISP service. It makes no more sense to condemn the HTTP protocol because many web pages are junk than it does to condemn blacklists because some blacklists are junk or used badly. If you think blacklists are bad because they can be run by fools, then you also must hate any network authentication and authorization mechanism. What's the difference between Kerberos and a mail blacklist? Both are responsible for summary denial of services. I fear there are bad reasons for the disdain for blacklists: - they are effective against spam from spam friendly ISPs. - some of us work for spam friendly ISPs and let the interests of our employers color our thinking. - some of us are lazy and hire ISPs have been spam friendly. - some of us feel we have a devine right to send any mail to anyone and are deeply offended by any contrary suggestion, not to mention an effective mechanism. > "Caring > enough about spam" is an awfully slippery concept on which to base a > blacklist. I am offended by your implication that I suggested any such thing. I only pointed out that using spam-friendly ISPs has consequences. (You evidently know about XO's reputation, which I think has improved lately.) The only major blacklist that does anything remotely like your implication is SPEWS, which "escalates" in order to get the attention of ISPs. If I did use a blacklist, it wouldn't be SPEWS but that would be only one reason among serveral. > ... > > that is not blacklist, then why can't a blacklist be run properly? > > Good point. That's why I favor giving users access to their spam pool > when they suspect problems, and using challenge/response in certain > (carefully defined) situations. A good filtering mechanism is not > nearly as black and white as a blacklist. The last part of that is simply wrong. Every filtering mechanism is exactly as black and white as a blacklist. Whether or not an SMTP server keeps good logs has nothing to do with whether it decides to reject messages using blacklists of IP addresses or domain names or anything else. If your correspondents use software that consults any blacklist but doesn't keep good logs, then the fault lies first with your correspondents for using bad software, second with you for having foolish correspondents, and not at all with the blacklist. Yes, I realize that I'm implying that to keep good logs you need to act on a blacklist (if you use one) at the end of the DATA command instead of before the HELO. > > Any fool > > can set up a blacklist. That many fools have and other fools have > > used them does not show that blacklists are bad any more than the ease > > of setting up an IP network shows TCP is the spawn of the devil. > > I will confess that my personal experience makes it very hard for me to > be rational on the subject of blacklists, as I fear that any concession > to them will only encourage the creation of destructive blacklists by > "fools". In general I prefer a solution that any fool can implement, > because one surely will. Then you'd better give up on the Internet. As with much of the net, the information in and functioning of any spam system is at least somewhat "administrative" and subject to the whims of any fools administrating it. The buyer must beware, not only of hiring a spam friendly ISP, but contracting with a foolish spam filter. The greater fool is often the buyer of services offered by lesser fools. Vernon Schryver[EMAIL PROTECTED]
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
> From: Nathaniel Borenstein <[EMAIL PROTECTED]> > FWIW, I believe Keith is probably right. Blacklisting has been a major > impediment to my own email usage. I don't know about any *particular* > blacklisting service because when your ISP gets blacklisted by mistake > and you're simply collateral damage, it's very hard for you to get an > explanation of what's going on, because your email has been blocked -- > this has happened to me several times. Several times? As far as I know, most people I know have never been collateral or other kinds of blacklist damage. Do you use what might be called marginal ISPs? Some large outfits such as UUNet have long refused to care enough about spam. (See the current Spamhaus listings for UUNet at http://www.spamhaus.org/sbl/listings.lasso?isp=uu.net and particularly the orange boxes.) > My own theory is that > blacklists are fundamentally flawed because they are inevitably NOT > accompanied by sufficient administrative staff to deal with the > inevitable mistakes and exceptions in the blacklist. Moreover they > aren't necessary, given the number of other ways to block spam. -- > Nathaniel I have interests in other ways to block spam, but I don't like that reasoning. Many bad implementations don't prove the idea is hopeless. The design and implementation flaws in practically all installations of desktop software do not show that desk top computers are bad ideas. All of us, including those who have never used a Microsoft product, have been collateral damage of Microsoft's design philosophies, implementation processes, and business plans, but that implies nothing about personal computers in general or software from the Seattle area. Before mail-abuse.org existed and I think before the RBL was called the "RBL," it was pointed out to me. I said that I couldn't imagine a Fortune 500 company having an outsider decide which IP addresses could send mail. No matter how forcefully I would have said "Paul's a good guy," if I'd been one of my bosses, I would have been unmoved. But maybe that's just me. All other (usable) ways to block spam are being purchased as out-sourced services. If you can trust outsiders to have "sufficient administrative staff to deal with the inevitable mistakes and exceptions" in a spam blocking mechanism that is not blacklist, then why can't a blacklist be run properly? The only thing that distinguishes blacklists from other third party spam filters is that setting up a DNS blacklist is easiest. Any fool can set up a blacklist. That many fools have and other fools have used them does not show that blacklists are bad any more than the ease of setting up an IP network shows TCP is the spawn of the devil. Vernon Schryver[EMAIL PROTECTED]
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
> Cc: Keith Moore <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > From: Keith Moore <[EMAIL PROTECTED]> > To: Vernon Schryver <[EMAIL PROTECTED]> > >>> If that is an issue, it ought to be raised by those who are being > >>> misled, the targets of mail, instead of senders and other third > >>> parties. > >> > >> it IS being raised by them, for those who are actually able to figure > >> out what's going on. of course, when the recipient doesn't receive > >> the > >> mail he's expecting, he has no idea where to look - so he tends to > >> blame the sender. > > > > Keith Moore is not complaining about mail he has not received because > > of the dasterdly misinformation from the RBL. He is either a third > > party sender of reject mail that he is certain was wanted by its > > targets > > despite being rejected or he is a fourth party presuming to speak for > > the first parties (spam targets) against the second parties (blacklist > > providers). > > You are a barefaced liar. How so in that assertion of mine? Unless I missed something that seems unlikely, Keith Moore is not complaining about mail he has failed to receive. He surely would not have been misled by blacklist operators into configuring his SMTP servers to use one of their evil nasty cheating lying dishonest fraudulent unhealthy fattening cancer-causing end-to-end principle breaking RBLs. The remaining possibilities are that he writing is on behalf of himself as a sender of rejected mail or he is a fourth party presuming to speak for the people actually involved, senders, receivers, and blacklist operators. I admit that I would not be surprised if his opinion of anti-spam blacklists was informed long ago when some of his more or less innocent mail was rejected with a reference to MAPS's RBL. I've no evidence of that except his use of archaic jargon and what his "courtesy copies" and statements about how I've configured my SMTP server show of his views of those who would be happier with fewer of his words. Concerning how I've configured my SMTP server--Juging from the headers of the IETF list messages, today it has rejected 2 copies of "and the horse you rode in on" and one copy of "You are a barefaced liar." That seems like a Good Thing(tm), but perhaps not enough. Vernon Schryver[EMAIL PROTECTED]
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
> Cc: Keith Moore <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > From: Keith Moore <[EMAIL PROTECTED]> > To: Vernon Schryver <[EMAIL PROTECTED]> > ... > > If that is an issue, it ought to be raised by those who are being > > misled, the targets of mail, instead of senders and other third > > parties. > > it IS being raised by them, for those who are actually able to figure > out what's going on. of course, when the recipient doesn't receive the > mail he's expecting, he has no idea where to look - so he tends to > blame the sender. Keith Moore is not complaining about mail he has not received because of the dasterdly misinformation from the RBL. He is either a third party sender of reject mail that he is certain was wanted by its targets despite being rejected or he is a fourth party presuming to speak for the first parties (spam targets) against the second parties (blacklist providers). An odd thing about users of DNS blacklists and other filters is that many users avoid confronting senders of rejected mail. Many users are happy to let senders assume what the senders want to believe, that the evil nasty rbl consipracy used lies, bribery, and extortion to force an ISPs to use a blacklist. Never mind that after being informed of that evil nexus by senders, most users do nothing but demand even more filtering. Ignore the fact that blacklists are free or cost money and are now generally selling points. Of course popularity in the market is not proof of virtue, but it does poke holes in the claims of senders of rejected mail about blacklists. > ... > whatever. your mail server claims it's forwarding my mail to DCC, and > it's not bulk mail. The first phrase is true but only of mail sent directly from Keith Moore to my SMTP server. His second statement is false. Bulk mail includes any message which has a "a bunch" of copies sent to one or more mailboxes. All mail sent through non-trivial mailing list reflectors is bulk. Spam is bulk mail that is unsolicited. "A bunch" varies depending on whom you ask and when. Keith Moore has long known that his "courtesy copies" to my mailbox are unsolicited and unwelcome. They are identical except in headers to hundreds of copies of the same messages, and so are "bulk." I tolerate (and sometimes find interesting) the copies of his messages that arrive through the IETF reflector, but I object to duplicate copies of flames and insults. If your "a bunch" threshold for "bulk" is 2, then Keith Moore's attempts to put 2 copies of his messages in my mailbox are "spam" regardless of the hundreds of copies sent elsewhere. (Some people say 2 is the right threshold for "bulk", but I run my DCC client with a threshold of 5. 5 is a common choice for vanity domains. Choices for real domains range from 20 to 200 as well as the overflow value of "many.") > > Consider "courtesy" copies of mailing list messages and the people who > > send them. Many courtesy copies are sent unthinkingly by using a > > "reply all" function, but others are intentional. The intentional > > copies amount to "microphone queue jumping." > > "and the horse you rode in on." > > you are misleading people, and you know it. Notice that he does not specify whom is being misled or the falsehood. Sheesh!--what would a reasonable person do who knows that one of his targets doesn't want his "courtesy" copies? Vernon Schryver[EMAIL PROTECTED]
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
> From: Keith Moore <[EMAIL PROTECTED]> > ... > > In any case, what standing do you have to comment on what mail is > > rejected by other peoples SMTP servers? > > Sites can reject mail to their own servers if they want to. the issue > is whether they're being misled about the criteria used by a blacklist. If that is an issue, it ought to be raised by those who are being misled, the targets of mail, instead of senders and other third parties. > > I think that as long as > > those using blacklists get what they ask for, no outsiders have any > > business commenting, and particularly not would be senders of > > unsolicited bulk mail. > > Apparently you also think that it's acceptable to forward mail from > people you don't like to DCC, misrepresenting it as spam. The only > reasonable response to people with this kind of attitude ends with "and > the horse you rode in on". Actually, that's being far too polite. First, contrary to Keith Moore's the baloney, DCC clients detect bulk mail. It is impossible to (mis)represent mail as unsolicited bulk mail or spam by forwarding it to a DCC server. Doing so only reports it as "bulk." Are the "courtesy" copies mailing list contributions that Keith Moore insists on sending "bulk"? If they are private, then forwarding them to the DCC instead of my mailbox can have no effect because no one else will see them. If they are bulk, then some extra reporting also has no effect; if DCC clients haven't marked them solicited bulk by whitelisting the IETF list, they should be rejected as unsolicited bulk mail. That's how the DCC works. So why is Keith Moore so exercised? Consider "courtesy" copies of mailing list messages and the people who send them. Many courtesy copies are sent unthinkingly by using a "reply all" function, but others are intentional. The intentional copies amount to "microphone queue jumping." Their senders they feel their targets should see and respond to their words first. When the IETF reflector took literally days to finish sending copies to people at the end of alphabet like me, there might have been other reasons, but today it finishes within several dozen minutes. I didn't realize that "courtesy" copies are often intentional queue jumping until I noticed that senders of "courtesy copies" tend to foam at the mouth about the evils of MAPS, the RBL, blacklists, and spam filtering in general. I did not notice that common thread until I tired of "courtesy" copies of foaming flaming nonsense and started dropping senders into my personal, non-published blacklist. If you want to see apoplectic fits, use a sendmail access_DB instead of procmail to for your filtering. That will spare your system a few cycles, but it also lets senders know they're not being heard. People who hate the RBL and DUL for impersonally filtering their earthshaking words really hate being being personally shunned. Vernon Schryver[EMAIL PROTECTED]
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
> From: [EMAIL PROTECTED] (Mike S) > ... > The RBL and DUL are quite clearly (and openly) designed and > intended to be used to implement denial of service. Doing so with > the explicit authorization of the email recipient would be legal. > ... > The MAPS system does not, and cannot, distinguish between spam > email and legitimate, addressee desired email. It is a brute force > system which throws the baby out with the bathwater. Who but someone incapable of understanding the concept of one person never wanting to receive any mail or other communications from another could say something like that? For the rest of us, it makes perfect sense to say "I never want to receive any mail from any IP address owned by Stanford Wallace. I also never want to receive mail from any SMTP client using an IP address that has been declared 'dynamic' by its owner, because that declaration says that its owner cannot figure out who is using the address at any given time." I suspect that Mike Sauve (msauve at alientech.net) is upset with the RBL and DUL because some of his mail was rejected. I cannot find any evidence that he has sent unsolicited bulk commecial email, although some of his public statements about the definition of "spam" have been a little unusual. Perhaps he tried to run a commercial site on "residential" IP addresses and blames MAPS instead of the ISP that labelled those addresses. Note: - The DUL was largely populated with declarations by the owners of the IP addresses in question. - The IP address owners are ISPs, not the end users renting them, at least if they're not SWIPed. - I've always considered "dynamic" declarations by ISPs as implying that the ISP is a slumlord uninterested in tracking abuse by its users. Contrary to years of knowingly false statements from such as UUNET, anyone with standing to contribute to this list knows that figuring out which modem, DSL port, or cable modem port was using a block of "dynamic" IP addresses at any given instant requires only the will to maintain and consult RADIUS or other logs. Vernon Schryver[EMAIL PROTECTED]
