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..."
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.
--
Xenu loves you!
I'm sure everyone has their own favorite mirror, but I like x42.com's RFCs. You can get these two at rfc2821.x42.com and rfc2822.x42.com.
--Phil (x42.com even has anchors on the sections of the RFCs.)
355/113 -- Not the famous irrational number PI, but an incredible simulation!
The people at RFC.net have a link to An epitaph for RFC822 that turned up on their discussion mailing list.
--Phil (Sure it's MLP, but it's interesting MLP.)
355/113 -- Not the famous irrational number PI, but an incredible simulation!
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.
-- Object known as a camera. Vintage uncertain, origin unknown. - Twilight Zone
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...
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
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...
If ignorance is bliss, the world is full of blissful people
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.
If ignorance is bliss, the world is full of blissful people
I know.... party pooper.
--
Your Servant, B. Baggins
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...
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.
our isp, using Cubic Circle's Cucipop answers "quit" with
.sig
+OK Was it as good for you, as it was for me? (clean as a baby)
Just showing off fashionable fake replay
try { do() || do_not(); } catch (JediException err) { yoda(err); }
Then explain the "group" addition to the To: header. ;)
-- Grey d'Miyu, not just another pretty color.
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.
-- Grey d'Miyu, not just another pretty color.
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.
-
http://www.egrabber.com
Je ne parle pas francais.
Check out evolution... it supports MH and mbox,.. possibly others.
I said no... but I missed and it came out yes.
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)
To spur "enterprise Linux," Big Bang, the distributed two-phase commit.
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.
Your right to not believe: Americans United for Separation of Church and
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.
Bravery, Kindness, Clarity, Honesty, Compassion, Generosity
...Nothing interesting here. Just move along...
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.
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?
"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
Quoting RFC2821 (Section 2.3.1):
;) accept it. I think it's up to the MUA to bug the user with it.
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)
GNU guru and mainframe hacker
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:
However, RFC 1896 defined text/enriched to achieve that auto-wrapping that you desire. Or your mail program could just use text/html.
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)
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".
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.
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.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
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.
"Is it friday yet?"
Tom Swiss | the infamous tms | http://www.infamous.net/
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
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).
I upgrade my mailer when needed to a shiny new release of mutt, and read mail in a variety of 80-column terminals, be they xterms, (virtual) consoles, serial sessions from a termulator, or whatever. Admittedly, I've not used a real, physical VTwhatever in a while.
Other posters' comments regarding cold, dead fingers apply.
Regards,
Tim.
That's why I used to be a big sendmail fan. When I was talking UUCP, Fidonet and occasionally other oddities, sendmail rocked - you could (and can, I guess) do pretty munge any kind of munging, translation, forwading and other cleverness you need to.
I haven't had a box need to speak anything other than SMTP in probably a couple of years now, and I'm starting to gravitate towards Postfix. While I respect the power of sendmail.cf, it's too much pain to remember what you're doing unless you're hacking on it day-in, day-out.
Regards,
Tim.
The softwarelaw.html page you cited give DJB's take on what your rights are after you have legally received a copy -- you can make backups, modify it, etc. He says nothing about distributing further copies, nor distributing your changes. And he's right. The law he cites allows making of copies for yourself for specific reasons ("(1) that such a new copy or adaptation is created as an essential step in the utilization of the computer program in conjunction with a machine and that it is used in no other manner, or (2) that such new copy or adaptation is for archival purposes only and that all archival copies are destroyed in the event that continued possession of the computer program should cease to be rightful. "), but not the distributions of the copies or "adaptations".
For that, you need the permission of the copyright owner, and DJB won't give it for modified versions (what he says is "If you want to distribute modified versions of qmail (including ports, no matter how minor the changes are) you'll have to get my approval. This does not mean approval of your distribution method, your intentions, your e-mail address, your haircut, or any other irrelevant information. It means a detailed review of the exact package that you want to distribute."
What he says about licenses on the software law page and on the distribution page are not contradictory, but rather deal with different portions of the law. He does not believe in "shrinkwrap" licenses, so he doesn't use one. He demands absolute control over what gets distributed, so he uses a very-tight copyright license.
Just curious why you would like that. Personally, I very much appreciate being able to resize my mail reader window and have the paragraphs reflow to the width I set. I don't see the point of taking this flexibility away from the user.
Convert RSS to HTML - integrate webfeeds into your website
No no no... see... We had something good, RFC822, now there is RFC2822, now Microsoft will come out with their own standard (RFC2822MS) that doesn't support any other standard, but then some ticked off OpenSource/GNU loving sysadmin will come out with OpenRFC2822 that uses both and the world will be a better place. But... it will contain a piece of GNU text, and Richard Stallman will insist that we call is GNU/RFC2822 =) -SAFH
I cannot confirm nor deny the allegation or allegations you may or may not have just made
I agree with you that long line-lengths can be distracting, and I'm definetely annoyed by people whose mail clients can't manage to word-wrap their messages, but whereas for mail it's clearly a problem with the sender's client, on the web, it should be the browser that takes care of enforcing this, not the web site - after all, line length is a feature of the presentation, not the content.
Have you tried making your web browser window narrower? What you say? But then viewing web sites with lots of big graphics and highly-tabelized layouts is very annoying?
It's those websites which are the problem, not the ones where the designer lets you pick the line lengths.
Oh, man, that's a *wet* dream ... ;)
I am quite civilized, and I should be brought a beer immediately. -- Bruce Sterling
Microsoft Exchange server still doesn't allow the use of "+" symbols in your email name (i.e. john.doe+itcamefromspam123@doe.com)
Check out RFC2822's dot-atom BNF syntax in section 3.4.1. The following symbols are allowed in the local-part of the email address (before the @ symbol):
!#$&*'+-/=?^_~{|}`
When Microsoft stops using proprietary formats.
Translation: Never.
-- You can't idiot-proof anything, because they're always coming out with better idiots.
To tell you the truth, as much as I might dislike Microsoft as a corporation, I will say that Outlook is still the one of best PIMs out there, and even it's E-mail capabilities aren't that behind.
Hey, I don't like Michael Jackson as a person either, but he made some damn great music.
- Dave
Why, no, I haven't meta-moderated lately. Thanks for asking!
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.
Assuming that communicating "just fine" means sending HTML-formatted messages using Microsoft-specific character codings (non-Unicode curly quotes, etc.) and expecting the recipient to deal with it. Hotmail even changed their default settings recently so that there isn't even a plain-text alternative included in the message anymore.
Who said I was using MS products? I was complaining about the garbage that other people who are using MS products send me. Are you saying I should just refuse to receive e-mail from any of them? It's a thought, I suppose, but it seems a bit harsh to refuse to communicate with my less technically inclined friends and relatives simply because they're unaware that Bill & Co. are causing them to produce nonstandard messages.
req: HELLO
res: RUSPAM
req: YES
res: GOFUCKYOURSELF
req: OKSHOULDIKILLTHESENDER
res: YES
req: OKCRASHINGSENDERBOX
[...connection closed...]
Someone you trust is one of us.
Anything that lasts 20 years on the Internet and is then "revised" to be pretty much the same as it ever was, is a good design indeed.
Hats off!
Um, right now. If I showed you a screenshot, you would see that this window is partially covering a SSH terminal running Mutt and displaying my inbox.
The same notation in RFC821 has misled many implementors to think that it means:
Although the < and > brackets really should be there:
Unfortunately there are SMTP servers that do not require the brackets, and thus many mail clients and gateways tested with just the "nicer" servers do not work with servers that follow the protocol strictly.
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. One really good example of this is the HTML standard that was totally overrun by the industry instead of leading it.
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.
I wish they'd pay attention to possibly more radical changes to the mail infrastructure. Specifically, it seems that Internet Mail 2000 solves numerous fundamental problems with SMTP and the other mail related protocols, POP* and IMAP. It's disappointing to see more time spent on a protocol with a far better alternative.
Jeremy
--
Looking for a Python IRC bot?
From RFC2821:
It consolidates, updates and clarifies, but doesn't add new or change existing functionality of the following: - the original SMTP (Simple Mail Transfer Protocol) specification of RFC 821 [30], - domain name system requirements and implications for mail transport from RFC 1035 [22] and RFC 974 [27], - the clarifications and applicability statements in RFC 1123 [2], and - material drawn from the SMTP Extension mechanisms [19]. It obsoletes RFC 821, RFC 974, and updates RFC 1123 (replaces the mail transport materials of RFC 1123). However, RFC 821 specifies some features that were not in significant use in the Internet by the mid-1990s and (in appendices) some additional transport models. Those sections are omitted here in the interest of clarity and brevity; readers needing them should refer to RFC 821.
"Great way to spread, take advadage of your monopoly to force a new propritaty standard on everyone."= \=\=\=\
Ummm.. a propritary standard??? thats has got the be the best oximoron I have heard in a long time.
=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\
RFC 821 still applies for things that RFC 2821 doesn't specify - like SMTP over X.25. For most
purposes, RFC 2821 supersedes RFC 821.
mainly they're trying to clean up ambiguities in the orginal specifications which have become apparent over the past 20 years or so, and which occasionally caused interoperability problems. they're also trying to discourage some things which have been found to work poorly in practice.
These new RFC's are good, but to really solve the problem of spam and mail storage, a fundamental change in the protocol is needed.
Check out http://cr.yp.to/im2000.html
I'm impressed with this person's ideas for protocols. And his webpage has a neat domain name too :-)
Super eurobeat from Avex and Konami unite in your DANCE!
Dr. Demento On The 'Net!
2821 is here,
2822 is here.
-- fencepost
fencepost
just a little off
I may have missed it, but man do I wish the new RFC included an encryption scheme. Of course, they'ed make it backwards-compatible with servers/clients that didn't support encryption...and while some may say this defies the point of putting it in the standard, I say it's about time we started to really think about the security of our mail. If we say new servers that wish to comply with the RFC have to support an encryption-standard, and try to use that by default, then we're on our way to having secure mail transactions.
Sounds like an anti-aging face cream...
MindStalker: You're right. But the new RFC states that protocol must be able to be implemented across all of the transports. This way, we have no further reason to ignore IPV6 networks (well really, we're being nice to everyone). I didn't mean to imply that IPv4 is/should be depreciated
Bob: Remember that the SMTP server (or any application), when it opens a socket, has to choose the address family. So, it does matter what transport layer (or layers) you implement it with.
Black holes are where the Matrix raised SIGFPE
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
xterm? And here all this time I thought xterms were resizable... silly me...
when was the last time you read email on an 80 column terminal?
Today... and the day before that. And the day before that... and so on for about 3-4 years I'd say. Before that I didn't really use email much.
I write code on 80 character terminals (aterms actually under Linux). I write documentation in 'vim' on 80 character terminals. Why? I can crap it out to a printer and it comes out nicely on paper -- anywhere. It's lovely. It's archaic, heck this 80 character thing dates back to the days of punch cards but I still like it. I agree with the reply to this post that above 80 chars per line the reader can get confused. I'm one of them honestly... I like my stuff staying 80 characters.
And to prevent any replies saying, "Old fogie, get with the times." I'm only 21.
Justin Buist
Hey, you were close.
:(
:)
but the "User Space" slashbox must also be checked as well as having info filled in. And what you did actually unchecks the box
Try again, think harder
It is quite impressive that the originial specifications were in use that long. It is good to see changes, especially modifications for current practices. But to think that the old RFCs held up this long is quite amazing. They may not seem ideal now, but it takes some very good planning to make something work that long across such a wide time frame and user base.
It is more like RFC821 is obsolete now that 2821 exists, but 821 will still be used by some. There is a transitional period, and backwards compatability is important.
Fuck You. The point of the post is that sometimes the media gets wind of things it shouldn't. And runs stories about things 99% of the planet doesn't need to know about. When we updated the radius server, the admin felt it necessary to email all our dial-up customers, tell them about it. So they call us, and I have to spend 5 minutes explaining to someones grandmother that they need to call Compaq and see if they have any updated drivers, even though more than likely they dont. I didn't claim to be some kind of RFC genius, I read the things, well, scan them anyway, and most of it means little or nothing to me. Busta.
What, me worry?
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.
Tell Grandma not to worry. Tell her that you are fully compliant to RFC 1149, and that 82 22 has been replaced with 1149 as the new Internet standard. :)
[Connection closed by foreign host]
Hello, the first paragraph of the RFC says
how about every day? i read my mail using mutt via a putty session. there are millions of people who read their mail in 80 column terminals with pine, mutt, exmh, emacs etc. i for one can't stand reading email (or anything) in a full-screen outlook express window that is about 400 columns wide. it's damn near impossible
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.
Damnitall you freakazoid! Who the hell gave you the freakin baton of speakforall on this site, you know darn well jur gonna fry for this!
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
That's a bit sloppy, IMHO -- why not do a full 2821 with all the trimmings and then an informational abridged version?
/Brian
The world is a very different place than it was when those two documents were released. I presume they are talking about primitives such as SEND, SAML, SOML, TURN, and the like. Some of these mechanisms have security problems. Others are just plainold outdated. For instance, SEND was used to send an interactive message to an individual who was logged on to that very computer. How many people log into their mail server to receive instant messages? Those computers are unlikely to even know that your PC is online.
It says quite a lot for the developers of 821 and 822 (and 1123) that those standards have withstood such a long period of time without update. But that's not to say that mail hasn't changed. In that time, we've seen the creation of POP, IMAP, MIME, ldap, --->>> BIND ---, and all sorts of fun stuff.
If for no other reason, these new documents offer us an opportunity to look at them in light of the world we live in, and not "the good old days" (which maybe weren't quite as good as the days we live in).
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. I know it's a SHOULD and not a MUST, but it's better than a MAY. My hope is that all the clients will start forcing CRLF at the 78th character now instead of making paragraphs one really long line.
Doug Alcorn
I don't get any clue if new RFC's allow for refusing mail with other errors than 421 on highest MX to get all mail piped through lower MX'es?
__
L.
Won't Kill them, but at least will make them useful.
IP over messenger birds. I should talk to the pigeon breeders in my neighborhood about implementing it. Perhaps I should patent the pigeonethernet bridge. I think though I should extend the protocol to transmit the datagrams through barcodes to reduce the costs of the bridges. Barcode readers are much cheaper than optical scanners with OCR.
--- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
I hate to tell you but this RFC deals with a new method of implementing IP. Any TCP or UDP based mail RFC can be implemented over RFC 1149
--- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
Comment removed based on user account deletion
Comment removed based on user account deletion
Please show me the qmail license! Can't? Well, that's because there is none.
Read http://cr.yp.to/softwarelaw.html for DJB's take on licensing and you'll see why there is no license for qmail and determine for yourself what you are able to do with it.
How a license that doesn't exist is bothersome is beyond me.
My ancestors evolved from primordial ooze, and all I got was this lousy Existential Angst!
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
--no ISP wants to offer a cheap mail forwarding service um, no, open relay's are an Email admin's bastard child. Anybody (read spammer) can send thousands of email messages a minute through a relay server. Redirectipn is possible, it is just stupid at this time because it has a tendency to be abused. Nathan Wisconsin DOT email-admin
If moderators show interest by modding up this post, I'll even make it available under the GNU license.
Buy this post or we shoot this GNU? *grin*--
I would be a paid subscriber if Taco and Hemos weren't such cunts
I think there should be a standard that defines a syntax to include some input fields in the body of emails.
For example, a System Administrator may send an email to all users asking them for some information. When users hit the replay button an input form appears in the body of the mail were they can enter the requested information. Later, when the System Administrator got the replies he/she can process them manually or automatically because the information is submited in a predefined format.
This standard could also be used for shopping, customer support, workflow notifications, invitations to meetings and a lot of other things. The replies can be "read" by computer program who takes de proper action (ie, place a product order, record a customer support request, etc.).
The syntax could be similar to HTML Forms. Perhaps it could also include some JavaScript code for basic validations. Many applications can be made using this proposed feature.
Nobody thought about that before? Is there any proposed standard already written ?
MOD THE CHILD UP!
no... for ALL things, 2821 supercedes 821...
there are some things not covered in 2821, but that doesnt mean that 2821 doesnt supercede 821
Visit Ask Your Sweetie for an example (with source) that lets you send an HTML form in e-mail, or alternatively a plaintext message with a URL for the form.
More from the abstract: While I understand the reasoning for this, doesn't it defeat the purpose of obsoleting an RFC, if you are specifically instructed to refer to it foe explanations of certain pieces of functionality?
---
--Got Lists? | Top 95 Star Wars Line
Umm .. no, you can't. Well you CAN, but their mail server won't receive the mail for your domain. It certainly won't do virtual domain hosting, or direct all mails @the.domain to your e-mail account, whatever. For that, which means anything to do with an MX record point at a mail server, the mail server admin has to agree and configure the server appropriately.
So it comes down to: alter SMTP to support (arbitary) forwarding, or alter capatalism to get an ISP to accept mail to your virtual domain at no (low) cost. Hmmm.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
Well spotted. The reason Jon Postel's name is absent is due to him being deceased. http://www.postel.org/remembrances/ Regards, Steven
Great, you'd think after the uproar over the Y2K bug that they'd think far enough ahead to avoid this kind of thing. At least we have almost 7998 years to come up with a solution, though I'm sure most of us wont actually implement it until the November 9999.
You'd be surprised (but you'd have to read the new RFCs first) -- much of what's in them is stuff that's already used everywhere but didn't appear in a standard. It's as much a case of catching the standards up to practice as it is forging new directions.
For example, EHLO is now the standard greeting.
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/
I haven't read those new RFCs, but from what I've heard one thing that has been added is better "batch processing". Old SMTP requried quite a few round trip-times in order to send a message; first the TCP handshake, then the HELO with its answer, the RCPT with its answer, then the DATA and an answer.
The new RFCs should apparently make it possible to make the HELO, RCPT and DATA in one round trip-time. This would benefit those space-travellers with their long round trip-times!
Java, ActiveX, windows file sharing, are the first things that come to mind that are so.
--
Two witches watched two watches.
Which witch watched which watch?
Please feel free to ignore any parts of these RFC's you fell will hinder your innovation.
What is pirate software? Software for inventory of stolen treasure?
Most confuzzling.
--
Keep attacking good things as "communist"
KMSMA (WWBD?)
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. Great way to spread, take advadage of your monopoly to force a new propritaty standard on everyone.
When do you think it will stop?
-OrionPi
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 the FTP site listed had benn slashdotted, you can take a look at here and here for the RFCs.
-> Capt Cosmic <-
Can someone please explain why this is important? As far as I can tell, mail works just fine the way it is. What deficiencies are the new proposals trying to address? And, in particular, how will they change my life and/or the way I use mail? Are the proposed changes merely cosmetic, or do they address any fundamental issues?
Toronto-area transit rider? Rate your ride.
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.
This is ridiculous. The old RFCs served well for something like 20 years, there was absolutely no need to change them. For me it's just another reason to look forward to retiring from the field of computing and getting the hell off the damned Internet for good. (Absent its use as a technical resource for work, I see no need for it at all.)