Slashdot Mirror

http://www.ietf.org/rfc/rfc1149.txt?number=1149.

HTTP Digest Authentication

RFC2795

Also, bad redneck joke:
If you took an infinite number of rednecks and an infinite number of STOP signs and had them shoot at them with an infinite number of shotguns, would you eventually get a work of Shakespeare in Braille?

The "SMTP Service Extension for Secure SMTP over TLS" (STARTTLS for short) defined by RFC 2487 already provides the technical framework for Tripoli. And is today supported by Sendmail, Exchange, Postfix, Exim, etc.

It normally runs over TCP port 25, the initial connection is normal SMTP, then the STARTTLS directive begins a TLS-encrypted session. STARTTLS can be configured to only accept mail sent with a trusted certificate, or to allow anyone to connect - it is compatible with existing SMTP.

The one additional item in the Tripoli proposal is the use of a trusted third party to validate certificates. Great if this can be made to work, though current experiences with PKI make me doubtful of a truly Public Infrastructure. But STARTTLS can certainly work amongst smaller private user groups.

One current hurdle preventing wholesale adoption is that few ISPs support STARTTLS. Not a problem for people running their own mail servers, though even they would want secondary servers to support STARTTLS. But if the core ISPs started using STARTTLS, they could mutually authenticate each other. Initially all mail could be accepted, but later on unauthenticated mail could be filtered more rigorously.

When we understand the way books are printed we would only understand its very different than what we would assume.Burning CD's and printing Books is quite different, CD printing is in a digital format, while plain paper printing, binding is a lot more time consuming and costly affair. Custom Internet books printed through digitial copier machines would cost a hell lot.

When we understand the way books are printed we would only understand its very different than what we would assume.Burning CD's and printing Books is quite different, CD printing is in a digital format, while plain paper printing, binding is a lot more time consuming and costly affair. Custom Internet books printed through digitial copier machines would cost a hell lot.

Now just add in a few wooden peripherals, and the occasional pigeon for the networking, and you'll be all set!

"For starters, it's essential that the old addressing scheme be a straightforward subset of the new one."

Actually, it is. There is a whole block of IPv6 which is the IPv4 address space. So if your IPv4 address is 10.20.30.40 your IPV6 address is :0a14:1e28 (you convert the bytes to hex).

You're talking about rfc 2893 ipv4 compatibility? Well, "IPv4-compatible addresses are assigned exclusively to nodes that support automatic tunneling". Dumb dumb dumb.

The IPV6 designers spent (and continue to spend) far more time on the migration issues than on the actual protocol changes.

That's because they didn't make it enough like the current system, even though that would not have been hard to do. Come on, is this or is this not an observed fact?

If I could just drop in an IPv6 stack and have everything just work, I'd no doubt be running IPv6 right now, and I'd own at least one public IPv6 address. As it is, I don't own any IPv6 addresses because I wouldn't be able to connect to them from outside anyway. And yes, there would still need to be a way of enabling the most significant octet, but with the stack in place at home and at my ISP (because it just works, duh) we're already most of the way there.

At this point the IETF has pretty much alienated everyone but the academics and the open software crowd.

They've alienated the open source crowd too. (In case you don't see right away what's happening here, IETF is defending its policy of allowing RAND patent-encumbered standards, which is obviously incompatible with free software implementation of same.) I can't speak for the academics, but it does invite the question, just who they haven't alienated.

NAT is bad. It screws up the end-to-end transparency of the Internet. People shouldn't rely on it as it only delays the inevitable: IPv4 adress space exhaustion. With IPv6 you (as the end user) get a ~2^64 usable address space, aka /64 prefix.

Well, too bad IPv6 is not widely supported. I'd like my ISP to deliver *native* IPv6 services. As of now I'm running IPv6 through a tunnel with all the associated problems: long delays between hops, shitty DNS resolution (for reverse records), etc.

