New Mail RFCs Released 196
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..."
Re:not to burst anyone's bubble... (Score:1)
Bastards! How in the world they expect to interoperate on the internet without supporting XML?
Victor
Re:Will Sendmail bother to listen? (Score:1)
qmail isn't Open Source (Score:2)
--
Re:/.ed (Score:1)
I'm sure everyone has their own favorite mirror, but I like x42.com [x42.com]'s RFCs. You can get these two at rfc2821.x42.com [x42.com] and rfc2822.x42.com [x42.com].
--Phil (x42.com even has anchors on the sections of the RFCs.)
RFC822's Epitaph (Score:1)
The people at RFC.net [rfc.net] have a link to An epitaph for RFC822 [warhead.org.uk] that turned up on their discussion mailing list.
--Phil (Sure it's MLP, but it's interesting MLP.)
Re:Competition (Score:1)
Besides, any money the government makes is EVENTUALLY (after 80% of it is flushed into the proverbial beurocracy bowl) spent on the people anyway.
I never thought I'd see the day... (Score:1)
they are only PROPOSED standard atm (Score:1)
sendmail (Score:1)
Innapropriate Extensions (Score:2)
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.
Obsolete or not (Score:2)
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.....
PROPOSED standard (Score:2)
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.
Re:PROPOSED standard (Score:2)
Disclaimer: This isn't a Your Wrong post, just a "but this is what the docs say" :)
Even that (RFC1869/STD10) buids on the SMTP protocol specified in RFC821. In fact, RFC1869 explicitly says it's an extension of RFC821, in no way supercedes RFC821, and should not break any RFC821 functionality. There really is no standard implenentation document for SMTP. RFC1869 refers to STD10 and RFC821 in the same breath, but the offcial references for STD, RFC, and such don't make that connection.
In fact, neither RFC821 nor RFC2821 are currently Historical, Best Practice, Proposed Standard, or anything other than just plain old RFC's
And just to be amazed at the longevity of the RFC: RFC1869/STD10 came almost 10 years after RFC821. Which wasn't updated until 10 years after that. And even then, it wasn't an update, but a clarification.
Will Sendmail bother to listen? (Score:2)
--
You know, you gotta get up real early if you want to get outta bed... (Groucho Marx)
Re:Don't blame sendmail (for once) (Score:2)
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)
Re:Amazing to think about... (Score:1)
Of course this new one will most likely cause some problems with new servers that don't follow directions correctly...
Re:is this important? (Score:1)
Why it will complicate it, cause you stress and worry since someone is bound to break it allong the way missinterpreting this.
I think its good the change the standards occasionally, and if it was well thought out and designed it will probably be a benifit to us all eventually. Once I have a chance to read them over I'll figure out if I'll even care...
Adapting to your natural surrondings is the sign of a insane geek gone past carring.
goatse.cx alert in above link (Score:1)
I know.... party pooper.
--
Re:PROPOSED standard (Score:1)
Both Proposed, Draft and (full) Standard documents are Internet standards, they are just at different "maturity levels".
The biggest reason why so many things remain at Proposed is that it's work to update them, and a lot of people don't see much benefit.
Re:IPV6 in SMTP (Score:1)
IMAP != IMAP over TCP (Score:2)
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).
-
Coincidental RFC numbers (Score:2)
Re:Coincidental RFC numbers (Score:2)
Revision numbers on the STD track would be nice though, but so long as people still reference RFC's directly and not STD's or FYI's, there doesn't seem to be a pressing need for it. The IETF still operates in pretty much ad-hoc fashion (submit an ID, get a room for your BOF next meeting, let the BOF tear it apart, whatever survives will stick)... and it still works.
--
Re:PROPOSED standard (Score:2)
--
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:A dream I had... (Score:1)
+OK Was it as good for you, as it was for me? (clean as a baby)
Just showing off fashionable fake replay
Re:Well, the reply-to argument is at rest... (Score:1)
Re:Well, the reply-to argument is at rest... (Score:1)
From: is clearly defined as the author of the message. In face here is the exact wording, "In all cases, the "From:" field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message." Since the mailing list generally doesn't belong to the author as a mailbox, From cannot be used.
Sender could be used but then what header would be used for the "owner" address? This has typically been what Sender was used for so error messages would return to the Sender. In doing so the error messages went to an address that might actually be able to do something about it or, at the very least, didn't spam the list. If sender becomes the list then the list propigates errors.
Well, the reply-to argument is at rest... (Score:2)
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.
Re:not to burst anyone's bubble... (Score:2)
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.
-
Re:Embedded Input Forms in Email (Score:1)
Re:Don't blame sendmail (for once) (Score:1)
Don't blame sendmail (for once) (Score:1)
Peace,
(jfb)
Re:Don't blame sendmail (for once) (Score:1)
Peace,
(jfb)
Re:It's about damned time. (Score:1)
I think Jon's name is absent because he's dead, and I doubt that he died of obsessing over new standards/advances. You were very poetic, though.
Why IPv6? (Score:1)
Lots of host addresses (wait until every cell phone gets an IP address)
Faster stacks (no really. 6 was not designed for a PDP-11 with no RAM).
IPSEC. Well, IPSEC for IPv4 was back ported
Auto Addressing on ethernet - dhcp becomes moot
Routers that don't SMOKE with the number of routes being run through them (you haven't run a multihomed router with BGP, have you?)
And much much more.
IPv4 met our needs for a while. NAT let us get around some of the address shortage problems (and introduced its own problems).
Now the REST OF THE WORLD wants in. China could use the whole v4 address space itself (ever wonder why so much of the work is coming from Asia? See KAME.net).
Just like TCP replaced NCP. Time moves on. We went from 256 hosts to an unlimited 32 bit address space. Next stop, 128bit.
Re:Competition (Score:1)
Bravery, Kindness, Clarity, Honesty, Compassion, Generosity
Re:better links... (Score:2)
Exactly, only a few comments and the IETF is already slashdotted! So, in the best whoring fashion:
better links... (Score:2)
please view these rfcs at www.faqs.org [faqs.org].
complex
John Postel (Score:2)
Re:Will Sendmail bother to listen? (Score:1)
If you want to stick with the "standard" standard, you can use the Content-Length: header, which removes the need to quote lines starting with From. Of course, not everything supports it.
Re:IPV6 in SMTP (Score:2)
Re:IPV6 in SMTP (Score:2)
Re:Line Length (Score:1)
I read Slashdot in a wide window. I read email in a 179x64 char xterm. I use the pointer to highlight the line I'm reading. This is like reading text on dead tree with a transparent straightedge; finding the next line is easy, plus it gives my mousing hand something to do.
Re:Line Length (Score:2)
(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?
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:But Microsoft will decide to invent their own.. (Score:1)
the body, if structured, is defined according to MIME [12]. The content is textual in nature, expressed using the US-ASCII repertoire [1].
and section 3.3:
SMTP systems SHOULD NOT reject messages based on perceived defects in the RFC 822 or MIME [12] message header or message body.
Thus, if Hotmail only sends HTML-formatted email, _your_ SMTP system NEEDS TO
Sendy
--
I used IE for this. I was expecting vi and Window Maker. IE sucks. (Note ESC)
Re:Well, the reply-to argument is at rest... (Score:1)
There is some discussion going about 'Reply-To munging'.
I found this in the Mailman "general/reply_goes_to_list" details help:
There are many reasons not to introduce or override the Reply-To: header. One is that some posters depend on their own Reply-To: settings to convey their valid return address. Another is that modifying Reply-To: makes it much more difficult to send private replies. See `Reply-To' Munging Considered Harmful [unicom.com] for a general discussion of this issue. See Reply-To Munging Considered Useful [metasystema.org] for a dissenting opinion.
I prefer _not_ to set the Reply-To header.
Sendy
Re:It's about damned time. (Score:1)
That's actually a good example, but not the way you seem to imply. Those working on HTML 3.0 took great pains to work with the industry (Netscape, Spyglass, et al). The industry kept contributing and promising that they would support it. Then once it was finallized, they said "Yes, that's nice. But we've decided to do our own thing"
In that case the standard was kept up and even made to give the boost needed by the industry. But the industry did a 180 and turned their backs. So, it's not that the standard lagging was the problem, but rather that the companies choosing to flout them was.
Re:Why? (Score:1)
You don't have to take that flexibility away, since it's been given. However, there are proper ways to do it. RFC 2046 clearly states regarding text/plain:
However, RFC 1896 defined text/enriched to achieve that auto-wrapping that you desire. Or your mail program could just use text/html.
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.
Re:Will Sendmail bother to listen? (Score:2)
The way mail is stored and the way mail is transmitted and displayed are rather different things. You might just as well argue that changing one file system to another will break things, because the data ends up aranged in a different way on the physical media.
Re:Don't blame sendmail (for once) (Score:2)
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.
Re:But Microsoft will decide to invent their own.. (Score:2)
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".
Re:Don't blame sendmail (for once) (Score:2)
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.
Re:Don't blame sendmail (for once) (Score:2)
At least a start, does it also support preventing end user fiddling?
Re:Amazing to think about... (Score:2)
That's because sendmail supports quite a few other protocols in addition to SMTP.
Re:Why the wasted time and energy? (Score:2)
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?
Re:[OT] Re:Why the wasted time and energy? (Score:2)
Let alone how would you do mput with HTTP. Even with downloading something equivalent to reget is unusual with HTTP.
Re:Coincidental RFC numbers (Score:2)
Re:Innapropriate Extensions (Score:2)
You can do this with 550 error codes. The text of the error message should be delivered back to the author.
Re:But Microsoft will decide to invent their own.. (Score:1)
Can't we just wait until they do something bad and THEN talk about it rather than pessimistically assume the worst and write about it in advance? You know, email has existed for a pretty long time now and people using Outlook can still communicate with the rest of the world just fine. Sure, Microsoft has a reputation of embrance and extend, but in this area, they are no worse than any other company. Just think about how many proprietary discussion group and email systems exist.. (Netscape Collabra, Lotus Notes, Exchange)
Maybe we can calm down a little and forget about Microsoft for once?
Re:2821 isn't really a new standard (Score:2)
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.
SMTP Error Messages (Score:1)
In my experience some MTAs just drop the error message they got from speaking to another MTA and inserting whatever they think is appropriate. This is bad. An error message like: "553 Open relay problem - see http://www.orbs.org/..." turns into "500 user unknown" which is definitely not the case. And the sender blames the MTA of the receiver...
IMHO this should not happen.
Re:Innapropriate Extensions (Score:2)
Boss of nothin. Big deal.
Son, go get daddy's hard plastic eyes.
Re:Innapropriate Extensions (Score:1)
It is possible to add to a standard and simplify it at the same time.
Re:Embedded Input Forms in Email (Score:2)
Tom Swiss | the infamous tms | http://www.infamous.net/
Re:A dream I had... (Score:2)
Re:not to burst anyone's bubble... (Score:2)
Translation: Never.
not to burst anyone's bubble... (Score:3)
A dream I had... (Score:2)
res: RUSPAM
req: YES
res: GOFUCKYOURSELF
req: OKSHOULDIKILLTHESENDER
res: YES
req: OKCRASHINGSENDERBOX
[...connection closed...]
Re:not to burst anyone's bubble... (Score:2)
No, no, no. winmail.dat [google.com] is a good thing. It tells you which companies hire completely incompetent sysadmins. It's a big red flag that says "these idiots are going to get 0WN3D by kiddies and hammered by viruses [yahoo.com] for the next several years". It's a shame that so many organizations (such as PBS [pbs.org]) fall into this category, but it's their loss.
Personally, I just wish that all webmail services provided a "view as plain text" option.
Both are on www.faqs.org (Score:3)
2822 is here [faqs.org].
-- fencepost
IPV6 in SMTP (Score:2)
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]
Re:is this important? (Score:2)
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.
Re:Well, the reply-to argument is at rest... (Score:2)
No, the SMTP MAIL FROM address, which isn't necessarily the one in the message itself.
But the problem there is still that some errors don't happen during the SMTP transaction, they happen later on, inside the receiver's network or something strange like that. Then all the deliverer has to go on is what's in the From/Sender/Reply-To headers.
Sendmail and >From; - turn off the "E" flag! (Score:2)
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.
Re:Why not XML based? (Score:2)
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
Re:they are only PROPOSED standard atm (Score:2)
(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
Re:2821 isn't really a new standard (Score:2)
/Brian
Re: getting rid of winmail.dat attachments (Score:2)
Won't Kill them, but at least will make them useful.
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:Embedded Input Forms in Email (Score:2)
So ignore the RFC. (Score:2)
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
[OT] Re:Why the wasted time and energy? (Score:2)
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
Re:Line Length (Score:2)
Re:Line Length (Score:2)
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.
Re:Why the wasted time and energy? (Score:2)
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.
Re:Line Length (Score:2)
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.
Re:Well, the reply-to argument is at rest... (Score:2)
I get pretty pissed in the IETF when folk use that line unless they can then follow up with a statement of what the additional problems that need to be considered are.
The whole premise of SMTP is that a naive (Simple) approach to email is sufficient. In many cases the problem is solved simply by the statement of a uniform approach.
Any solution that is not simple is certainly not going to work.
Re:Well, the reply-to argument is at rest... (Score:2)
I can answer that /dev/null
Sending automatic error emails is the cause of most email problems and the solution to almost none.
In the case of a mailing list nobody cares that alice did not get the email.
I would however support a proposal to formalize this situation:
Error-Reply-To: /dev/null
OK, maybe, just maybe
Error-Reply-To: http://listserv.test/kick_off_list/that_idiot_alic e
Re:But Microsoft will decide to invent their own.. (Score:2)
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.
Re:Line Length (Score:2)
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.
Re:Well, the reply-to argument is at rest... (Score:2)
There are two bugs here, first the fact that SMTP design means that a list server requires a list admin.
The other bug is that the standard does not differentiate between normal replies and automated replies.
If mailers implemented SMTP correctly and only accepted mail they could process the SMTP codes would suffice. Unfortunately email has acquired a whole set of pathologies, in particular spurious relays. There is no reason my email client cannot effectively deliver mail itself. Instead most email clients insist that the mail be passed to an outgoing mail server, introducing the need to report failed mail.
If this was the SMTP design the authors should have provided for a proper protocol for handing off mail to a mail forwarder. This would provide for reporting of asynchronous error codes.
And removing people automatically as you propose causes even more problems. Even your mail quota can be exceeded ;-)
What the list serve does with the error report is its own business. The most sensible approach is to track send failures and dump the user after a certain period.
Re:[OT] Re:Why the wasted time and energy? (Score:2)
If you have a large quantity of data the overhead of either protocol will be negligible.
The human interface of FTP is better for some tasks, however it is still pretty crappy.
Why not have an interface that allowed the FTP site to simply be mounted as a remote file system in the manner of automount NFS?
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.
SMTP spec should do more for encryption (Score:2)
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?
/.ed (Score:5)
sigh.
Be conservative in what you send and liberal in what you receieve.