Slashdot Mirror

There is a long, long tradition for RFCs to be issued on 1-April which are not to be taken so seriously (e.g.: Telnet Randomly Lose (748) and Subliminal Message (1097) options). They've occasionally shown up on implementation checklists: this can been interpreted by the vendor's support departments that a potential client may need additional support.

Some are intended to be taken seriously, but authors have been known to request pubilication to be held for a few days to prevent confusion (not that there aren't some that need this distinction).

There is a long, long tradition for RFCs to be issued on 1-April which are not to be taken so seriously (e.g.: Telnet Randomly Lose (748) and Subliminal Message (1097) options). They've occasionally shown up on implementation checklists: this can been interpreted by the vendor's support departments that a potential client may need additional support.

Some are intended to be taken seriously, but authors have been known to request pubilication to be held for a few days to prevent confusion (not that there aren't some that need this distinction).

You can solve the constant connection requirement by using CPIP to connect to the Internet.

RFC 2549: IP over Avian Carriers with Quality of Service

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

Do you mean the Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)?

Ain't that the truth.

RFC1149 was updated by RFC2549 in 1999.

Yes, but is there an RFC for IP-over-jet?

the relevant rfc

Incorrect. That would be an absolute killer for a patent as an example of pubically accessable prior art. I can't think of anything better as an example of prior art, except perhaps RFC 799 published in 1981. Of course, I am not an attorney, your milage may vary, contents may have settled in shipping.

Too bad nobody agrees on how MD5 should be calculated.

Wow, really, you know, someone should like, write an RFC for it or something, then maybe they could all agree!

Read some RFCs.

I have. In particular, I have read RFC 1918.

Hmm... So if we combine this with the Transmission of IP Datagrams on Avian Carriers...

I hope they had the foresight to make it compatible with RFC 3514.

Someone like me?

You read my message with blinders on. I noted this exact problem and said that it was unacceptable to bounce messages for this reason. It takes a peculiar set of circumstances for a virus email to bounce because of me - the virus sending it through an intermediary SMTP server (which I think only happens if there's a transparent SMTP proxy; quite rare) which doesn't catch the virus itself, and then bounces the message on 5xx failure sending. And those rare ones do not all flood the same person, as the virus selects random addresses to forge. So I think this is acceptable.

You're complaining to the wrong person. Go talk to one of those antivirus companies that consistently send worthless replies like "you sent us this exact virus, which we know forges senders."

Btw: I thought that it contradicts the SMTP standard to reject messages after the DATA portion

It violates a SHOULD in RFC-821 for it to fail under these circumstances:

The DATA command should fail only if the mail transaction was incomplete (for example, no recipients), or if resources are not available.

...but as the hyperlink notes, there can be valid reasons for not following a SHOULD. Besides, RFC-2821 (which obsoletes RFC-821) explicitly allows this case:

or if the server determines that the message should be rejected for policy or other reasons.

It's standard practice to do this with Postfix, and presumably with other mailers.

this would mean that the direct-connecting clients could do anything when being told that the message was rejected -- including silently dropping it -- and still be standards compliant!

Absolutely not. Even with a strict interpretation of RFC 821, they have to allow for the case where the receiving MTA does not have enough available resources to store the message.

Internet Standard #1 (currently RFC-3600 - November 2003) lists TCP as being Standard #7, which is outlined in RFC-793. RFC-793 was published in September 1981. In other words, we are still using the 1981 edition of TCP. RFC-793 contains the following note from Jon Postel:

This document is based on six earlier editions of the ARPA Internet Protocol
Specification, and the present text draws heavily from them.

Thus, Dr. Rhee is a little bit off in his assesment.

Internet Standard #1 (currently RFC-3600 - November 2003) lists TCP as being Standard #7, which is outlined in RFC-793. RFC-793 was published in September 1981. In other words, we are still using the 1981 edition of TCP. RFC-793 contains the following note from Jon Postel:

This document is based on six earlier editions of the ARPA Internet Protocol
Specification, and the present text draws heavily from them.

Thus, Dr. Rhee is a little bit off in his assesment.

What's happening to slashdotters? Have we all turned into scared whiners a la "nothing can be done, let's all weep in unison"? That idea above isn't mine (or this guy's either, I've heard it before), but it's not so bad.

This "simple yet elegant" layer would require far more work than the underlying SMTP servers do.

Exagerration. It is much work and it's not going to be here this year, but I think it will be here.

How exactly -- no handwaving, no fluff -- do you propose to implement this?

One email is defined as "incoming SMTP session". Attache some unique ID to it - say, "SMTP-server-IP.date.time.message-digest". Or anything else. There are lots of possibilities here.

You need to either tie bank account details to email account information, or maintain a separate "online only" bank.

Cavalry's incoming: http://www.ietf.org/html.charters/trade-charter.ht ml

You need to find some unforagable, unbreakable, untappable method of identifying individual emails to make your one penny claim.

Digital certificates + public cryptography guys have already done most of hard work here.

Say, you sign your claim (with your private key, so that it can be verified using your public key).

You need to retrofit all existing mail clients to keep track of this new header (because Message-IDs can be forged).

1. It can be done at server level, transparent to users (why should they be bothered with such stuff). Regarding problem "no more 'free to receive' mailing lists and email": make webpage on their smtp server for users where they indicate 'if they send me email with 1 cent and it gets verified positive as belonging to this mailing list/company newsletter/whatever give it back'. Users by signing up send this 1 cent to populate 'sending budget'. By unsubscribing they get this 1 cent back (obviously this requires trusted third party, but you need it anyway -- online bank -- for handling those cents). Or wait - they can even give this 1 cent into "custody", lasting as long as they are subscribed to the list.

2. It actually could be used to enhance email capabilities - say, for increasing email priority or for "consulting via email".

3. Finally, once this infrastructure is in place, there will be a way to unambigously identify emails, parties and servers - so some, like coworkers or business partners could set policy like "make exchanges fulfilling requirements of this ruleset free of charge in both directions if other parties agree to the same conditions". Again, there's a lot of exciting opportunities here.

This scheme is gigantic and unworkable. Prove me wrong, with details.

Quit whining. ;-)

On more serious note: the pieces to implement this are evolving independently anyway - OITP, financial XML, PKIs, online banks. At some point they just HAVE to become mature enough to use them in this way - and then it will be just a matter of working out software to glue it all together. I'm sure things like avamisd_new will include interfaces to it - it already has interfaces to spam scanners and antivirus scanners, why not this?

About unfeasibility of micropayments: yes, this guy has good arguments; but the issue is complex and the "metered services" are not simply going to die and be replaced by flat rate. Real world example are SMS messages - they're paid "per message" and still immensely popular (at least here in Europe).
One could even think of connecting this sort of service to flat rate somehow - say, an online bank that includes this sort of verification service as gratis in its monthly fee for online account, i.e. it exchanges "variable risk" from email-dealing for "fixed income". The model is already working in mortgages for real-estate, so I guess it

With QoS.

Amen to that - PSTN was never secure. VoIP can be MUCH more secure. Starting with the ability to control who calls you, where they come from, and whether or not they are impersonating someone else. Even PSTN CallerID is trivially spoofable. What privacy? Get OE. Start with encrypting everything - check out http://www.ietf.org/internet-drafts/draft-richards on-ipsec-opportunistic-13.txt and http://www.freeswan.org/freeswan_trees/freeswan-2. 05/doc/quickstart.html A future revision will explain how to do it through NATs. What? Your VoIP box doesn't support OE? Tell your vendor to fix it, or put it behind a Linux firewall.

Thanks for the lesson.

--Mike--

Such as IP over "Avian Carriers" :)