Hm, rahter than using NAT one could use some kind of 6to4 translation and have his network run on IPv6, provided that it's supported by the nodes. Windows doesn't even come with IPv6 out of the box, and Linux distributions are somewhat lacking in the field. The BSDs are way ahead of everyone else I guess. Mostly because of the japs, who afaik are running out of IPv4 addresses.

You have to just jump in! I too am already using IPv6 comfortably alongside my routed IPv4 network. I actually forced myself to start using it just 'cause, and it's wonderful. The autoconfiguration features are worth it alone. And I have a mixed network of Linux, AIX, HP-UX, Windows 2000, and Cisco. My bind/DNS is configured for IPv6, my sendmail is configured for IPv6, and so on. But the underlying IPv4 network is still there right along side. There's really no reason to not go ahead and start experimenting with IPv6, to get comfortable with it before you depend on it.

Actually my excuse to start playing with it was I was developing an application which could make use of multicasting. And let me tell you, IPv6 multicasting is a dream come true when compared with IPv4! And the sockets-API is much more sane and complete, after all the IETF learned from the shortcomings of the IPv4 API. See these wonderful resources and just jump in!

• RFC 3493 Basic IPv6 Sockets API
• RFC 2292 Advanced IPv6 Sockets API
• IPv6 Essentials Book, from O'Reilly
• IETF IPv6 Working Group
• Linux IPv6 HOWTO

So now that I'm enjoying it, I've been seeking out open source applications that use IPv4 and providing assistance to the developers to get them compatible with IPv6. A lot of the smaller projects in particular could use help, as some of them are unnecessarily tied to the IPv4 stack and probably don't even know it nor know anything about IPv6. I also suggest that anybody with some expertise to lend a hand as well. The open source/free software community can not find itself falling being here.

You have to just jump in! I too am already using IPv6 comfortably alongside my routed IPv4 network. I actually forced myself to start using it just 'cause, and it's wonderful. The autoconfiguration features are worth it alone. And I have a mixed network of Linux, AIX, HP-UX, Windows 2000, and Cisco. My bind/DNS is configured for IPv6, my sendmail is configured for IPv6, and so on. But the underlying IPv4 network is still there right along side. There's really no reason to not go ahead and start experimenting with IPv6, to get comfortable with it before you depend on it.

Actually my excuse to start playing with it was I was developing an application which could make use of multicasting. And let me tell you, IPv6 multicasting is a dream come true when compared with IPv4! And the sockets-API is much more sane and complete, after all the IETF learned from the shortcomings of the IPv4 API. See these wonderful resources and just jump in!

• RFC 3493 Basic IPv6 Sockets API
• RFC 2292 Advanced IPv6 Sockets API
• IPv6 Essentials Book, from O'Reilly
• IETF IPv6 Working Group
• Linux IPv6 HOWTO

So now that I'm enjoying it, I've been seeking out open source applications that use IPv4 and providing assistance to the developers to get them compatible with IPv6. A lot of the smaller projects in particular could use help, as some of them are unnecessarily tied to the IPv4 stack and probably don't even know it nor know anything about IPv6. I also suggest that anybody with some expertise to lend a hand as well. The open source/free software community can not find itself falling being here.

You have to just jump in! I too am already using IPv6 comfortably alongside my routed IPv4 network. I actually forced myself to start using it just 'cause, and it's wonderful. The autoconfiguration features are worth it alone. And I have a mixed network of Linux, AIX, HP-UX, Windows 2000, and Cisco. My bind/DNS is configured for IPv6, my sendmail is configured for IPv6, and so on. But the underlying IPv4 network is still there right along side. There's really no reason to not go ahead and start experimenting with IPv6, to get comfortable with it before you depend on it.

Actually my excuse to start playing with it was I was developing an application which could make use of multicasting. And let me tell you, IPv6 multicasting is a dream come true when compared with IPv4! And the sockets-API is much more sane and complete, after all the IETF learned from the shortcomings of the IPv4 API. See these wonderful resources and just jump in!

