Slashdot Log In
New Mail RFCs Released
Posted by
timothy
on Wed Apr 25, 2001 10:49 AM
from the sequels-are-judged-harshly dept.
from the sequels-are-judged-harshly dept.
Anonymvs Cowardvs writes "Well, it looks like after their 20-year reign, RFCs
821
(SMTP) and
822
(mail message format) are history. The replacements, RFCs
2821
and
2822
are available now (2822 was just released). Apparently they
reserved the numbers, no cosmic coincidence here."(Read on for more.)
"It's weird. Both 821 and 822 looooong predate my time on the Internet, and you sort of get used to them being as if written in stone. Doesn't look like the changes were too radical -- mostly just catching them up to current practice -- but that's a lot of text that I haven't got through yet and there's surely some gotchas in there. Does your mail client or server (or netnews client, since they use the message format) comply?
And this is the first time that Jon Postel's name has seemed conspicuously absent to me..."
This discussion has been archived.
No new comments can be posted.
New Mail RFCs Released
|
Log In/Create an Account
| Top
| 196 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Re:Don't blame sendmail (for once) (Score:3)
How about protocol that accesses mailboxes, allows for accessing and otherwise managing them, retrieving and deleting messages, regardless of the particular format in which they are stored... A protocol that supports extensions through a simple capability negotiation framework...
Sounds like IMAP to me. No, IMAP as is isn't perfect. So let's get cracking on IMAP5, shall we?
--
Re:Why the wasted time and energy? (Score:3)
Not sure what you're smoking, but FTP is considerably more efficient for data transfer than HTTP. (Just try timing downloads of something like, say GNOME using both FTP and HTTP - you'l find that FTP will almost always win...) In fact, it's generally acknowledged among protocol jocks that HTTP is one of the major things limiting what we can do in the future. It's a horrible protocol, and it's a real shame it got so widely used before it got fixed. Have a look at Marshall Rose's BXXP (a.k.a. BEEP) protocol for an idea of how a general purpose replacement for something like HTTP should work.
BTW: Only a few of us are old enough (well in Internet time, anyway) to remember this, but there was a very good reason that FTP was designed to require the creation and destruction of a TCP connection for each file transferred: The DoD realized (wisely) that it was very important to the long-term viability of the ARPAnet/Internet to build code that was good at creating and destroying TCP connections. FTP is intentionally designed the way it is so that it would force the TCP stacks to mature much faster than they would have otherwise...
Re:Line Length (Score:3)
Oh, a little while back. However... when was the last time you read a magazine with wider lines than that? Most publishers know that long lines of text makes it harder for the average person to read. It's one of the big reasons that most newspapers and magazines break stories up into columns instead of splaying them accross the whole width of a page. (and one of the big failings of a large number of websites)
Deprecated Features of RFC 821 (Score:3)
A few features of RFC 821 have proven to be problematic and SHOULD
NOT be used in Internet mail.
F.1 TURN
This command, described in RFC 821, raises important security issues
since, in the absence of strong authentication of the host requesting
that the client and server switch roles, it can easily be used to
divert mail from its correct destination. Its use is deprecated;
SMTP systems SHOULD NOT use it unless the server can authenticate the
client.
F.2 Source Routing
RFC 821 utilized the concept of explicit source routing to get mail
from one host to another via a series of relays. The requirement to
utilize source routes in regular mail traffic was eliminated by the
introduction of the domain name system "MX" record and the last
significant justification for them was eliminated by the
introduction, in RFC 1123, of a clear requirement that addresses
following an "@" must all be fully-qualified domain names.
Consequently, the only remaining justifications for the use of source
routes are support for very old SMTP clients or MUAs and in mail
system debugging. They can, however, still be useful in the latter
circumstance and for routing mail around serious, but temporary,
problems such as problems with the relevant DNS records.
SMTP servers MUST continue to accept source route syntax as specified
in the main body of this document and in RFC 1123. They MAY, if
necessary, ignore the routes and utilize only the target domain in
the address. If they do utilize the source route, the message MUST
be sent to the first domain shown in the address. In particular, a
server MUST NOT guess at shortcuts within the source route.
Clients SHOULD NOT utilize explicit source routing except under
unusual circumstances, such as debugging or potentially relaying
around firewall or mail system configuration errors.
F.3 HELO
As discussed in sections 3.1 and 4.1.1, EHLO is strongly preferred to
HELO when the server will accept the former. Servers must continue
to accept and process HELO in order to support older clients.
F.4 #-literals
RFC 821 provided for specifying an Internet address as a decimal
integer host number prefixed by a pound sign, "#". In practice, that
form has been obsolete since the introduction of TCP/IP. It is
deprecated and MUST NOT be used.
F.5 Dates and Years
When dates are inserted into messages by SMTP clients or servers
(e.g., in trace fields), four-digit years MUST BE used. Two-digit
years are deprecated; three-digit years were never permitted in the
Internet mail system.
F.6 Sending versus Mailing
In addition to specifying a mechanism for delivering messages to
user's mailboxes, RFC 821 provided additional, optional, commands to
deliver messages directly to the user's terminal screen. These
commands (SEND, SAML, SOML) were rarely implemented, and changes in
workstation technology and the introduction of other protocols may
have rendered them obsolete even where they are implemented.
Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers
MAY implement them. If they are implemented by servers, the
implementation model specified in RFC 821 MUST be used and the
command names MUST be published in the response to the EHLO command.
not to burst anyone's bubble... (Score:3)
Both are on www.faqs.org (Score:3)
2822 is here [faqs.org].
-- fencepost
Re:It's about damned time. (Score:3)
While you may be right, what's the use of a "standard" that changes every (short enough time period to track the state of the art)? In an ideal world, the point of standards is that they change very slowly so that all applications can adhere to the baseline features and behaviors delineated in the standard.
The politics surrounding standards processes now is bad enough. Imagine what it would be like with a new standard coming down the pipe every 6 months? A new standard that, if your corporation can influence it to use YourThing2000's features instead of TheirThing2000's features, will let you bash the competitor's products for the next release cycle...
--
News for geeks in Austin: www.geekaustin.org [geekaustin.org]
Winmail.dat? Not a problem! (Score:3)
winmail.dat...when are we going to get rid of it?
I spent a half-day looking for information about winmail.dat and found it. As a result, I now have a little tool that picks apart winmail.dat files. If moderators show interest by modding up this post, I'll even make it available under the GNU license.
I have several clients who send me crap in winmail.dat, so I'm glad I have the tool.
Re:Why the wasted time and energy? (Score:4)
FTP requires two separate connections for a data transfer, HTTP requires only one. Packet for packet there is no circumstance in which FTP does not require more packets than HTTP.
There are many inefficient HTTP servers arround, mainly those that try to do intelligent processing of some sort on the content. Also HTTP servers are usually designed to handle lots of requests for small chunks of data rather than infrequent requests for big blocks at a time. Equally comparing a GUI based HTTP client against a line mode based FTP client is ridiculous. Use a good line mode HTTP client and it is much faster than FTP.
Protocol efficiency has nothing to do with implementation efficiency. HTTP is the more efficient protocol.
There are many 'protocol jocks' who think they could have done better. Many are full of it. I don't know anyone seriously suggesting FTP as a design exemplar who has actually coded it (as I have BTW).
BEEP and HTTP-NG address a set of problems that simply do not exist in the FTP world. There is no reason to multiplex sessions onto a single conection for file transfer. The processing overhead of HTTP ASCII headers is common to most IETF protocols and is negligible.
FTP is intentionally designed the way it is so that it would force the TCP stacks to mature much faster than they would have otherwise...
Opening and closing TCP connections has a dramatic negative impact on performance. Each time a TCP connection is opened the van Jackobssen slow start begins from scratch. That is the limiting factor for transfer. Ever wondered why when transferring files on a broadband conection the transfer speed continues to accellerate for 10 to 15 seconds?
I don't think the story is true by the way. It was simply a joke told round the IETF.
/.ed (Score:5)
sigh.
Be conservative in what you send and liberal in what you receieve.