Re: web sites going dark
On Thu, 13 Sep 2001 08:11:31 EDT, stan kulikowski ii [EMAIL PROTECTED] said: how many times can any of us recall that this was done? for what reasons? A case could be made that we should keep our web sites *not* dark. Consider this: Israel is a small country surrounded by much larger countries that don't particularly care for it. Yes, it has a continuing problem with terrorist attacks - but not as much as you'd expect from location and population considerations. Why don't they have MORE of a problem? I'll submit the hypothesis that it's because every terrorist wanna-be that didn't just fall out of a tree knows that if you use a car bomb on an Israeli site, it doesn't accomplish much - you kill a few victims, they have funerals, the Israeli military launches a reprisal atttack. But the terrorist doesn't accomplish his main goal - upsetting the populace. In the initial hours after the attacks, somebody stated that George W Bush should return immediately to Washington DC, to send the message that he believed that DC was safe. I opined that no, he should remain in Nebraska for a while - because an even more powerful message for the terrorists than DC is safe is the message it doesn't even *matter* if DC is safe - this country is so great and so capable that we can drop our President in the middle of a corn field 200 miles from anywhere, and he can STILL run the country from there. It may not be the message *our* people want to hear - but if the terrorists learn that they're just trying to nail Jello to a tree - and that it's explosive Jello to boot. Valdis Kletnieks Operating Systems Analyst Virginia Tech
Re: World war 3
On Wed, 12 Sep 2001 10:40:01 +0200, TOMSON ERIC said: the war), there's simply nothing to excuse or justify such inhumanity *against innocent civilians*. You're making the dangerous assumption that the perpetrators have a belief system that recognizes the victims as innocent civilians. Even though there are civilians in it, I think everybody agrees that the Pentagon is a *military* target in any sense of the word. And if the perpetrators see themselves at war with Western capitalism, anybody who worked in the WTC is supporting the enemy and thus not innocent. *NOTE* - I'm pointing out what the perpetrators *might* believe. I'm *NOT* saying it's acceptable in my belief system - merely pointing out that *understanding* the thinking of the perpetrators is necessary in order to properly deal with the problem long-term. For instance, it would probably be a *very bad* idea to create martyrs during our retaliation. We've already had enough lack of success dealing with software vandals, often due to not understanding their motivations. Fortunately, so far it's been small stuff of the CodeRed variety. Failing to really understand the motivations and goals of a truly determined adversary in the Internet arena could be REALLY bad news. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
Re: Rumor about US disaster
On Wed, 12 Sep 2001 15:40:08 EDT, Don McMorris [EMAIL PROTECTED] said: all males between 18 and 40 will be drafted. At this time, as far as I = Fred Brooks wrote a very informative book called The Mythical Man Month. One of the points he wrote about was Adding manpower to a late software project makes it later. The basic precept is that until the new manpower gets up to speed, the old manpower is training not coding. Similarly: 1) Who is going to *train* all these males? I think our trained military is currently 2M people. Now, assuming a population of 300M, a life expectancy of 75 years, and a flat linear age distribution, this means there are some (300,000,000 / 2) * ((40 - 17) / 75) or 45,900,000 males to be drafted. Assuming we move ALL the current military to training, and assuming 1 drill instructor per 15 males, that still leaves us 1 million drill instructors short. Guess we'll have to rais it to 1 per 25. In the meantime, we have *NO* military capability at ALL, because they're all drill instructors. I'll gloss over the fact that only some 3-4% of that 2 million is actually TRAINED to be drill instructors - you need an awful lot of cooks, truck drivers, and other support staff (drill instructor is only ONE of the 212 ways to be an army of one ;) 2) What happens to the 43,650,000 jobs vacated (assuming a 4.9% unemployment rate, as reported in a recent newspaper)? Hint: at 4.9% unemployment, you can't cover a 30% reduction in workforce. Also - there WONT be any training, so productivity there will take an even BIGGER hit. 3) Compare 45.9M with the current population of California, and then ask yourself where the boot camp goes. Remember that you have to put it inside the CURRENT territorial limits of the US - you can't put it in the desert owned by the country you're contemplating pounding into submission. 4) Compare 2 million *trained soldiers* to the *total population* of most countries. Remember that in Desert Storm, we sent *part* of our 2M up against what was at the time the *fourth* largest standing army in the world. The biggest problem in Desert Storm was *moving* everything there and staging it. We'll have a similar issue this time. Once we figure out who's about to get pounded into the Stone Age. And we don't need more troops to do it - we're just waiting for a road map. Moral: Learn to do back-of-envelope calculations to sanity check numbers. Use a calculator if you have to. Especially when posting to a technical forum. Valdis Kletnieks Operating Systems Analyst Virginia Tech
Re: rfc 3030 comments...
On Mon, 10 Sep 2001 13:34:20 -, Franck Martin said: I'm just reading the rfc 3030 you made. I have been looking around for such protocol for large messages and I have been talking about it on the [EMAIL PROTECTED] mailing list. I think the RFC could be even greater if it would allow to send chunks in separate sessions... Bigger will be the mail message, higher there will be a session error or connection drop. Therefore you have to be able to recover (like http and ftp protocol do)... An extension to RFC3030 would be to have the server answering by a session ID with chunking and to use this ID in following BDAT commands in other sessions to recover from where the system left... Or other means of recovery... I've read over RFC1845 (SMTP Checkpoint/Restart), and it *seems* to do what you want. However, I'm cc:ing this to the IETF-SMTP list, in case somebody with more knowledge of RFC3030 and 1845 can see if there's any subtle interaction. It *looks* like it should be OK, as per RFC1845 you are handed a '355 octet-offset is the transaction offset' before you commmit to sending a 'BDAT ' to start sending. RFC1845 does say this: The SMTP canonical format for messages is used when this offset is computed. Any octets added by any SMTP data-stuffing algorithm do not count as part of this offset. In the case of data transferred with the DATA command the offset must also correspond to the beginning of a line. It's unclear if the beginning-of-line requirement applies if BDAT is in use, or how it would be handled if binary data was being transmitted. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
Re: Acronyms
On Sat, 08 Sep 2001 10:20:18 +0900, Jiwoong Lee [EMAIL PROTECTED] said: I think Readability and comprehensibility are the main goal in writing and organizing a technical document. We have plenty of acronyms in this field. Some are public-domain (wide-spread and well-known) and some are newly defined by the author and are introduced to the Internet society. (Not ISOC.) ... Which one do you think is better ? : Wise answers plz.. Acronyms aren't as bad as what people in other fields have to deal with. At least we *have* the letters on our keyboards, and don't have to resort to special typsetting because we have partial derivative symbols, or capital letters with vector arrows over them, or other things like that... Having said that, most style books say that acronyms when used in moderation are acceptable, as long as at first use they are identified - in your example, the use of ISOC as an acronym is OK if one of the following is true: 1) the reader is expected to have completed prerequisite work where the acronym was defined, and thus should already know it - thus the frequent use of 'RFC' in the IETF. 2) If the acronym is new or not reasonably expected to be known by the audience, the first use should be spelled out and then the acronym presented. For example: In other news, the Internet Society (ISOC) announced.. Additionally, this is a good spot to add definitions or expository material. Valdis Kletnieks Operating Systems Analyst Virginia Tech
Re: MPLS,IETF, etc..
On Fri, 31 Aug 2001 16:49:39 EDT, Natale, Robert C (Bob) said: To really jump the tracks here (since I'm pretty much just rambling on here anyway): It could be argued that both the dot com mania and melt-down were attributable -- in large part -- to the same mix of evangelistic and journalistic misunderstanding of simplicity. It wasn't simplicity. It was investor stupidity. Too many investors saw the 'e-' in e-commerce and saw some mystical quality that glossed over the 'commerce' - things that have been understood for hundreds of years, like cash flow and business plan. I can guarantee that even a cobbler in 1100AD understood I buy leather for X, I sell shoes for Y, and I need to sell enough shoes so that (Y-X)*n is enough money that I don't starve. Many of the dot-bombed had a *very* simple business plan: We'll burn investor money while we try to figure out how to make a profit while giving away the content for free. Now, this is a perfectly valid business model - if you're a 501(c) charitable organization and the investors are called benefactors. Now as for MLPS, it sounds to me like a good idea for its original design goals, but is being promoted for so many other things that many people are confused - Does it *really* slice, dice, *and* make Julienne fries? Valdis Kletnieks Operating Systems Analyst Virginia Tech
Re: Mailing Lists
On Wed, 15 Aug 2001 09:43:55 EDT, Meritt James said: Which Jim? We are BOTH James? Bruce, Bruce, Bruce, Bruce and myself.. But my name's not Bruce Well, that's going to make it a bit confusing, isn't it? (With apologies to Monty Python) /Valdis (who never seems to have that problem for some reason...) PGP signature
Re: Resume command for ESMTP?
On Sun, 05 Aug 2001 19:39:21 +1200, Franck Martin [EMAIL PROTECTED] said: So ESMTP could have an extension called RESUME The protocol would be standard, except that before DATA and after RCPT TO, the sending server who has identified the RESUME keyword could ask a RESUME session... For FTP and HTTP, most transfers are *DOWNLOADS* - which means that the server has *already* committed space on stable storage to hold the file on at least a semi-permanent basis. If it *is* an upload you are trying to resume, the user is most likely uploading to *his* storage space, which is likely quota-protecteed in some way. On the other hand, SMTP is a store-and-forward system where the files are kept in essentially *temporary* storage. As such, the general design philosophy is to throw away the temporary files if a transfer fails, so as to free up queue space. This in and of itself is not a problem, until you realize that quite possibly more than one file may need to be saved in case the person will *someday* try to RESUME the transfer. Now.. a real-life case in point. Our mail server is getting hit *thousands* of times a day with variants of the SirCam virus. Many of these transfers fail. Currently, our mail server would just toss the files related to the failed transfer - if it supported RESUME it would have to keep them around. It's call a 'denial of service attack'. Feed the victim lots of large files they have to keep around, and then leave and watch the fun as their mail server runs out of queue space. And that's why there isn't a RESUME. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
Re: Resume command for ESMTP?
Am taking further followups to [EMAIL PROTECTED] where it belongs... On Mon, 06 Aug 2001 10:11:33 +1200, Franck Martin said: The first principle, is not to store a mail part indifinitively, but to timeout it in the queue. The parameter should be left configurable. Let's say that the mail sender has 5mn to resume the session or it has to start from the beginning again. This would allow that the queue doesn't grow out of proportion because of errors. Is there any evidence that it is common enough to have a network outage severe enough that the TCP connection gets broken, but that within 5 minutes it's resumable? The second principle, is that most servers do a content analysis based on the line received. The mail server, needs to know where it is in the session. Are we still in the headers or already in the content? Based on content anylysis of the mail being received the server may send an error back, like Error content rejected, Malformed error, Message to big. The server trash the message and clear the session. This would take care of the sircam virus, like on my system where I block attachments with .exe or .lnk extensions. This is done easily on the fly while receiving the e-mails. Here the e-mail does not need to be fully received but as soon as a condition is met the session is closed. Closing the session on the fly is *very* anti-standard. Also, note that if you close it on the fly, a standard conforming MTA will *retry* it. Over and over, as you keep closing the session on the fly. A much better solution is to wait until the final '.' is received, and THEN do something interesting. See RFC2821, section 4.2.5 for details. I understand that a mail server with RESUME capability may need a bigger queue than one without, but HD space is cheap, and it saves huge amount of expensive bandwidth... The problem is that it may be cheap to say add another 500M to the spool for a *small* system. However, when you start talking about *large* mail systems, scaling becomes an important factor. I spent some time at a recent Sendmail workshop, and some of the people there were working on systems that had to do a million deliveries an hour. At these levels, even saying just move it to another queue for later becomes problematic - it takes a lot of I/O to sync everything to disk... And remember - these big systems are the ones you're probably having the trouble talking to. So What do you think? Anybody that support the idea and want to develop it further? Well.. I still think that the *proper* solution is to fix the TCP infrastructure so that there isn't a NEED for a RESUME -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
Re: Resume command for ESMTP?
On Sun, 05 Aug 2001 16:14:36 MDT, Alexey Melnikov said: SMTP Service Extension for Checkpoint/Restart RFC 1845. Damn. How did that sneak by me? ;) /Valdis PGP signature
Re: Any value in this list ?
On Thu, 02 Aug 2001 07:29:03 +0200, Anthony Atkielski said: no, it's more like blaming automobile manufacturers for producing cars whose brakes fail when used normally. No, it's more like blaming automobile manufacturers for brakes that don't apply themselves when the driver is too stupid to apply them himself. It's more like blaming the users for failing to put chocks under the tires because they fail to realize that just because the stick is in the PARK position, the car may shift to DRIVE under some circumstances not under direct obvious control of the driver (say, if 3 red pickup trucks in a row drive by). And *ANY* system that attempts to interpret 'image/jpeg' as *ANYTHING* other than image data is just WAITING to pop into DRIVE. /Valdis
Re: Any value in this list ?
On Tue, 31 Jul 2001 11:17:59 +0200, H. Szumovski (via secureshell) said: .) Throw silently away mails containing the string [spam in the subject. I've never actually seen a spam that has '[spam]' in the subject. I save the RFC822 headers of mail I receive, and of the 4,652 headers I have going back to Feb 1, there are 13 that match 'grep -i spam'. Of those, 8 are from a thread Subject: kyxspam: isc loses mind and 5 are from a thread Subject: More member-only anti-spam. On the other hand, I average 20-30 pieces of spam a day that do NOT contain 'spam' in the Subject: header. A better heuristic is called for. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
Re: filtering active content
On Sun, 29 Jul 2001 15:55:46 PDT, James P. Salsman said: How do you feel about filtering winsock connections to TCP port 25 in a way such as would allow the user to confirm that a particular program could always do so, but would be asked to approve the connection when programs without prior approval do so? That would take care of the SirCam strain. A patch has been available that would fix SirCam *and* most other address-book viruses for a *year*, and we're still getting hosed by it. Certainly doesn't bode well for when CodeRed wakes up in about 47 hours and 30 minutes - I'll bet most of the 300K machines that got hacked are still unpatched and still infected. It's gonna be a LONG week guys. Valdis Kletnieks Operating Systems Analyst Virginia Tech
Re: IPv4 vs MAC
On Thu, 26 Jul 2001 18:52:50 CDT, Jose Manuel Arronte Garcia [EMAIL PROTECTED] said: If the used 48-bit addresses in lower layer protocols, why they did not use 48-bit routing-enabled addressing for the Internetwork layer? Not just use the very same addresses as I may have implied (I DO NOT mean that). After all, they were using 48-bit addresses already. First off, 32 was probably chosen because it was a number of octets(*) that fit nicely into a register. Dealing with 48 gets more interesting. Secondly, at the time, a 9600 baud leased line was a *high speed* link, and 56KB was long haul backbone link. The added 4 bytes/packet would be noticable at that speed. Third, they were doing a new design, and the old one (NCP) had a 256 host limit. I wasn't there, but I bet '4 billion will be PLENTY' was a common sentiment - and understanding the amount of address space wasted by subnetting and the eventual need for CIDR so routing tables could be aggregated were still a decade down the road. Valdis Kletnieks Operating Systems Analyst Virginia Tech
Re: duplicate messages on IETF mailing lists
On Thu, 26 Jul 2001 07:54:51 MDT, Vernon Schryver [EMAIL PROTECTED] said: This morning (7/27) ietf.org or optimus.ietf.org claims via the HELP command to be running Sendmail 8.9.1a. There are reasons that many people consider sufficent to switch from ancient 8.9 to current 8.11.4 or even 8.12.0. Hey wait a minute - I'm not done finding bugs in the 8.12.0 betas (just caught one yesterday, in fact ;) Actually, it's fairly stable, and in public beta. But remember guys, 8.12.0 *IS* still beta. On the other hand, the general consensus at a recent get-together of Sendmail people was that running anything pre 8.9.3 isn't a good idea at all in today's Internet. Upgrade to 8.11.4, or 8.12.0 will be out very shortly. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
Re: Attachment Stripped in Transaction
On Wed, 25 Jul 2001 13:37:33 BST, Lloyd Wood said: The message is that the IETF's work in describing protocols is done only in the basic protocol of text. Correct. If it can't be described in text, it probably can't be implemented in text as a computer program either. The point I was trying to make was that if we simply filter *ALL* messages that aren't text/plain, we're sending a message that we've given up on multipart/signed messages as well. Surely after almost a decade of MIME experience, we can do better than just saying Throw out all stuff that isn't text/plain. /Valdis PGP signature
Re: why cant this list clean up the spam!!??
On Tue, 24 Jul 2001 18:49:05 +0200, Nicolai Schlenzig (DXD) [EMAIL PROTECTED] said: The sender can, afaik, not help it. It's sent automatically if you're first infected. However - who on earth would open such mail attachment? And if doing so... w/o an updated antivira? Beats me... RFC1341: (June 1992) Security Considerations Security issues are discussed in Section 7.4.2 and in Appendix G. Implementors should pay special attention to the security implications of any mail content-types that can cause the remote execution of any actions in the recipient's environment. In such cases, the discussion of the applicaton/postscript content-type in Section 7.4.2 may serve as a model for considering other content-types with remote execution capabilities. We knew about the issues when we did MIME. Complain to the implementors. ;) -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
Broken mail systems.
Whereas: The Internet standards state that automatically generated error messages should be directed at the SMTP MAIL FROM: address, which is often locatable in the Return-Path: header. Whereas: Certain software vendors fail to respect said standards, resulting in their software annoying thousands of subscribers on mailing lists. Whereas: The standards have only been the standards since '56k' meant a very high speed backbone link, so it should hardly be a surprise. Therefor, let it be resolved: That users of said software be summarily removed from the IETF mailing lst, and be sent a Your clue must be - THIS - tall to ride the Internet notice. They call it a talent pool. Too bad it varies between a children's wading pool and a wet towel on the floor. /Valdis
Re: Comparison of ICAP and SOAP
(trimming back the cc: list for sanity) On Tue, 10 Jul 2001 16:26:01 PDT, Mark Nottingham said: Many involved in the development of SOAP acknowledge the limitations of using HTTP. However, SOAP is being designed to allow multiple bindings underneath, not just HTTP; HTTP is only the chartered transport for the 'core' WG. Most anticipate that HTTP will only be used for relatively simple applications, while more business critical uses will be transported across things like BEEP or DIME-over-TCP. The cynics and realists among us read this as: SOAP over HTTP is the only chartered transport, so an RFC will be produced for that, complete with all the HTTP-implied warts. This will be implemented by several large software companies and become the de facto standard. A few people will create non-interoperable versions of BEEP or DIME encapsulation, but these will die off because they're not standard, and too many big software houses will botch SOAP-over-HTTP because they can't get HTTP right to have even a snowball's chance in Beelzebub's backyard for them to ever dream of doing a BEEP or DIME versions. /Valdis
Re: Whither OPES? [was: Antigen found W32/Hybris.gen@MM (McAfee4,Sophos) virus]
On Tue, 10 Jul 2001 20:01:40 PDT, Mark Nottingham [EMAIL PROTECTED] said: Interesting... seems to be a message generated by an intermediary that used a heuristic to vector the message and effect a transformation... Unfortunately, that transformation was performed without proper knowledge of the semantics of the application protocol, incurring unintended and undesireable results. Maybe if we standardized the heuristics and the means of vectoring, the transformation engines would magically behave in a more responsible manner... or maybe it would just encourage the deployment of transformation engines. Umm.. Mark? The heuristics *are* standardized. It's called Thou shalt send this crap to the SMTP MAIL FROM: address. Of course, if people manage to botch something THAT simple and well understood, how will we ever deploy a working OPES? /Valdis
Re: Re[2]: too many Out of Office AutoReply
On Fri, 29 Jun 2001 23:05:18 +0530, Ashutosh Agarwal said: I personally would like to receive some kind of ACK from the person whom I am trying to send a mailso that I am rest assured that the mail has Some of us do *NOT* like getting 15 or 20 such messages from people we have never heard of, just because we post to the IETF or Bugtraq or Incidents mailing lists. How many responses did you get to *your* posting? The IETF list is relatively clean this week - but I *have* had days when I have gotten over *200* of these Out of Clue AutoReply in *ONE DAY*. And not one single solitary one was a result of a direct mail to that recipient - all 200 were nice replies to things I posted to the list. Over and over and over. I post 4 times in one day, these things are nice enough to tell me 4 times that day that yes, George is STILL out of the office and will be for the next week. Never mind that it: 1) it SHOULD keep track of who it replied to and not reply AGAIN for this invocation of out of office. 2) it SHOULD NOT reply to mailing list postings. There *is* RFC2298 on how to get an ACK from the mail system. And guess what - it specifically says to not auto-reply if the origin seems to be a mailing list. From section 2.1: MDNs SHOULD NOT be sent automatically if the address in the Disposition-Notification-To header differs from the address in the Return-Path header (see RFC 822 [2]). In this case, confirmation from the user SHOULD be obtained, if possible. If obtaining consent is not possible (e.g., because the user is not online at the time), then an MDN SHOULD NOT be sent. /Valdis
Re: too many Out of Office AutoReply
On Thu, 28 Jun 2001 16:25:07 BST, Lloyd Wood said: message. Apparently the Microsoft stuff is quite hard to configure well. To the point that I've *yet* to find somebody who can tell me how to do it for the offending versions of 'Internet Mail Service'. Or is it permanently broken, not configurable, and the organizations afflicted with it need to be sent a 'Your clue must be -THIS- tall to ride the Internet' notice? -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
Re: IPv6
On Wed, 27 Jun 2001 12:32:02 EDT, Don McMorris [EMAIL PROTECTED] said: 1. Which operating systems currently support it? I irun RedHat linux, = and it does not, to my knowlege. RedHat Linux 7.1 supports it just fine - am running a 2.4.5 kernel with the USAGI IPv6 patches and it works. Some Assembly Required though. http://www.ipv6.org has a lot of references. In particular, there's a who runs it list at http://www.ipv6.org/impl/index.html - the Unix list seems to include all the major players except SGI. http://www.linux-ipv6.org will get you started for Linux. http://www.bieringer.de/linux/IPv6/ is a good source as well. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
Re: too many Out of Office AutoReply
On Wed, 27 Jun 2001 18:44:41 BST, A James Lewis [EMAIL PROTECTED] said: I notice also that ALL of the autoresponder messages come from Internet Mail Service Microsoft software No surprises there then! I used to send a canned note to people who did that, explaining that it was poor netiquette, but gave up when I noticed that: (a) 99% of the offenders were using that software (b) I have *yet* to find somebody who can tell me how to configure said software to not reply to mail that comes from owner-* or *-request addresses. If somebody has a choose this tab, select that, type this cookbook, please let me know -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
Re: I am *NOT* a believer in the democratic process.
On Mon, 25 Jun 2001 12:01:03 PDT, Brian Lloyd said: threshing process. I see entirely too little threshing going on in the IETF these days. I think we worry to much that people will get their little feelers hurt. Send them my way. I'm renowned for my ability to tell almost anybody, in excruciating detail, exactly why their idea is dumber than a box of rocks. ;) So let 'em build their protocol, whatever it is, and bring it to the IETF. The problems with a really bad protocol can be extremely educational and entertaining. The elegance of a really good protocol can be extremely educational and entertaining. I don't see how we can lose. Actually, a Really Bad Protocol is usually dreadfully excruciatingly painful, unless somebody performs an MST on it. For those not familiar with it, see http://www.scifi.com/mst3000/ for the TV show, or http://brie.bmsc.washington.edu/people/merritt/books/Eye_of_Argon.html for an example of the concept. Now, maybe if we had more protocol reviews like that... ;) /Valdis
Re: WG Review: Open Pluggable Edge Services (opes)
On Wed, 20 Jun 2001 15:58:48 MDT, Vernon Schryver [EMAIL PROTECTED] said: From: Adam Shostack [EMAIL PROTECTED] ... Yes. I made a point of saying The threat under discussion is that there is a proxy modifying content... because this discussion started with OPES. In that particular case, where random people might approach your website, you want to send them content that is authenticated, and there is no out-of-band channel, then you don't have a way to send them a certificate reliably. There is no creditable threat that OPES or OPES-like mechanisms would filter, replace, or modify my or anyone's certificates. It is silly to imply that AOL might use something like OPES to defeat the distribution of certificates that would wreck SMTP interception proxies like AOL's. I think you misread this - what Adam *meant* was that without a workable low-cost PKI system, or other means of distributing certificates, the person at the other end doesn't have a certificate to verify that an OPES-class mechanism hasn't done something ELSE to the bits. If I create a self-signed CA to protect my personal website on my computer, how do you get the certificate so you can verify that an OPES hasn't translated my text into an obscene poem in kanji? That's the threat model here /Valdis