• RFC 3493 Basic IPv6 Sockets API
• RFC 2292 Advanced IPv6 Sockets API
• IPv6 Essentials Book, from O'Reilly
• IETF IPv6 Working Group
• Linux IPv6 HOWTO

So now that I'm enjoying it, I've been seeking out open source applications that use IPv4 and providing assistance to the developers to get them compatible with IPv6. A lot of the smaller projects in particular could use help, as some of them are unnecessarily tied to the IPv4 stack and probably don't even know it nor know anything about IPv6. I also suggest that anybody with some expertise to lend a hand as well. The open source/free software community can not find itself falling being here.

A large number of providers offer IPv6 support today. NTT/Verio has been offering this as a Commercial Service for quite some time, as well as through the domestic provider OCN and the OCN DSL services. As the 6bone tunneled networks go away, there is ongoing native support being added to networks. IETF and other conferences have been supporting providers that offer native IPv6 services. Aside from the always behind the ball DSL/Cable providers in the edge provider space of multicast, IPv6, etc.. you can contact any of the Tier-1 networks to obtain IPv6 services. Likely for free and not out of the 3FFE space. Build IPv6 into your kernels, ask your service providers for IPv6 and encourage them to provide these to you for little/no additional cost. Juniper and Cisco routers currently offer IPv6 in their current software releases. Now that Cisco has acquired Linksys, hopefully they will assist in providing support for these services in the edge-router space.

I am afraid this will introduce latencies remniscent of RFC 1149.

64 bytes from 10.0.3.1: icmp_seq=0 ttl=255 time=6165731.1 ms...

I guess with presidential politics already starting it was inevitable that people would start putting forward ideas to combat spam in the political arena. My first question on this is why would I pay the government anything to send email, since neither state nor federal agencies have anything to do how I process email. They don't provide bandwidth, servers, or even oversight. The author's suggestion that this money could be used to "The proceeds could go to maintain and expand bandwidth." is patently ridiculous since the government doesn't provide bandwidth, private companies do. The next issue is just how would you even implment this? Most of the spam that our servers process comes from places that US can't tax, and I imagine that if this was implemented, then the remaining spam would quickly move to places that aren't known for cooperating with US courts & extradition. There is a reason that Sharman Networks (the folks who own Kazaa) are incorporated
in Vanuatu
The only thing that we can do that isn't a band aid or a un-enforcable law is look at how to rewrite the SMTP protocol, right now it is far too easy (by design) to send email from anywhere to anywhere without any accountability. We need a system that allows for servers to positively identified (something similar to a secure cert, not that I want to hand more money to Verisign but...) Then its up to the individual admin to decide what to do with email from a un-certified server; accept it, rate limit it, tag it, or deny it. Now no one _wants_ to rewrite all of the MTA's in the world, but at least this gives a way for non-compliant servers to get mail processed until everyone has gotten their's updated.

RFC 3445

This caused massive problems so the DNS Extensions working group has eliminated it. This has been true since December 2002 and 3445is now a proposed standard as well as an RFC so the FreeS/WAN guys are making a really major mistake. The record sub-type bits they're using are now defined as RESERVED status and "MUST be set to 0 and MUST be ignored by the receiver". Once enough DNS servers have implemented RFC 3445 the records won't propagate through the system at all. There are better ways to do this - take a look the leading underscore system that SRV records use (synthetic sub-hosts on a per service basis). Special TXT records are still fully usable or they could simply go to the DNS-EXT working group and say "Hey, we'd like to define a new record type. What's the best way to do it?" Opportunistic encryption is a big step forward, but it's useless if it's broken by design and the arrogance of ignoring the IETF is the kind of thing that's slowly edging FreeS/WAN towards irrelevance.

