[Enigmail] Yes - FTP begat email... directly. (was Re: MIME - PGP/MIME - S/MIME debacle...)

Fri Feb 22 11:30:21 PST 2008

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Barry,

forgive my ignorance but what is the date on the earliest of the "Mail over FTP"
- - if I may call it that - RFC?

Peter Dzwig

Barry Smith wrote:
| Hi, Robert:
|
| First off, your discussion of email RFCs don't go back far enough.
|
| Email is not the sole domain for SMTP, IMAP, POP etc... and you only
| mentioned SMTP.
|
| No, Emails were being tossed about long before the "formal" internet
| existed.
|
| My senior seminar report tracked the concept of email (not SMTP) back
| into much earlier RFCs... a quick Google gets me back to RFC 822,
| which explicitly obsoletes RFC 733.
|
| | I see no cross-coverage between the FTP RFCs and the SMTP RFCs.
| Again, you are focused on SMTP, not "mail", or as it was referred to
| in some of the RFCs for "ARPA Internet text messages".
|
| Actually, if you look in RFC 524 (the original specification of the
| "Proposed Mail Protocol"), you'll see reference to the _fact_ that
| mail was being transferred before this RFC 524, and I quote --
|
| |    This is the document I offered in (15146,) to write.
| |    It's a proposed specification for handling mail in
| |    the Network -- a Mail Protocol.
| |
| |    Main handling is currently implemented as two FTP
| |    commands, MAIL and MLFL, which permit an FTP user
| |    process to deliver a file or string of text to an
| |    FTP server process, designating it as mail to be
| |    made available to a user, identified by a local
| |    name, in its host.
|
| The 15146 in the quote above refers to the Network Information Center
| documents, which are mentioned as far back as RFC 101.
|
| OK, back to the search.
|
| I was pointing out a single document that links FTP and MAIL...
| how about the FTP spec from RFC 542?
| If you look in RFC 542, under the section "MISCELLANEOUS COMMANDS"...
|
| |    There are several functions that utilize the services of file
| |    transfer but go beyond it in scope.  These are the Mail and Remote
| |    Job Entry functions.  It is suggested that these become auxiliary
| |    protocols that can assume recognition of file transfer commands on
| |    the part of the server, i.e., they may depend on the core of FTP
| |    commands.  The command sets specific to Mail and RJE will be given in
| |    separate documents.
|
| Thus, backing up my original statement...
|
| |> First -- Email is really a specialized version of FTP for special text
| |> files.
|
| For more on the development of mail... or email...
| don't forget RFC 524, RFC 751, RFC 753, RFC 757, RFC 759, RFC 760, RFC 761,
| RFC 763.
|
| QED.
|
| "MAIL" at one point [see RFC 765 - MAIL FILE (MLFL)] _was_ an FTP command.
| maybe it still is... will have to research that one in a spare moment. ;) )
|
| | On some level, sure, they're the same thing--but this is the same level
| | that says "FTP and HTTP and email are the same thing, since I can get
| | ftp:// and http:// URLs through my browser and my ISP provides webmail."
|
| No. Now you are talking about a browser-support feature of supporting
| multiple protocols.  I am pointing out that EMAIL and FTP are closely
| related, because EMAIL is based upon and was part of FTP at one time.
|
| Sorry.
|
| No hard feelings?
|
| Barry Smith
| Robert J. Hansen wrote:
| | Barry Smith wrote:
| | | First -- Email is really a specialized version of FTP for special text
| | | files.
| |
| | Umm... no.  No, no, no.  This is divorced from reality.
| |
| | FTP is covered by RFCs 114, 133, 141, 171, 172, 238, 264, 265, 765, 959,
| | 1579, 2228, 2428 and 3659.  There may be a few more that I've missed,
| | but that should be a reasonably comprehensive enumeration of the various
| | FTP RFCs from 1971 to the present.
| |
| | SMTP is covered by RFCs 821, 822, 974, 1123, 1651, 1847, 1869, 2015,
| | 2045, 2046, 2047, 2077, 2821, 2822, 3156 and 4288, among others.  (Some
| | of those RFCs actually specify the format of mail messages as opposed to
| | the mail transfer protocol, but I'm lumping them into the SMTP family
| | here.  Purists are free to object, and are probably right to do so.)
| |
| | I see no cross-coverage between the FTP RFCs and the SMTP RFCs.
| |
| | On some level, sure, they're the same thing--but this is the same level
| | that says "FTP and HTTP and email are the same thing, since I can get
| | ftp:// and http:// URLs through my browser and my ISP provides webmail."
| |
| | | While looking for a website to read about "MIME vs attachment",
| | | I happened upon the reason that MIME is not supported by GPG, nor
| | | PGP/MIME.
| |
| | Yes... because this is only relevant at the level of mail user agents,
| | and GnuPG quite wisely avoids that.  (Or, at least, did: GnuPG 2.x has
| | some support for S/MIME, CMS and PGP/MIME.)
| |
| | | 1) If any mailserver
| | | ~     (including the one that you connect to when you send OR
| | | ~      receive email, OR any mailserver in between you and your
| | | ~      communication partner)
| | | doesn't support MIME or PGP-MIME or even GPG, it can choose to
| | | strip out what it doesn't like in the email.
| |
| | If any MTA doesn't like you for whatever reason it can choose to do
| | almost whatever it likes to the email.  It is not simply "I don't
| | support MIME, PGP/MIME or GnuPG".  It could be "there's a full moon
| | tonight and the sysadmin has not quenched my thirst with the blood of
| | twelve chickens, two horses and a purebred Guernsey cow."
| |
| | | 2) The convention is that most mailservers look at the FROM
| | | header and the TO header to see if it should process it as a
| | | local file and validate the email file, or forward the mail
| | | as-is to another MTA.  During local validation, and MTA will
| | | verify that the email meets the local guideline for a valid
| | | email.  If it sees anything that it thinks is invalid, it
| | | can remove it.
| |
| | Relaying MTAs are supposed to pass data on unmolested, but this
| | gentleman's rule is increasingly ignored nowadays.  PGP/MIME and/or
| | GnuPG have little to do with it.  The person running the MTA gets to
| | decide what sorts of messages get relayed on for further delivery or
| | accepted for local delivery, and may use rules as arbitrary as the
| | sysadmin wishes.
| |
|

____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
_______________________________________________
Enigmail mailing list
Enigmail at mozdev.org
https://www.mozdev.org/mailman/listinfo/enigmail

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHvyLNFBRi6tGXGGYRAsg6AJ9jeyEJ98+b2Ps4RNzJ8Udv+RW7KQCfV72o
gHGuA9WNNt03XPi5mFAFT8U=
=vGMc
-----END PGP SIGNATURE-----