Re: VIRUSES ARE PROFITABLE???
> ... why don't you isolate > your important information from the internet, including back ups for your > web servers and open attachments on offline isolated computers also remember > to do your browsing on seperate computers. That may reduce disaster > vunerability by about 5%. If you are so rich that you can afford one seperate computer for each little task to accomplish, please send me some money. It seems that you have plenty. - Anders Feder
RE: VIRUS WARNING
PLEASE change the title of this thread. It's borders on a partial self denial of service, since the title is now misleading. Thank you. Bill Flanigan -Original Message- From: Henry Clark [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 14, 2000 4:35 PM To: Jeremy Cc: [EMAIL PROTECTED] Subject: Re: VIRUS WARNING At 01:38 PM 5/12/00 -0400, Jeremy wrote: >Can you plase pleaes stop this Virus Thread. This thread _is_ the virus...
Re: Any comparison Study on MGCP vs H.323, MGCP vs SIP
Sez "Masataka Ohta" <[EMAIL PROTECTED]> > > H.323 is defined for a LAN environment, not for telephone lines. > > For telephony people, the IP protocol is for a LAN environment > that there is no difference between H.323, SIP, TELNET, or DNS > for that matter. "Telephony people" are not relevant here, since we're talking about VoIP. > As I said: > > > >For VoIP over telephony networks Your statements don't make sense; "VoIP over telephony networks" is an oxymoron, since VoIP is, by definition, over an IP network. > some protocol is necessary between two telephony networks. > > FYI, there is a protocol called TBGP proposed in IETF for the purpose. TBGP is the proposed method for binding E.164 numbers to telephony domains, much like DNS binds names to IP addresses. One would still use SIP (or equivalent) to actually complete the call. > > If you want to use ITU protocols, please choose some other numbers. > > So, you are saying SGCP/MGCP are wrong to use 323. > > Fine. No, he's suggesting that if you wish to use an ITU protocol, H.323 is not the correct one. Perhaps Q.931? > FYI, in my design of "The Simple Internet Phone": > > If you are interested in Internet telephony, see you at > INET'2000 in Yokohama for the presentation of our paper > "The Simple Internet Phone". Please let us know the URL where you'll be publishing this paper, as some of us may not be inclined to fly to Yokohama to hear about yet another non-standard, proprietary telephony protocol. > I chose to keep using 164 (sorry, not 42) at least for the time being, > because it is the easiest way to let subscribers replace telephony > network with the Internet. MGCP/SGCP/Megaco directly use E.164 numbers. SIP allows users to see only E.164 numbers during a transition period, though it becomes much more pwoerful when you move to a more expressive namespace. [from a prior message] > As I pointed it out with regard to iMODE and WAP, an attempt to > promote protocols like SIP, a NAT friendly protocol even more > complex than H.323 SIP may or may not be NAT-friendly, a point which is best left to other (time-wasting) threads. I would love to see any explanation of how SIP is more complex than H.323; maybe you have them backwards? > was based on a wrong strategy destroying > the Internet into a collection of mostly-non-IP networks connected > by application/transport gateways with mostly-non-IETF > application/transport protocols. SIP is not, as you state, based on a strategy of building non-IP networks and connecting them with non-IETF protocols; in fact, it's quite the opposite. SIP allows the replacement of non-IP (ie. legacy telephony) networks and non-IETF (ie. ITU) protocols; in the ideal SIP world, legacy telephony would cease to exist. While a bit dated, Henning Schulzrinne and Jonathan Rosenberg's paper has quite a bit of detail on the subject: http://www.cs.columbia.edu/~hgs/papers/Schu9807_Comparison.ps.gz > Masataka Ohta S | | Stephen Sprunk, K5SSS, CCIE #3723 :|::|:Network Consulting Engineer, NSA :|||: :|||: 14875 Landmark Blvd #400; Dallas, TX .:|||:..:|||:.Email: [EMAIL PROTECTED]
Re: Any comparison Study on MGCP vs H.323, MGCP vs SIP
Stephen Sprunk; I dare reply because your mail demonstrates common misunderstandings by people outside of the Internet. > > > H.323 is defined for a LAN environment, not for telephone lines. > > > > For telephony people, the IP protocol is for a LAN environment > > that there is no difference between H.323, SIP, TELNET, or DNS > > for that matter. > > "Telephony people" are not relevant here, since we're talking about > VoIP. Huh? > > As I said: > > > > > >For VoIP over telephony networks > > Your statements don't make sense; "VoIP over telephony networks" is an > oxymoron, since VoIP is, by definition, over an IP network. Some IP networks are pure telephony networks. Only one IP network in the world is the Internet. > > > If you want to use ITU protocols, please choose some other numbers. > > > > So, you are saying SGCP/MGCP are wrong to use 323. > > > > Fine. > > No, he's suggesting that if you wish to use an ITU protocol, H.323 is > not the correct one. Perhaps Q.931? He is not saying anything meaningful. > MGCP/SGCP/Megaco directly use E.164 numbers. SIP allows users to see The context is that Yixin said something about S/MGCP and 323 and Chrisitian acknowledged. I know the relevance is meaningless. > > FYI, in my design of "The Simple Internet Phone": > > > > If you are interested in Internet telephony, see you at > > INET'2000 in Yokohama for the presentation of our paper > > "The Simple Internet Phone". > > Please let us know the URL where you'll be publishing this paper, as > some of us may not be inclined to fly to Yokohama to hear about yet > another non-standard, proprietary telephony protocol. You seem to have no knowledge on INET and IETF. Signature of Vint will be a good starter for you. Or, ask someone who knows something about not only IP networks but also the Internet. > SIP is not, as you state, based on a strategy of building non-IP > networks and connecting them with non-IETF protocols; in fact, it's > quite the opposite. SIP allows the replacement of non-IP (ie. legacy > telephony) networks and non-IETF (ie. ITU) protocols; in the ideal SIP > world, legacy telephony would cease to exist. We, IETF, are for the Internet, not merely IP. Masataka Ohta
Re: Any comparison Study on MGCP vs H.323, MGCP vs SIP
Hi, > > As I said: > > > > > >For VoIP over telephony networks > > Your statements don't make sense; "VoIP over telephony networks" is an > oxymoron, since VoIP is, by definition, over an IP network. > > > some protocol is necessary between two telephony networks. > > > > FYI, there is a protocol called TBGP proposed in IETF for the purpose. Just a minor correction. The new name for this protocol is TRIP. Thanx, Dhaval > > TBGP is the proposed method for binding E.164 numbers to telephony > domains, much like DNS binds names to IP addresses. One would still use > SIP (or equivalent) to actually complete the call.
HTML email
Vernon Schryver wrote: > The practice of sending both HTML and cleartext of supposedly the same > message reflects very poorly on those who do it intentionally and on those > who cause MUA's to trick others into doing it unintentionally. Never mind > the security issues, but consider only the wastes of disk space, CPU > processing, network bandwidth, and the inevitable differences between the > two versions. If the two messages were the same, then there would be no > excuse for sending both. If they differ, then one must be wrong, and > sending both is worse than a waste. So why does multipart/alternative exist? -- /==\ |John Stracke| http://www.ecal.com |My opinions are my own.| |Chief Scientist |=| |eCal Corp. |"I lost an 7-foot boa constrictor once in our| |[EMAIL PROTECTED]|house." --Gary Larson on his youth | \==/
Re: HTML email
> From: John Stracke <[EMAIL PROTECTED]> > > The practice of sending both HTML and cleartext of supposedly the same > > message reflects very poorly on those who do it intentionally and on those > > who cause MUA's to trick others into doing it unintentionally. Never mind > > the security issues, but consider only the wastes of disk space, CPU > > processing, network bandwidth, and the inevitable differences between the > > two versions. If the two messages were the same, then there would be no > > excuse for sending both. If they differ, then one must be wrong, and > > sending both is worse than a waste. > > So why does multipart/alternative exist? Perhaps in theory, it exists for the reasons implied by RFC 2046, especially the last part of section 5.1.4 or in the scenario described in RFC 1766. There are also RFC 2447 and RFC 2532. They all seem to involve situations where the two messages are not identical, but the having a wrong version is better than none at all and which cannot be predicted in order to avoid the waste. However, most of the vast quantity of objective evidence implies that multipart/alternative exists so that people can look stupid and technically incompetent by sending plaintext with HTML that when rendered looks practically identical to the plaintext. The remaining evidence implies that multipart/alternative exists to trick unwary recipients into rendering HTML containing things they would be wise to not let their computers evaluate, starting with porn (with all of its modern legal dangers) and tricky URLs (e.g. the concrete example recently displayed here), and continuing to other things with significant security problems. When was the last time you received a multipart/alternative message that did not make the sender look stupid, malicious, or both? I can't remember ever receiving any other kind of multipart/alternative. Maybe that's why so many competent people apologize when they realize they've been tricked by a MUA into sending visually identical HTML and plaintext. Vernon Schryver[EMAIL PROTECTED]
Re: HTML email
--On Monday, 15 May, 2000 18:22 -0400 John Stracke <[EMAIL PROTECTED]> wrote: > Vernon Schryver wrote: > >> The practice of sending both HTML and cleartext of supposedly >> the same message reflects very poorly on those who do it >> intentionally and on those who cause MUA's to trick others >> into doing it unintentionally. Never mind the security >>... > So why does multipart/alternative exist? (i) For those few situations in which there is information content in a "rich" fancy display form that cannot be rendered in a weaker form that where it is important to get some idea of the content through. This is clearly a judgement call on the part of the sender, but the usual mindless attachment of an HTML part to a plain-text message (to which I assume that Vernon is most strongly objecting) doesn't add any more information, just a bit of formatting that the receiving MUA could probably figure out from a text message if the developer and user were adequately motivated. (ii) For situations in which the meaning of multiple rendering is presumably the same but the string-content is very different. E.g., one could in theory send a message out in several different languages, tagging each, and permitting the receiving MUA to select the message that best matches the knowledge/usage/skills of the reader. Of course, the security issues in the latter case are the same as those that exist anytime you are handed text in a language you don't understand and some other text that proports to be an accurate translation of it. john
Re: HTML email
Date: Mon, 15 May 2000 20:11:45 -0400 From: John C Klensin <[EMAIL PROTECTED]> >> The practice of sending both HTML and cleartext of supposedly >> the same message reflects very poorly on those who do it >> intentionally and on those who cause MUA's to trick others >> into doing it unintentionally. Never mind the security >>... > So why does multipart/alternative exist? (i) For those few situations in which there is information content in a "rich" fancy display form that cannot be rendered in a weaker form that where it is important to get some idea of the content through. It seems to be usually the case, for most messages that I've seen, that there's *no* added value to the HTML version. I.e., other than adding at the end of lines, and using microsoft-specific font settings at the beginning of each paragraph (usually all the same), there's nothing to be gained by using HTML except for bloating the message. So one question to ask is "why send HTML at all" in those cases? It would be nice if MUA's could detect this case, and only send plain-text, and reserve HTML only for when it's actually adding something of value. This is clearly a judgement call on the part of the sender, but the usual mindless attachment of an HTML part to a plain-text message (to which I assume that Vernon is most strongly objecting) doesn't add any more information, just a bit of formatting that the receiving MUA could probably figure out from a text message if the developer and user were adequately motivated. I wonder how many people are still using plain-text, non-HTML enabled mail readers? It still happens on some mailing list, where someone will send a base-64 encoded html'ified message (usually using MS Outlook), and someone will send back "try again in English; I don't read that MIME crap." For a long time, if you wanted to guarantee that messages issued by your MUA would be read, it was wise to send it both in plain-text and HTML form, with the plain-text form first --- and non-base-64 encoded if at all possible. For certain recipients, this is still the case. - Ted
Re: HTML email
On Mon, 15 May 2000 18:22:00 EDT, John Stracke <[EMAIL PROTECTED]> said: > So why does multipart/alternative exist? Well, when we were designing the MIME spec, we went to great lengths to cover all the bases - in fact, I've seen one very good use of multipart/alternative by somebody with crippling RSI. He got into the habit of sending commentary to a mailing list as multipart/alternative - one part being a *very* brief summary of his commentary (usually a sentence or two tops), and the other being a message/external-body pointing at a (usually longer) audio file that he'd record in greater detail - this was in the days before good speech-to-text software. Yes, it probably violated the letter of the law just a bit, but it was certainly in the spirit of it.. Also, remember that we designed it in 1991 or so - the infamous Green Card Lottery was still 3 years away, AOL wasn't the majority owner of several northern Virginia counties, and the concept of a point-and-drool interface for the masses didn't exist yet. We designed it for the Internet we were hoping for, not for the one that we actually got Valdis Kletnieks Operating Systems Analyst Virginia Tech
re: Financial Stnadards Work group?
I do not quiet agree with the current standards, they are a pain in the neck. E.g ( Just one example ) I want the internet debit card and the devices for charging them to be standard hardware available in any computer store. This will allow one to chose any bank or service provider ( instead of your money going proprietory ): imagine buying a new modem or router every time you change ISPs or buying different kinds of printers for printing from different web sites. That is the position of debit card recharging buying a new device each time you change the service provider. The IETF can help or do you hold alternative views ( give me some recharging devices that allow change overs )?? Yours sincerely, Nyagudi Musandu At 10:28 14/05/00 -0700, you wrote: >Musandu <[EMAIL PROTECTED]> writes: > > >It may just be time for the IETF to develop a financial standards > >work group separate from the applications work group. I can even >forsee >a Simple Cash Transfer Protocol? any objections? > >There is an ANSI Financial Standards body (X9) which is also chair of the >ISO Financial Standards group. > >The electronic commerce payments working group (X9A10) has a draft standard >for all electronic retail payments (debit, credit, pre-paid, electronic >cash, etc) .. X9.59. > > >misc. ref > >http://www.x9.org/ >http://www.x9.org/main_organization.html >http://www.x9.org/subcomms/x9a/general/public/general.html >http://www.tc68.org/ >http://www.x9.org/n20.html >http://www.garlic.com/~lynn/ >http://www.garlic.com/~lynn/99.html#224 >http://www.garlic.com/~lynn/8583flow.htm >http://www.garlic.com/~lynn/draft-wheeler-ipki-aads-01.txt > >& of course my rfc index is also at: > >http://www.garlic.com/~lynn/rfcietff.htm > >as well as ietf, payments, security, X9F, and financial glossaries > > > >-- >Anne & Lynn Wheeler [EMAIL PROTECTED], [EMAIL PROTECTED] > http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/ > > >
Re: VIRUSES ARE PROFITABLE???
> ... why don't you isolate > your important information from the internet, including back ups for your > web servers and open attachments on offline isolated computers also remember > to do your browsing on seperate computers. That may reduce disaster > vunerability by about 5%. If you are so rich that you can afford one seperate computer for each little task to accomplish, please send me some money. It seems that you have plenty. - Anders Feder
