Slashdot Mirror
New Mail RFCs Released
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..."
qmail has an extremely restrictive license which is quite bothersome. My favourite Sendmail killer is Exim; others prefer Postfix.
--
Xenu loves you!
There are lots of features we would all like to see added to many specs. Some of them would solve narrow problems quite neatly, others would be of broad applicability.
The question becomes how extensive should a specification be? Should mail be extended to handling response-forms? What about including full forms-routing? Do we include conditionials & alternates?
While we're at it how about extending the specification fields for email, adding more sender & reciever information, more meta-information, perhaps going to an XML-structure?
Then there's the old bugaboo of undeliverable email. How about putting in some standards for things like "no longer here but we'll forward anyway" or "here's their new address effective a/b/c)" or even "this rotten bastard is no longer associated with our repectable firm and if you've any sense you'll keep this freak away from small children & house pets!"
How far should basic principals go in servicing every situation? Frankly I think we should stick to a minimum effective specification & leave any extensions out in seperate documents where relevant applications can take advantage of them.
My Internet Toaster doesn't need forms to fill, why ask it to support these features?
Again, lots of good stuff out there but lets try to keep the fundamental documentation clear & universal, keep dedicated-use stuff off in it's own areas.
Perhaps you should start drawing up an RFC for what you want. They're open to everyone & if it's truly useful it'll likely get adopted.
I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
2821 obsoletes anything which is referenced in both 821 and 2821. However, in the case that you are referring to parts of 821 and are not referenced in 2821, then 821 should be concodered current.
I think they need to release 3821 to clarify the clarifications.....
This space for rent. Call 1-800-STEAK4U
Unless I'm mistaken, 821 and 822 were never OFFICIAL standards, just accepted as standard. There are actually very few "Official Standards" that come out of the RFC's. Most just live their life out in peace and never get accepted.
This space for rent. Call 1-800-STEAK4U
I'm just wondering if Sendmail will finally stop putting in the > character in front of every occurance of the word "From" at the start of a line...
--
You know, you gotta get up real early if you want to get outta bed... (Groucho Marx)
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
See page 79 of Unix-Haters Handbook for a discussion on it.
Page 81:
--
You know, you gotta get up real early if you want to get outta bed... (Groucho Marx)
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
You can just run the imapd executable and talk to it using stdin/stdout. Most implementations will detect this and skip the user/password and enter the PREAUTH state immediately. This way you can access any mailbox that is accessible via the filesystem (NFS, SMB, etc).
-
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
The first RFC describing HTTP/1.1 was RFC2068. After an arduous revision process, the next version was offered number 2608. It was decided that the revision process was complicated enough without having to worry about stupid typos having semantic significance, so they held out for 2616.
> No-one has yet managed to come up with an MUA which highly abstracts the storage of email and supports "plugings" for mbox, IMAP, Maildir, MMDF, some database or other, etc.
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?
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
While I was a firm believer of reply-to to be used by mailing lists because of how RFC822 was worded (sender sets reply-to, the list is the sender) 2822 states it much differently which leaves no room for different interpretations. The /author/ sets the reply-to.
:/
However, I am sad to see that the mailing list issue simply has not been addressed. They have the perfect opportunity to formalize a way to for mailing lists to indicate how to respond to the list versus to the individual and they have not, from my brief skimming of the document, completely failed to do so.
-- Grey d'Miyu, not just another pretty color.
One of the first things that the RFC says is, "It consolidates, updates and clarifies, but doesn't add new or change existing functionality".
Unfortunately, that is not the case here. It does indeed change existing functionality, in that RFC 821 allowed use of a CNAME in a HELO, and this specifically excludes that in an EHLO.
-
Exactly, only a few comments and the IETF is already slashdotted! So, in the best whoring fashion:
putting four direct links to that ftp on the front page is just horrible.
please view these rfcs at www.faqs.org.
complex
I'm not sure what you are getting at about John's name not being on the RFC.. he passed away recently. And sadly enough, we don't have a way for him to work his magic from beyond the grave (It would be nice if we did though)
Where did you get this from, the RFC does support IPv6 but it also supports IPv4, and in fact I quote "SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel."
Oh so what your saying is that "sendmail" or other has to support IPv6 even if it isn't actually used. Is it not supported now?? I havn't really kept up with things.
I'll give up my ADM-3A when you pry my cold dead fingers from its vi-labelled keyboard... :-)
(Really, the thing has little vi cursor arrows on the h, j, k, and l keys, among some other interesting stuff. Surely you wouldn't want me to give this sort of clearly advanced technology up in favor of Windows, would you?
"The future's good and the present is nothing to sneeze at." - Roblimo's last
FTP has been effectively replaced by HTTP which is more efficient than FTP for any transfer - with the sole exception of the rarely used ability to initiate a third party transfer.
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...
"The future's good and the present is nothing to sneeze at." - Roblimo's last
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)
F. Deprecated Features of RFC 821
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.
Go not unto/. for advice, for you will be told both yea and nay (but have nothing to do with the question)
The >From idiocy is an artifact of the craptacular Unix mbox format, not sendmail. Remember, not /everthing/ horrible about electronic mail can be laid at the feet of sendmail.
The ">" is being used as an escape character. Since mbox format uses lines starting with "From " as message deliminators.
Problem is that mbox format (or more likely mbox with some kind of index file) is about the closest thing we have to a universal mail storeage format. Even though there are other formats, such as either MMDF (uses strings of ^A as message deliminators) or Maildir (stores each message in a separate file.
Even non unix programs support mbox, you can't even rely on unix programs supporting MMDF or Maildir.
No-one has yet managed to come up with an MUA which highly abstracts the storage of email and supports "plugings" for mbox, IMAP, Maildir, MMDF, some database or other, etc.
But Microsoft will decide to invent their own standard that they say is better but and not support the new standard.
Not sure if it was Microsoft who came up with the concept of the "limited SMTP client" i.e. one which must use a relay. Even though such programs are almost universal with Windows.
Interestingly the latest RFC whilst acknowlaging the existance of such software calls the behaviour "non ideal".
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?
IMAP has a major problem. That is being over complex and redundant where email trivial accessable by a protocol such as NFS, SMB, NCP, etc or is even on a directly connected disk drive.
AFAIK there is no way to get IMAP to work without both end user configuration and entering storing passwords. Maybe ok for the dialup home user, but something to avoid on corporate LANs.
Gnus does. Support the idea of pluggable backends, that is.
At least a start, does it also support preventing end user fiddling?
The only insanely complex software involved with the whole mail system is sendmail - And god only knows why sendmail has to be the world's well-known "most complex program ever written". It's a nightmare.
That's because sendmail supports quite a few other protocols in addition to SMTP.
It bothers me that they spend more time on SMTP. SMTP and FTP combined are probably two of the hardest protocols to implement correctly, as is evinced by the numerous vulnerabilities on almost all servers designed for either protocol.
Actually SMTP is fairly trivial to implement (especially the limited, i.e. crippled form common in many desktop MUAs). How many vulnerabilities are found in MTA's which exclusivly implement SMTP?
Any single transfer, yes. How about "mget *-src.tar.gz"?
Let alone how would you do mput with HTTP. Even with downloading something equivalent to reget is unusual with HTTP.
The authors are trying to balance brevity (shorter documents are more likely to be fully read and understood) and exhaustiveness.
RFC821 is obsolete and should not be the primary reference.
However, if you're using some obscure feature of 821, it's included by reference in 2821 and shouldn't be considered <i>prima facie</i> non-compliance.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Tom Swiss | the infamous tms | http://www.infamous.net/
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Oh, man, that's a *wet* dream ... ;)
I am quite civilized, and I should be brought a beer immediately. -- Bruce Sterling
When Microsoft stops using proprietary formats.
Translation: Never.
-- You can't idiot-proof anything, because they're always coming out with better idiots.
One of the first things that the RFC says is, "It consolidates, updates and clarifies, but doesn't add new or change existing functionality". This is not some new revolutionary mail transfer format that's going to leave existing infrastructure in the dust; its a clarification of the old system that takes into account some of the changes that have occured in the way that people use and look at e-mail. I don't think that users are going to see any change because of this new RFC, except MAYBE fewer incompatabilities with attatchments or something if client developers everywhere find they understand mail better because of this RFC.
req: HELLO
res: RUSPAM
req: YES
res: GOFUCKYOURSELF
req: OKSHOULDIKILLTHESENDER
res: YES
req: OKCRASHINGSENDERBOX
[...connection closed...]
Someone you trust is one of us.
2821 is here,
2822 is here.
-- fencepost
fencepost
just a little off
Excellent... this is probably the biggest benefit. If vendors want to be up to snuff and support the new RFC, they have to have IPv6 support. So this is an extra push of getting rid of crusty old IPv4. I mean, what better use of IPV6 than forwarding chain letters intellegently?
Black holes are where the Matrix raised SIGFPE
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
News for Geeks in Austin, TX
Well, once and for all it is indisputable that bare lfs in a message body are forbidden.
In particular, LSMTP until recently allowed them. In fact me and several employees of L-Soft got into a pissing match over the matter when a large mailing list started flooding our servers with something on the order of 4 million SMTP connections a day using their software. Their argument was that, since it was only an Internet Draft and the RFCs only RECOMMENDED bare LFs be filtered, they were perfectly justified in not fixing the issue.
Only if you dont know how to configure sendmail. It only does this if the mailer definition line in sendmail.cf (the line beginning with "M") contains the "E" flag.
From the Sendmail Installation and Operation guide (aka ops.ps), version 8.103, p08-38:
E Escape lines beginning with "From" in the message with a '>' sign.
Write it yourself, that's what open source is all about...
Keep in mind, too. You can't just chuck everything just because a new scheme is better. You need to consider reverse compatibility or you're going to break everything.
Now if you want XMTP, make it; you might even find people interested in helping out. But don't expect to replace the system that's already in there -- you're talking about displacing something as basic to net traffic as, I don't know, FTP or HTTP. The net is big, and it's a long way to go to create a competing standard.
/Brian
IPv4 works fine as long as your four billion possible hosts are asssigned with no slack. But it's a bit hard to see how giving someone who needs a block of four IP addresses a full Class C address is really a good idea...
(Try living in New York or Boston for a while, and see what's happened to our phone system. It's very much the same phenomenon.)
/Brian
That's a bit sloppy, IMHO -- why not do a full 2821 with all the trimmings and then an informational abridged version?
/Brian
Won't Kill them, but at least will make them useful.
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.
Why not just send them an HTML formatted email with a form in it? Have it submit to an intranet site, and you can use server side scripting to store the input however you want.
Blasphemy, I know, but that's probably what's going to happen anyway. People won't just say "oh well, the RFC says we can't do this anymore, let's give up"; look at what happened to HTML, after all. This goes as much for RFCs as for anything else: trying to declare that "you must not do XYZ" when people want to do XYZ just doesn't work (unless you happen to be a dictator)--people will ignore you and do it anyway.
--
BACKNEXTFINISHCANCEL
FTP has been effectively replaced by HTTP which is more efficient than FTP for any transfer - with the sole exception of the rarely used ability to initiate a third party transfer.
Any single transfer, yes. How about "mget *-src.tar.gz"? And there are people who use that third-party transfer ability--just because you don't isn't enough reason to kill the protocol, unless you can come up with a better alternative.
--
BACKNEXTFINISHCANCEL
If you have a serial port, lots of 80-column terminals "support Windows," whatever the hell that means. But since you're obviously trolling people who were on what you call the WWW before you were out of diapers, you might already know that.
CEE5210S The signal SIGHUP was received.
If you thought I meant a serial port in your head, you're even thicker than I thought. But I suspect you're just being a piddly pedantic pain. You were trolling and are pissed because you got called on it, fess up.
CEE5210S The signal SIGHUP was received.
SMTP works. FTP has been effectively replaced by HTTP which is more efficient than FTP for any transfer - with the sole exception of the rarely used ability to initiate a third party transfer.
I have never heard of Internet Mail 2000 and having read the page I can't say I am impressed. I disagree with the premises stated, there is no link to any substantive information. Redoing everything from scratch just isn't an option. There are hundreds of one man bands with ideas that would be great if there was no established infrastructure.
The revision to RFC822 should eliminate most of the implementation difficulty of SMTP and many problems with NNTP.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
That is my pet peve as well, only in reverse I don't give a crap about your ability to read mail on a DEC Teletype made in 1964 you bought at a car boot sale. In other words go get yourself a client that can display text properly on your cruddy screen, don't expect the rest of the world to cope with your crappy software.
The automatic line wrapping is a pain, especially when you get forwarded mail. You end up getting posts with paragraphs where alternate lines have 78 characters and one word. It also screws up digital signatures
However trying to get people to rewrite text based mailers is probably futile at this point. People who are prepared to upgrade are probably already using HTML capable email clients.
HTML mail can be rendered to any device, including speech. Provided that is that the text is really HTML and not HTML plus one of the braindamaged and intrinsically scripting languages we never needed.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
Mod this chump down, kneejerk Microsoft flamming without cause should have a penalty. Save it for cases where they actually have done something bad.
Microsoft has recently re-engineered Exchange from the ground up so that it uses IETF messaging standards instead of the X.400 derrivatives it was originally designed arround.
Like every other X.400 vendor Microsoft modified X.400, for the simple reason that as specified X.400 did not work - even if you did have an OSI network stack.
Like every other vendor Microsoft also implemented a variant of SMTP, attempting to maximize compatibility with exisiting systems. The whole purpose of the DRUMS group was to take account of the fact that implementing 822 was not sufficient to guarantee interoperability. Microsoft has no vested interedt in having its mail systems fail to interoperate with those of competing vendors.
Of course Microsoft might add in a couple of proprietary extensions with additional functionality, but that is absolutely OK by IETF rules.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
The reason you make such ignorant statements is probably because your procmail filters out all mail with a clue as well.
There is no problem reading HTML on a VT100. If you use an obsolete mail client then that is your problem.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
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.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
Currently TLS for SMTP provides this functionality. It can be implemented using open-ssl which is distributable, and isn't patent encumbered as far as i understand it. sendmail and other MTAs support this with patches, but buggy implementations such as Microsoft's in exchange 5.5 hamper it's adoption (if you turn it on you currently can't communicate with Exchange servers). Other vendors have compatibility problems as well.
The new SMTP team would have done us all a great service if they had made TLS implementation mandatory in the new spec. This would have the effect of getting MTA's like sendmail to support it without serious hacking, and shame Microsoft into releasing a non-buggy implementation. The end result would be an ever increasing amount of email traffic sent across the wire, and in the end foil attempts at mass sniffing.
While I agree that SMIME and other end to end solutions offer better security, user based adoption will always be hard. point to point security still provides much better privacy for the masses, and is within our reach. But without a real push, will it be another ten years with our email the digital equivalent of postcards?
since we just /.ed the RFC editor site to hell, have a mirror of both
sigh.
Be conservative in what you send and liberal in what you receieve.