I think we should implement RFC 3514 and end all security problems once and for all. ;)

Although there is no perfect solution I have found that STUN works quite well. It suffers most from the fact that there doesn't seem to be a standard for NAT implementation that is used by the vendors. I have used Vovida's free STUN Server and have only had some issues with LinkSys products. Unfortunately it is required to run on a public address. Vovida provides 2 public STUN Servers for people to use: The IP address of the STUN servers are: 128.107.250.38 128.107.250.39 I have not tried these and they may have changed. Maybe someone can give them a try and report back how well they work.

I wanted to provide a "sample implementation" link as a supplement to your post, but I can only find the first implementation of the more primitive predecessor, rfc1149.

Yes, SSLv3/TLSv1 does have a NULL cipher suite, which is authentication only, and there is also support for Anonymous Diffie-Hellman key exchange (which doesn't require authentication). (See RFC 2246) But browsers don't use it. No browser, even going back to Netscape 2.0 supported NULL or ADH by default. If you wanted these cipher suites, you have to explicitly turn them on.

Go ahead, try it. Take a test Apache/mod_ssl server and change the SSLCipherSuite config line to:

SSLCipherSuite ADH:NULL

and restart the server. Now try to connect to it.

In IE, you'll get the generic "The page cannot be displayed" error. In Mozilla/Firefox, you'll get "Firefox and cannot communicate securely because they have no common encryption algorithms."

I welcome a real-world example of this "attack" that will actually work on a default-configured web browser.

I warned them Avian Carriers couldn't survive in a vacuum.

Yes you can.

There are too many protocols and applications that incorporate their own (poor) security mechanisms. What we should be aiming for is *simplicity*, not redundancy.

Natch. IP address range for spammers is not enough.
Insist that spammers turn on the Evil bit - RFC 3514.

(More seriously - RFC 3675, ".sex considered dangerous", gives a little more thinking about why this is a Bad Idea. This is NOT an Internet standard, but it's a well written document.)

I've been on both sides here. I've done the OpenLDAP database of users, with OS X desktops an Samba fileservers, Sendmail / QPopper / IMAP mail setups for a few thousand users. I've also done the Win2k3 servers with AD and Exchange, and WinXP desktops, again for a few thousand users. The bottom line is that they both serve the same roles: user management, mail, fileserving.


You've got a great point, there. The MS way is tightly integrated, and that really shows off in the provisioning/de-provisioning functions. You'll never get that kind of tight integration in the Open Source world, but you can get close with "standards". Sadly, standards for leveraging LDAP for mail and file service lag way behind. For account provisioning, we have the experimental RFC 2307 for storing NIS information as objectClass posixAccount. There are only a couple of expired Internet-Drafts for mail. For file servers, there's basically nothing.

All this is not to say that standardization is not the way to go, it's just that there's still a ways to go. And the people who know how to make this sort of solution work -- people with lots of practical, large-scale, real-world experience -- are just not the people working on "standards."

:w

SPF is already a IETF draft, the first stage towards RFC-style standardisation.

It seems the author of the article wished to place emphasis on certain words in the article. I contend that he went about achieving his end with the incorrect means.

HTML has provided authors with a means of deliniating emphasized content since version 2.0 and this means has not been depricated since.

The following is taken from RFC 1866:

5.7.1.3. Emphasis: EM

The <EM> element indicates an emphasized phrase, typically
rendered as italics. For example:

A singular subject <em>always</em> takes a singular verb.

This is the best way for authors to indicate emphasized content because user agents may then style the content according to a stylesheet. For example, a user agent may perform a text transform to all capitals (which would achieve the effect he created), boldface the content, or raise the volume of the content (for an aural browser).

It should be noted that Slashdot is written in accordance with the HTML 3.2 Reccomendation from the W3. Comments, since they are displayed under this doctype, should follow spec.

Yeah, I've had bad experiences with Computers in general, sticking to pen and paper for years to come.

( This was posted using protocols described in RFC 1149 )

Hamsters are probably less efficient than Carrier Pigeons, too.

After creating the HamsterMIDI an automated process could upload the files to the internet via the RFC 1149 protocol.

I for one would love to see this. Because the day hamsters and pigeons can create and distribute music, is [insert RIAA flamebait here]..

Sure you can push lossless uncompressed HDTV over public IP. Run UDP, and put a sequence number and timestamp in each packet so the receiver can reorder. Doesn't require any changes to the routers.

There's even a standard for it, and we ran a demo at the SuperComputing 2001 conference between the University of Washington in Seattle and the conference site in Denver (that used custom end system hardware - we also have a slightly lower quality system that runs on Linux PCs).

I would suggest designing for the minimum browser, as many people may be connecting using modems, carrier pigeons, or other low bandwidth connections. The FSF homepage is a good example.

Actually its called the Pigeon protocol!

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

Heh, that's nothing for high ping times. =^_^=

#1: Verisign can fake that, though. They can create their own private key and replace yours with it temporarily. Either way, I have to trust them quite a lot.

This is only a trust issue for SSL clients, not for an ssl server.


at what point do you draw the line between 'ssl' and 'not ssl'?

SSL is a specific protocol, not a library. It has been standardized by the IETF in RFC 2246. If the protocol described in that document is implemented, it may properly be described as SSL or TLS. SSH, of course, does not implement that protocol although many of its crypto operations are the same.

RFC3251 - Electricity over IP

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

Now THAT'S a beast I would like to see implemented!

I love it when someone quotes an RFC, but doesn't realize that it has been superceded by a more recent RFC.

The practice of sending a username and password is not reccomended, but it is defined in relevant RFC and is explicitly allowed in the URL syntax. Microsoft will be breaking the standard if they disallow this format.

"...United Nations Human Rights code for multinationals which says businesses should 'seek to ensure..." The UNHR code says businesses SHOULD seek to ensure their products will not abuse human rights. It doesn't say is they HAVE TO.

So what you're claiming is that what Microsoft is doing is (for once) RFC 2119 compliant!:

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

thats the protocol behind the only tried and proven open IM platform, Jabber

We have already had an open IM, APEX. but nobody remember it...

As most of you know, it's been done already for ages, using pigeons instead of motorbikes. The IP-over-Pigeons technology even has itw own RFC, which of course predates the implementation. Talk about a mature technology !

do they have redundancy plan. . .

Would you believe CPIP?

RFC1149

KFG

SIP (Session Initiation Protocol) is a Protocol aiming at just session initiation and teardown.
There are loads of extensions to this protocol aimed specifically at instant messaging. SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) for one. There is presently an IETF working group working toward getting it standardized, and their efforts can be tracked at their website There are also intertwined extensions describing multimedia messaging sessions (SDP - Session Description Protocol).
Although, there are no RFC's out there yet, there are loads of well thought of Internet drafts to spend some quality time on.

"They'll extensible this to death"

Actually they won't. MS has a competing standard called SIMPLE.

I guess you aren't concerned about QoS, then (RFC 2549)