Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
The Internet

New Mail RFCs Released 196

Posted by timothy 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 More

New Mail RFCs Released

Comments Filter:
  • Oh. So it doesn't use XML yet?
    Bastards! How in the world they expect to interoperate on the internet without supporting XML?

    Victor
  • Yes. That would break a lot of stuff.
  • qmail has an extremely restrictive license which is quite bothersome. My favourite Sendmail killer is Exim; others prefer Postfix.
    --

  • 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.)

  • 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.)
  • The USPS should never care being as they are a government entitiy which is funded entirley by stamp sales. The USPS's function has never once been to make money, their function is to deliver mail which our leaders have deemed a vital function in our society.

    Besides, any money the government makes is EVENTUALLY (after 80% of it is flushed into the proverbial beurocracy bowl) spent on the people anyway.
  • That this many people would all want to look at a serious RFC at the same time.
  • ... which means there is going to be a lot discussion about it. Some very Good Things(tm) are in it (ipv6, so isp's will finaly have to implement it), but some bad as well (a lot of people will cry that HELO is no longer apreciated) ...
  • Oh great... Just when sendmail starts to get all the bugs worked out...
  • Lovely idea but it doesn't belong in a basic standard.

    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.

  • 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.....

  • 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.

  • 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.

  • 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)
  • In this case, I can. As another post said, transmitting mail and storing mail _should_ be two different things. If the mail is stored in a "fancy" mailbox, as opposed to a unix mbox (where From is the divider), then there should be no need whatsoever for the > character...but its there anyways, because Sendmail attaches it to it as it forwards it.

    See page 79 of Unix-Haters Handbook for a discussion on it.

    Page 81:

    Sendmail even magles mail for which it isn't the "final delivery agent"...

    --
    You know, you gotta get up real early if you want to get outta bed... (Groucho Marx)
  • Actually, I think it was the fact that it worked well and for so long that it was left alone. Since any email server could send mail to any other email server since all were complient then email was easy and worked. Why mess it up?

    Of course this new one will most likely cause some problems with new servers that don't follow directions correctly...
  • And, in particular, how will they change my life and/or the way I use mail?

    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.
  • Duh...

    I know.... party pooper.

    --

  • RFC 821 and 822 were grandfathered in as full Standards. They predate by quite a few years the standardization levels.

    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.
  • Correct me if Im wrong (and its likely), but dont MOST of the common protocols run on whatever transport layer you decide to implement them? I thought the protocols were independent of the comm stack...
  • AFAIK there is no way to get IMAP to work without both end user configuration and entering storing passwords.

    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).

    -
  • 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.
  • Versions and revisions and such would defeat the purpose of a flat numeric index for the RFC's. When someone talks about RFC822, I know exactly what document they mean, typos, vaguenesses, inaccuracies, and all, it requires no further clarification. They're also issued in roughly chronological order (though they weren't strictly in order even from the start, TCP and telnet are discussed well before their RFC's), so I know that an RFC that's 1000 higher than another definitely came after.

    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.
    --
  • Strange but true. There's numerous STD docs that are based on RFC821, but RFC821 never itself became a STD. However, STD10 is ESMTP (RFC1869), which is probably close enough.
    --

  • Re:Don't blame sendmail (for once) (Score:3)

    by scrytch ( 9198 ) <chuck@myrealbox.com> on Wednesday April 25, 2001 @10:04AM (#266177)
    > 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?
    --
  • our isp, using Cubic Circle's Cucipop answers "quit" with
    +OK Was it as good for you, as it was for me? (clean as a baby)

    Just showing off fashionable fake replay .sig
  • Then explain the "group" addition to the To: header. ;)
  • No.

    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.
  • 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. :/
  • 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.

    -
  • Check out evolution... it supports MH and mbox,.. possibly others.
  • 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.

    Peace,
    (jfb)
  • Gnus does. Support the idea of pluggable backends, that is.

    Peace,
    (jfb)

  • 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.

  • Um, guaranteed Quality of Service
    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.

  • Nah, no one would ever get the Postal Service confused with the Postel Service. There's no competition there.

    Bravery, Kindness, Clarity, Honesty, Compassion, Generosity

  • 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 [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)
  • They have. For starters, there are other mailbox formats that have advatanges over the Berkeley standard. However, the Berkeley one has the advantage of inerita since it's the most common.

    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.
  • 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.
  • 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.
    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.
  • 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?

  • Re:Why the wasted time and energy? (Score:3)

    by dublin ( 31215 ) on Wednesday April 25, 2001 @08:38PM (#266198) Homepage
    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...
  • Quoting RFC2821 (Section 2.3.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 ;) accept it. I think it's up to the MUA to bug the user with it.

    Sendy
    --
    I used IE for this. I was expecting vi and Window Maker. IE sucks. (Note ESC)
  • ESC really sucks in IE

    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
  • One really good example of this is the HTML standard that was totally overrun by the industry instead of leading it.


    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.


  • 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:



    Plain text is intended to be displayed "as-is"


    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)

    by mughi ( 32874 ) on Wednesday April 25, 2001 @12:27PM (#266203)
    And besides, when was the last time you read email on an 80 column terminal?


    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)

    by tiny69 ( 34486 ) on Wednesday April 25, 2001 @08:51AM (#266204) Homepage Journal
    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.

  • Won't that break lots of mail clients that use standard "unix" mail boxes? IIRC, these clients us a newline followed by a From (no colon) line to signify a message boundary.

    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.
  • 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.
  • I've wondered why we don't start giving RFC's version numbers. If we said RFC822 version 2, that would be perfectly clear.
  • 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!"

    You can do this with 550 error codes. The text of the error message should be delivered back to the author.

  • This story had absolutely nothing at all to do with Microsoft but wouldn't you know it - there's still a post with a negative tone about Microsoft.

    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?
  • 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.

  • 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.

  • Delivering the error message back to the author rarely does much good. I wish I had a nickel for every time someone I had this conversation:
    "My e-mail got returned, why?"
    "I don't know, did you look at the message to see why it was returned?"
    "No"
    "Do that now and tell me what it says."
    "It says.... blah blah blah... No such user."
    "The e-mail address you sent it to does not exist."
    "Oh, OK." (calls friend) "Hey, my e-mail to you got sent back for some weird reason. There must be something wrong with our server because we can't send e-mail. Can I send you a fax?"


    Boss of nothin. Big deal.
    Son, go get daddy's hard plastic eyes.
  • This is exactly why it's important to have standards to define "all possible situations" rather than just textual error messages: so that an automated system (i.e. your email client) can read the error message itself and deal with it apropriately, e.g. relay the error message back to the user in a way s/he can understand; or automatically retry with an alternative email adddress, etc. Without making a standard as robust as it should be, the clients can never become as powerful as they should be able to be.

    It is possible to add to a standard and simplify it at the same time.
  • I think there should be a standard that defines a syntax to include some input fields in the body of emails.
    This can be done with HTML-formatted e-mail; I once got spam that was a fill-in form submitted via a mailto URL. I don't know what mail clients would or would not support this, though. (I use mh and exmh; exmh has some HTML support, but I view this (and alerted the relevant postmasters) from the command line version so never saw it rendered.)

    Tom Swiss | the infamous tms | http://www.infamous.net/

  • Oh, man, that's a *wet* dream ... ;)
  • When Microsoft stops using proprietary formats.

    Translation: Never.

  • not to burst anyone's bubble... (Score:3)

    by matman ( 71405 ) on Wednesday April 25, 2001 @07:45AM (#266231)
    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...]

  • damn winmail.dat attachments.

    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)

    by Fencepost ( 107992 ) on Wednesday April 25, 2001 @07:44AM (#266251) Journal
    2821 is here [faqs.org],
    2822 is here [faqs.org].

    -- fencepost
  • 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?

  • Re:It's about damned time. (Score:3)

    by StandardDeviant ( 122674 ) on Wednesday April 25, 2001 @07:24AM (#266257) Homepage Journal
    Personally, I think that proprietary extensions would not be used so often if the standard were to keep up with the times, accomodating the needs of the community in a uniform and non-propriety fashion.

    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]
  • 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.

  • But sending it to the "From" address isn't appropiate either

    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.

  • In this case, I can. As another post said, transmitting mail and storing mail _should_ be two different things. If the mail is stored in a "fancy" mailbox, as opposed to a unix mbox (where From is the divider), then there should be no need whatsoever for the > character...but its there anyways, because Sendmail attaches it to it as it forwards it.

    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
  • See Fentun [fentun.com].

    Won't Kill them, but at least will make them useful.

  • Winmail.dat? Not a problem! (Score:3)

    by satch89450 ( 186046 ) on Wednesday April 25, 2001 @06:47PM (#266290) Homepage

    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.
  • And while I have a few holes in my head, I do not have a serial port. By your logic, "lots of 80-column terminals" must not "support Windows" (since your statement depends upon me having a serial port, which I don't, although most of my computers do

    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.

  • 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.

    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.

  • I've seen all the posts about how this really isn't anything new; but, I found something in it that's my personal pet peeve. Section 2.3 "Body" states that the message MUST be limited to 998 characters plus the CRLF and SHOULD be 78 plus the CRLF.

    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.

  • now that this work is done perhaps the issues associated with replies to list traffic can be tackled. but the problem isn't as simple to solve as it seems at first, and most of the popular approaches are naive.

    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.

  • Another issue I hoped would be resolved is where automatic error emails should be sent to.

    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

  • But Microsoft will decide to invent their own standard that they say is better but and not support the new standard. This way _everyone_ will have to have a Windows machine to send email to other people with Windows machines

    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.

  • Moving to a mailer that displays HTML would be a downgrade, not an upgrade. (And worthless, as my .procmailrc bins HTML on incoming mails wherever possible anyway).

    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.

  • Well, I (as as the listadmin) do care.

    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.

  • Any single transfer, yes. How about "mget *-src.tar.gz"?

    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)

    by Zeinfeld ( 263942 ) on Thursday April 26, 2001 @05:38AM (#266321) Homepage
    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...)

    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.

  • Currently nearly 100% of internet email travels in plaintext over a relatively small number of interconnect points. I am no real conspiracy theorist, but I think it is obvious that this situation is being used to gather information by various nationalities.

    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)

    by sllort ( 442574 ) on Wednesday April 25, 2001 @07:04AM (#266343) Homepage Journal
    since we just /.ed the RFC editor site to hell, have a mirror [f2s.com] of both [f2s.com]

    sigh.

    Be conservative in what you send and liberal in what you receieve.

Slashdot Top Deals

Murphy's Law, that brash proletarian restatement of Godel's Theorem. -- Thomas Pynchon, "Gravity's Rainbow"

Close