I am familiar with SMTP, and I did think about it logically. The sequence is HELO, MAIL FROM (there is no RCPT FROM; you don't send from a recipient; think about it logically), and then RCPT TO.

Please see RFC 821, which describes this sequence. There are examples.

For future reference, when you say things like "think about it logically", make damn sure you are and the person who you are saying it to isn't. Because seeing people secure in their stupidity really pisses me off.

http://www.ietf.org/rfc/rfc1149.txt

A Standard for the Transmission of IP Datagrams on Avian Carriers

This memo describes an experimental method for the encapsulation of IP datagrams in avian carriers. This specification is primarily useful in Metropolitan Area Networks. This is an experimental, not recommended standard. Distribution of this memo is unlimited.

(I realize the articles listed are 8-9 months old, but clearly the issue is still relevant.)

I'm unfortunately not running OE, as my DNS provider (UltraDNS) did not provide the capability to add KEY records to a zone at the time I went through the installation process. Not sure if they do so now; perhaps time to check! I'd be interested in discovering which DNS providers do or do not provide the ability to insert KEY records into zones.

I hope the newsletter is for the VOD trade group, 'cause it won't get much traction anywhere else given your premise. I design broadband systems including DSL, CMTS, FTTH, FTTC, wireless, etc and I can let you know that none of them are remotely ready for true VOD. In fact most of the "VOD" systems are actually the near VOD similar to what DirectTV uses. Now given that everyone would _like_ to have real on demand VOD why do you think company implement near VOD? The simple answer is bandwidth, with IGMP proxying Click here for the RFC you only need the amount of bandwidth equal to the lesser of either your total number of subscribers on each DSLAM/node or the total number of channels. Take a simple example of a DSL system that offers 100 channels of broadcast & near VOD and their density per DSLAM is 300 subs and that they only allow ONE set top box per household. This means that I need to provision at least 300 mbps (OC-12 minimum) to that DSLAM to handle the traffic (100 channels x 3 mbps per channel I'll address the reason I use 3 mbps later). Now lets says that I want to offer true VOD, suddenly our bandwidth needs to that DSLAM have tripled to 900 mbps (OC-24 minumum but I'll probably have to use an OC-48 since most vendors don't make an OC-24)because VOD is inherently a UNICAST not multicast service. It doesn't take a mathematician to see the challenges. To further complicate matters, most of the DSL systems in the world work run ATM at layer 2. This is a problem since ATM is inherently a connection oriented protocol, in other words there is no simple way to send a broadcast as you do in Ethernet or other baseband shared acess system. This means that you have to have a large system or systems to handle the load of (1) creating the main IGMP streams at the head end and (2) doing all the work to SAR that data into and out of the ATM cloud. This adds a great deal of cost to the system since SAR'ing takes allot of processing power. Also to run video reliably you need to be running your PVC's as VBR-NRT or better. All of this adds up to very expensive gear. The reference to power line based broadband is very much wishful thinking, that technology is not even close to being ready for a major deployment and there are NO standards for access. 1.5 mbps as a planning bandwidth per video channel is also not realistic, it is possible with some of the very low bit rate encoders but those are all two or three times as expensive as "normal" 3.0 - 3.5 mbps encoders and you still haven't made any provisions for HDTV which runs in excess of 27 mbps.

There are few aspects of SSH vs. IPsec that you seem to be missing:

* first of all, IPsec can go through NAT, no problem. There is a couple of IETF drafts that - define just that IPsec NAT Traversal. Drafts are in their 5th revision, and Cisco, SSH, Nortel and some other manifacturers already support NAT-T and are quite interoperable with each other. Keep in mind though that it's UDP based, and that's the way it must be, because ...

* TCP-based VPNs (and SSH/SSL tunneling in particular) are prone to a trivial DoS attacks, which severely depricates their robustness. I put a quick paper together that provides a bit more details on the subject.

* keep also in mind that tunneling over SSH leads to TCP-over-TCP encapsulation, which is considered by many 'a bad idea' in general due to the induced TCP retransmission problems.

* you may also consider that SSH comes with a higher average per-packet overhead (due to TCP ACKs), which may require more frequent re-keying when compared to IPsec, which in turn may bring overall VPN performance down.

The bottom line is I would not recommend SSH over IPsec unless it's a time-critical project .. or you dont have a budget for a decent IPsec client :)

1. Education - Get educated about what information security is all about, you should know what C.I.A. stands for (in infosec, not the US federal agency), you should know what a security policy is, understand risk management and mitigation, and known what criminals/attackers can do in your organization.

You can get a lot of this from several books and websites, such as Secrets and Lies by Bruce Schneier, the SANS Reading Room, if you can afford it SANS/GIAC training and/or certification may be of benefit to you and your org, the CISSP and SSCP Open Study Guides even if you don't go for CISSP or SSCP (I don't recommend paying any money to ISC^2), and Security Focus.

2. Audit - This step is critical and too many places forget to do it. You need to know what you are trying to secure, yet most organizations do not have a complete picture of their network and all the systems on it. This includes security and non-security issues (e.g. software licenses, maintenance patches, standardization)

Tools like those from IBM Tivoli or HP Openview can help here. For security specific vulnerability analyzer, open-source Nessus and eEye's Retina, ISS's Internet Scanner

3. Policy - You need a plan and a document to give you and others guidenance, and this if your infosec policy.

Large orgs should consider BS 7799 or ISO 17799 whereas smaller groups can look at Center for Internet Security for benchmarks, and SANS Reading Room - Auditing and Assessment, and Site Security Handbook - RFC 2196.

4. Implement -- Using your education, audits and policies you can now implement decent security.

Basic principles of defence in depth, fail-safe, separation of privilege, and complexity is the enemy of security can guide you to build a practical network of secured systems that limits exposure to criminal activities, and minimizes damage from attacks.

5. Be vigilant - "Security is a process, not a product" - Bruce Schneier

Now the work begins, up to now it was the fun stuff, now you get to dig in with boring but important tasks such as analyzing log files, maintaining a accurate asset database, applying patches, maintaining user accounts, periodic audits (internal and if you can afford it and it is warranted, external), educating users, and maintaining your security posture.

there's an RFC dealing with that exact problem.

basically what they're proposing to do is use DNS to map phone numbers to ip addresses. if your voip phone is assigned a phone number of 5125551212, you would send a dns query with an address of 5.1.2.5.5.5.1.2.1.2.e164.arpa in order to get the ip address assigned to that number. as far as i know this hasn't been implemented yet, but it's a pretty cool hack nonetheless.

I too have noticed that the vast majority of spammers now seem to forge the HELO/EHLO greeting. And as most non-spammers don't, this is actually a wonderful way to catch them. I've even seen them send the IP address of my secondary mail gateway in hopes that my primary mail server would fully trust it (obtained probably by looking up my MX records). I run a mail gateway for a corporate domain an get on average 30 to 40 thousand spams per day. Using sendmail with it's milter programming interface I put the HELO greeting though a very strict check. For those contemplating doing the same...

• Per RFC 2821, the HELO greeting string should be either the FQDN of the sending hostname, or the IP address of the sending system in SMTP syntax (e.g., [1.2.3.4] or [IPV6:abcd::1234]
• Most spammers don't even bother with a domain name, using a random greeting like "sqss7e". If it doesn't have a domain, throw it away. Same if you see an IP address without the [] brackets; it's another dumb spammer that can't read the RFC's.
• Sometimes spammers don't even hide their spammy-sounding names in the HELO greeting even though they go to a lot of trouble to make up legitimate From headers. A good regular expression check for common words like "offers" or "optin" in the HELO greeting can work wonders (but use caution).
• When checking if a spammer if forging your own address, be sure to check for ALL hostnames under your domain (say you have acme.com, then check for both "acme.com" and "*.acme.com", and use a case-insensitive comparison). Also check for ALL your possible IP address even if you don't use them all. A remote site using your own IP or hostname is never legitimate.
• If you are running a gateway, you need to treat outbound versus inbound messages differently. This can usually be done by checking the connecting IP address to see if it is one of yours. Also be sure to check for 127.*.*.* and ::1 (IPv6).
• Be aware that some mail clients are broken and don't send conforming HELO greeting; this includes Mozilla (see Bug 68877). So don't be too agressive with your HELO checks for mail originating from the inside of your organization.

One last note about Forged AOL Spam after talking to one of their postmasters...all their legitimate mail by corporate policy is always sent from within the *.aol.com or *.aol.net domains. This will be in both the HELO as well as a reverse DNS lookup of the connecting IP address. If you don't see this in the HELO and DNS but you see a MAIL FROM for aol.com, it's probably spam.

I wish more big ISPs would provide public information about how to better detect forged mail claiming to come from their sites. For instance if I see a MAIL FROM *@yahoo.com, then should the connecting IP address always be from a *.yahoo.com host? Some ISP's like hotmail seemingly always add in a known predictable header whose absence indicates spam. But I can't reliably make these calls unless the ISPs provide that information. Also, beware that some semi-legitimate sites, like Monster.com forge the sending address on purpose; so if you want to receive resumes you may need to whitelist them.

We can also start wrapping processor instructions in XML and transmit them via SOAP, in order to create more interoperability between different machine architectures! Remember, we already have IP over XML :-)
That's what the whole thing sounds like to me...

But really, now that I think of it, I should have told them that it would have worked if they'd implemented RFC 3251 over 802.11! ;)

we can have electricity over IP over 802.11b!

Just get rid of email as we know it. This is getting much too complicated for me.

Just do away with email. I've already done it with my US Mail. Every day, I'd open my mail box and find trash. Honest to God TRASH. So I told them I didn't want mail any more, just like in Seinfeld, only they actually did it.

I still have email, but I'd be happy to use this protocol instead, if only there was an effective reference implementation.

I also wanted to know if anyone knew what language iCalendar was written in.

Looks like American English to me. Why don't you look at the iCalendar specification yourself and see if you agree. I believe all RFC's are written in English.

What's a PIM in this context?

You're missing something that just about everyone who talks about "the limitations of SMTP" misses: SMTP isn't limited. SMTP has a standard mechanism for introducing extensions such as cryptographically certifying mail servers, and mechanisms already exist to allow for fast, distributed key recovery and verification.

Reading the RFCs is a very good start to understanding how to solve this sort of problem. Giving everyone on the Internet (or at least all of the SMTP-sources) an Identity and then actually attaching a record of trust to those identities would be a wonderful idea, and does NOT require replacing SMTP. In fact, if you do it very, very carefully, it probably doesn't even require writing any (or at least very little) new code.

Avian carriers can provide high delay, low throughput, and low altitude service.

The real future is in distribution of electricity over IP.

That's great if you can pull it off, but most of us don't have that luxury.

There are five e-mail addresses that can reach me, which get different degrees of spam, due to different abilities to keep them private:

1. The primary address for my ISP is kept completely private - I don't give this address to anybody - not even my immediate family. It's not a word that appears in the dictionary. Only my ISP and I know this address, and the only thing I get from them is the monthly receipt for the bill. This account has not received any spam (at all - not one) in many years, although the mailbox that forwards itself into this mailbox does get spam.
2. My second mailbox is also from my ISP. It forwards everything into the primary address. The idea here is that I can blow away this mailbox without blowing away my ISP account along with it. I give this address to family, friends and some private mailing lists. This address gets some spam, but not very much.
3. The third mailbox is a web-mail box from mail.com. This is my spam-trap address, which I use on all web sites, newsgroup postings, and for my shopping. I expect this one to get spammed, but because it uses a web interface, I can sift through the subject lines and delete the spam without downloading it. The surprising thing is that this mailbox doesn't get nearly as much spam as the next two to.
4. The fourth mailbox is the moderator address for a mailing list I run. Unfortunately, I can't hide this one, since non-subscribers may need it if they have a problem subscribing. It gets spammed extensively. Typically about 40-80 spams a week.
5. Finally, there's my work mailbox. Due to the nature of my job, I must frequently post messages to IETF working group mailing lists with this address, and those lists are mirrored to many web sites. These lists are the only public places that I ever use this address, and the company directory is not accessible to the outside world. This account typically gets 30-60 spams a day.

On the plus side, ever since Mozilla version 1.3 came out, it hasn't bothered me nearly as much. Current Mozilla releases have a spam filter that learns by example. You click a button to tag spam as "junk" and Mozilla constructs its own filters. If it guesses wrong, you click the button to tag legitimate mail as "not junk". After about two weeks of training, it becomes very accurate. I recently returned to work after a week's vacation to find about 210 spams in my mailbox - Mozilla correctly filtered 200 of them into a junk-mail folder with no false positives.

-- David

I would love to have something like a "stringent" mode while developing web pages (ala browser producer error instead of trying to render the html).

I have my local Apache configured to send .html files as application/xhtml+xml so that I know my XHTML files are well formed since Mozilla/Phoenix throw errors if they are not.

It was April 12, 1994, before e-mail even existed in its current form.

Yes. With an infinite number of universes, there are an infinite number of you typing the code. Most of you will get it right and the computer will average the correct answer for you. So there, an infinite number of monkeys CAN write Shakespere, GUIs or anything else they please. No, no, no. Haven't you heard of the The Infinite Monkey Protocol Suite (IMPS) which proves you wrong?

http://www.ietf.org/rfc/rfc3514.txt

I wonder how an evil bit would affect the pigeon.

Here

Also note that it's actually based on the ideas initially developed by HTCPCP protocol, which just turned 5 years.

Note that any single IPv4 address can be used to claim a /48 -- that's 80 bits of address space -- of IPv6 address space by sticking 2002: in front of it, e.g. 192.0.2.69 -> 2002:c000:0245::/48. This is called 6to4; see RFC 3056.

You haven't read the addendum to rfc1149 have you?

This answers how TMDA deals with this problem. I don't know how other challenge/response email systems deal with it.

There is an IETF draft which describes how automatic, machine generated responses are supposed to be formatted, so that they can be easily identified as such. The primary author of TMDA (Jason Mastaler) has, I believe, incorporated all of the recommendations of that draft which are applicable to TMDA. So, if other automatic response systems (like TMDA) are also following the recommendations of that draft, then all of these auto responders should be able to interract.

All right! RFC3251 over 802.11b!

1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
sign (-), and period (.). Note that periods are only allowed when
they serve to delimit components of "domain style names". (See
RFC-921, "Domain Name System Implementation Schedule", for
background). No blank or space characters are permitted as part of a
name. No distinction is made between upper and lower case. The first
character must be an alpha character. The last character must not be
a minus sign or period. A host which serves as a GATEWAY should have
"-GATEWAY" or "-GW" as part of its name. Hosts which do not serve as
Internet gateways should not use "-GATEWAY" and "-GW" as part of
their names. A host which is a TAC should have "-TAC" as the last
part of its host name, if it is a DoD host. Single character names
or nicknames are not allowed.

If you, like me, are tired of having to manually deliver documents or other items within your office building, and if your building has high ceilings, good lighting, and minimal air currents, then you will inevitably reach the same conclusion I have: An automatic helium blimp delivery service.

nope. rfc 1149, "A Standard for the Transmission of IP Datagrams on Avian Carriers"

same dependability as the blimp though: not very dependable.

so has this guy written the rfc for the intraoffice blimp protocol yet? no!? what kind of nerd does he think he is! ;-P

Ok. I'm not an American and I don't particularly care one way or another about what the guy claimed. While the quote does make it sound like he's taking credit for creating the Internet, it's obviously just a poor choice of wording on his part. For what it's worth, Vint Cerf had this to say on the whole issue, which does support Al Gore's (poorly worded) assertion.

In all fairness, MS had it first and the OSS people adopted it. (IIRC - I may be wrong about this.)
In fact, it's one of two innovations that I respect from the MS folks - this and ODBC.

You're wrong about this - it was part of Tim Berners Lee's original proposal for HTTP, and the RFC is cosigned by authors from Microsoft, UC Irvine, Netscape and Novell.

Now if we can just get an implementation of the Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)...