Re: Email delivery protocols / methods.
On 7/9/19 9:14 AM, Paul Koning via cctalk wrote: > > >> On Jul 8, 2019, at 11:27 PM, Grant Taylor via cctalk >> wrote: >> >> ... >> On 7/6/19 12:57 PM, Paul Koning via cctalk wrote: >>> There's the MAIL-11 protocol (end to end, no MTAs) and the DECmail protocol >>> which may be some OSI-like thing, I'm not sure anymore. >> >> I guess I don't know enough about MAIL-11 to understand why you say >> end-to-end / no MTA. > > No mail servers. You address mail to node::user and it contacts the mail > protocol listener at that node, which drops the message into the mailbox of > that user on that system. The "protocol listener" as you call it is the mail server. UUCP and SMTP worked the same way until the dawn of networked MUA's that let the mail remain on some system other than the user systems. bill
Re: Email delivery protocols / methods.
> MMDF MMDF was[*] an MTA, not a protocol. (See also PMDF.) --lyndon * Is anyone still running MMDF? The last production shops I had my fingers in that ran it was circa 1996. That was when SCO was still a thing, and MMDF was its MTA of choice.
Re: Email delivery protocols / methods.
> On Jul 8, 2019, at 11:27 PM, Grant Taylor via cctalk > wrote: > > ... > On 7/6/19 12:57 PM, Paul Koning via cctalk wrote: >> There's the MAIL-11 protocol (end to end, no MTAs) and the DECmail protocol >> which may be some OSI-like thing, I'm not sure anymore. > > I guess I don't know enough about MAIL-11 to understand why you say > end-to-end / no MTA. No mail servers. You address mail to node::user and it contacts the mail protocol listener at that node, which drops the message into the mailbox of that user on that system. > Was DECmail the OSI X.400 email implementation that DEC produced (I think) in > the '90s? Yes, in ALL-IN-ONE and the like. An interesting point is that it was not really accepted as the internal mail tool (except by some corporate overhead departments); engineering persisted in using MAIL-11 based email on the internal network. >> For real strangeness there is the PLATO mail protocol, which involves >> writing the mail into files, which are then extracted from PLATO into the OS >> file system by a periodic batch job, then sent to another system via file >> transfer (FTP or a predecessor), then pushed into the PLATO file system, >> then picked up by a mail agent at that end. Ugh. > > $ReadingList++ You're unlikely to find documentation for this, unfortunately. It's part of the "linked systems" capability of PLATO, a loosely connected collection of systems which could exchange email, notes (as in Lotus Notes, which goes back to a very popular PLATO tool) and, in a very limited way, files. It used very strange custom network hardware originally, and eventually moved to TCP/IP under CDCnet. paul
Re: Email delivery protocols / methods.
> How many different protocols / methods can we collectively come up with > for how email can be transferred? There is the old AUTODIN system, which is email before email was "invented". I have never seen the protocol details, but there can not be much to it. -- Will
Re: Email delivery protocols / methods.
I'm combining my replies into one message to avoid spamming the mailing list. Thank you all for intriguing responses. :-) On 7/5/19 3:28 PM, Dennis Boone via cctalk wrote: · FidoNet (FTN) As long as we're being silly, this isn't really one protocol. There are a number of different ones, which can probably mostly be characterized as thin wrappers (FTS-0001, Yoohoo(/2u2), etc) around common file transfer protocols (zmodem, xmodem, and others). Fair enough. On 7/5/19 3:40 PM, Bill Gunshannon via cctalk wrote: Well, if the idea is to get that silly, UUCP isn't one protocol either. And, technically. it isn't for moving email at all. Like FTP it is for moving files. It is what happens after the files have been moved that makes email, email. Also fair enough. On 7/5/19 4:06 PM, Peter Coghlan via cctalk wrote: It's not a holiday in most of the world, including where I am, however... ;-) BITNET isn't really a protocol. Perhaps you mean NJE which was the protocol used to implement the BITNET and related networks? Uh … Ya! I meant NJE. ;-) Although I think BSMTP (batch SMTP) was usually used to transfer mail over NJE networks. $ReadingList++ (Speaking of which, anyone want to join an NJE network?) Where can I find out more? I have no idea what this one is. "Mail spool" could mean mean all sorts of different things on all sorts of different systems. I was thinking an MUA accessing files in the mail spool (traditionally /var/spool/mail as far as I know) and not using an intermediate protocol (POP3 / IMAP / etc.). Another one was the coloured book protocol used between academic establishments over X.25 networks in the UK and Ireland and probably elsewhere, Grey maybe, I forget which, probably for the best. $ReadingList++ Then there is DECnet and/or Mail-11… I don't know how I missed that. …depending on what level of protocol you are talking about. Valid question. I don't have a distinction at the moment. And phonenet which I often heard about but never saw. I think I have a term collision in my head. I /think/ I'm thinking of Home Phoneline Networking Alliance. I worked for an email provider for about 15 years. We used just about every protocol you can think of to transfer mail to customers, including those already listed plus Kermit / X/Y/Zmodem / Blast (a file transfer package few seem to have heard of) wrapped up in protocols we came up with ourselves which often also used stuff like Zip to compress the data for transmission. We used them to feed mail into all sorts of email systems long since come and gone, for example CCmail, Microsoft Mail and Pegasus Mail, to name but three from the 1990s. Intriguing. I think that CCmail / Microsoft Mail / Pegasus Mail were email technologies that used shared access to a common "Post Office" (directory structure). On 7/5/19 5:27 PM, Peter Corlett via cctalk wrote: I use rsync (over ssh) for transferring between a couple of my mail servers. Hum. I'm curious to know more. Are you transferring / synchronizing mail boxes? Or are you using rsync as an intermediate transport between and outgoing spool on one system and an incoming spool on another system? On 7/5/19 5:40 PM, Jason T via cctalk wrote: I have vague memories of batch email transfer utilities from the BBS world. They were readers and/or transfer agents, but I imagine some had their own transfer protocols and file formats. The only two I can recall at the moment were QWK and Blue Wave. This probably has some tie-in to FIDOnet as well. I've heard of QWK and "BinkP" is coming to mind for some reason. On 7/6/19 12:57 PM, Paul Koning via cctalk wrote: There's the MAIL-11 protocol (end to end, no MTAs) and the DECmail protocol which may be some OSI-like thing, I'm not sure anymore. I guess I don't know enough about MAIL-11 to understand why you say end-to-end / no MTA. Was DECmail the OSI X.400 email implementation that DEC produced (I think) in the '90s? For real strangeness there is the PLATO mail protocol, which involves writing the mail into files, which are then extracted from PLATO into the OS file system by a periodic batch job, then sent to another system via file transfer (FTP or a predecessor), then pushed into the PLATO file system, then picked up by a mail agent at that end. Ugh. $ReadingList++ On 7/6/19 1:33 PM, Chuck Guzis via cctalk wrote: Those who quibble about the ftp being a separate entity from mail protocol would do well to look at RFC 524 from 1973. There, the MAIL command is implemented within the ftp structure (that is, it is an ftp command). Yep. -- Grant. . . . unix || die
Re: Email delivery protocols / methods.
Those who quibble about the ftp being a separate entity from mail protocol would do well to look at RFC 524 from 1973. There, the MAIL command is implemented within the ftp structure (that is, it is an ftp command). I've found it interesting that 524 never addresses the matter of data representation: (7 bit ASCII PDP-10), (8-bit IBM EBCDIC), (6-bit Univac Fieldata), (9-bit MULTICS), etc. This makes sense when viewed in the light of RFC 354 (ftp), as 354 makes provision for non-7-bit ASCII codes. --Chuck
Re: Email delivery protocols / methods.
> On Jul 5, 2019, at 5:05 PM, Grant Taylor via cctalk > wrote: > > Here's pot stirrer for a holiday Friday afternoon: > > How many different protocols / methods can we collectively come up with for > how email can be transferred? > > I'm primarily thinking about between servers (MTA-to-MTA). But I'm also > willing to accept servers and clients (MTA-to-MUA). Where you can / could > run at least one server yourself. There's the MAIL-11 protocol (end to end, no MTAs) and the DECmail protocol which may be some OSI-like thing, I'm not sure anymore. For real strangeness there is the PLATO mail protocol, which involves writing the mail into files, which are then extracted from PLATO into the OS file system by a periodic batch job, then sent to another system via file transfer (FTP or a predecessor), then pushed into the PLATO file system, then picked up by a mail agent at that end. Ugh. paul
Re: Email delivery protocols / methods.
Obviously that message wasn't supposed to go to the list. I forget how the list re-writes the message headers like that. Sorry about that. Dave
Re: Email delivery protocols / methods.
On 7/6/19 8:46 AM, Noel Chiappa via cctalk wrote: > So here's one I'm not sure anyone else will catch: TFTP has an email mode! I knew about that one. :-) Did anyone other than CSR ever use it? Not much airplane news. I've spent some time chasing down wheels and brakes for the Galaxie. The designer is planning to use hubs and brakes designed for trailers and farm implement tires on his. I was preferring more aircraft parts so I went off to find what I could in that direction. It was more difficult than expected but, in the end, I have a plan that I think will work well. The final part is axles and the designer says that with the specs I've found, he can machine up what I need. Been hearing more interest in running a KiCAD class at the MakerSpace so the past few days I've been putting together a more detailed outline of what I want to do there. One of the things I came across is "back annotation" which is something I've wanted a few times. This is where I do design-work on the circuit board and push that back to the schematic. Where I've wanted it in the past is in wiring up connectors or the LEDs on the indicator panel boards. In many cases I don't particularly care which goes to where as far as the electronics go but I want to make my life easier with the board layout. On the QSIC I've had that with wiring which bus drivers go to which bus signals and I will have it big time with wiring between the FPGA and the bus. Except for a couple signals that need to go to clock inputs on the FPGA, the rest all just go to any old I/O pin. Need to go learn this back annotation thing before starting that. I have tinkered with the QSIC circuit board design some more and have the bus drivers all routed. I didn't know about back annotation so I just did that by hand. That is, I look at the circuit board to see what signals are crossed and flip back to the schematic to swap signals around and then back to the circuit board until everything routed easily as possible. It was a pain but it's done and seems like a good job. I've also taken a stab at routing the signals from the FPGA to the memory chip. That's a new and interesting challenge. I've almost been able to do it with a 4-layer board. That plastic supply place that I'd talked about? Turns out I had a brain fart reading their webpage and it's not in New London like I was thinking but Londonderry. That means an hour and a half drive rather than a half hour drive. Sigh. At least it's still in the state. I heard a bit more from Greg up in Kantishna. He had an AVM and a small brain bleed but says it's all fixed up now. Still, he's grounded for at least a year and was asking about fill-in pilots. I thought about it some and decided that I could go up later in the summer say August sometime, and then finish out the season. He'd put the work out to a bunch of people and, last news I had, he was covered for now. And, holy crap, there was another accident in Ketchikan. No fatalities on this one, fortunately, but it was the company that shares the dock with us so I almost certainly know the pilot. Damn. They'd just rebuilt that plane last winter too. I hope your summer is going well and you got lots of wood out of that tree that almost crushed your house. Dave
Re: Email delivery protocols / methods.
> From: Grant Taylor > How many different protocols / methods can we collectively come up with > for how email can be transferred?' Hey, this is the classic computers list, so you should only list early stuff, (say pre-1990), and leave out all the modern crap (but I repeat myself). So here's one I'm not sure anyone else will catch: TFTP has an email mode! Why? Well, FTP is gargantuan (compared to TFTP) and needs a working TCP to boot, so if all you have is a working TFTP, and no email... Noel
Re: Email delivery protocols / methods.
On Fri, Jul 5, 2019, 16:05 Grant Taylor via cctalk wrote: > Here's pot stirrer for a holiday Friday afternoon: > > How many different protocols / methods can we collectively come up with > for how email can be transferred? > > I'm primarily thinking about between servers (MTA-to-MTA). But I'm also > willing to accept servers and clients (MTA-to-MUA). Where you can / > could run at least one server yourself. > > · SMTP(S) > · UUCP (rmail) > · MMDF > · X.400 > · Microsoft Exchange proprietary protocol > · Novell GroupWise proprietary protocol > · Lotus (IBM) Domino proprietary protocol > · FidoNet (FTN) > · BITNET > · Direct file access - group Post Office > · Direct file access - mail spool > I have vague memories of batch email transfer utilities from the BBS world. They were readers and/or transfer agents, but I imagine some had their own transfer protocols and file formats. The only two I can recall at the moment were QWK and Blue Wave. This probably has some tie-in to FIDOnet as well. In Tedium, j >
Re: Email delivery protocols / methods.
On Fri, Jul 05, 2019 at 03:05:32PM -0600, Grant Taylor via cctalk wrote: [...] > How many different protocols / methods can we collectively come up with for > how email can be transferred? I use rsync (over ssh) for transferring between a couple of my mail servers. It is perhaps one of my favourite pieces of software and I must have shifted many hundreds of terabytes with it by now. Andrew Tridgell's well-earned PhD thesis where he describes rsync and the related technologies he invented is, unlike most theses, actually readable and quite interesting if you're into that sort of thing.
Re: Email delivery protocols / methods.
Grant Taylor wrote: Here's pot stirrer for a holiday Friday afternoon: It's not a holiday in most of the world, including where I am, however... How many different protocols / methods can we collectively come up with for how email can be transferred? I'm primarily thinking about between servers (MTA-to-MTA). But I'm also willing to accept servers and clients (MTA-to-MUA). Where you can / could run at least one server yourself. · SMTP(S) · UUCP (rmail) · MMDF · X.400 · Microsoft Exchange proprietary protocol · Novell GroupWise proprietary protocol · Lotus (IBM) Domino proprietary protocol · FidoNet (FTN) · BITNET BITNET isn't really a protocol. Perhaps you mean NJE which was the protocol used to implement the BITNET and related networks? Although I think BSMTP (batch SMTP) was usually used to transfer mail over NJE networks. (Speaking of which, anyone want to join an NJE network?) · Direct file access - group Post Office I'm not sure what this one is. Does it refer to POP/POP2/POP3? · Direct file access - mail spool I have no idea what this one is. "Mail spool" could mean mean all sorts of different things on all sorts of different systems. Another one was the coloured book protocol used between academic establishments over X.25 networks in the UK and Ireland and probably elsewhere, Grey maybe, I forget which, probably for the best. Then there is DECnet and/or Mail-11 depending on what level of protocol you are talking about. And phonenet which I often heard about but never saw. I worked for an email provider for about 15 years. We used just about every protocol you can think of to transfer mail to customers, including those already listed plus Kermit / X/Y/Zmodem / Blast (a file transfer package few seem to have heard of) wrapped up in protocols we came up with ourselves which often also used stuff like Zip to compress the data for transmission. We used them to feed mail into all sorts of email systems long since come and gone, for example CCmail, Microsoft Mail and Pegasus Mail, to name but three from the 1990s. Perhaps it would be easier to come up with a list of protocols that were never used to transfer email? Fred! Help me out here! Regards, Peter Coghlan -- Grant. . . . unix || die Chris Long wrote: This is tedious. Maybe so but it's not as tedious as your response. Btw, are we related? There are Longs in my family tree. Regards, Peter Coghlan.
Re: Email delivery protocols / methods.
On 7/5/19 5:28 PM, Dennis Boone via cctalk wrote: > > · FidoNet (FTN) > > As long as we're being silly, this isn't really one protocol. There are > a number of different ones, which can probably mostly be characterized > as thin wrappers (FTS-0001, Yoohoo(/2u2), etc) around common file > transfer protocols (zmodem, xmodem, and others). > Well, if the idea is to get that silly, UUCP isn't one protocol either. And, technically. it isn't for moving email at all. Like FTP it is for moving files. It is what happens after the files have been moved that makes email, email. bill
RE: Email delivery protocols / methods.
These days Microsoft Exchange uses SMTP Dave > -Original Message- > From: cctalk On Behalf Of Grant Taylor via > cctalk > Sent: 05 July 2019 22:06 > To: cctalk > Subject: Email delivery protocols / methods. > > Here's pot stirrer for a holiday Friday afternoon: > > How many different protocols / methods can we collectively come up with > for how email can be transferred? > > I'm primarily thinking about between servers (MTA-to-MTA). But I'm also > willing to accept servers and clients (MTA-to-MUA). Where you can / could > run at least one server yourself. > > · SMTP(S) > · UUCP (rmail) > · MMDF > · X.400 > · Microsoft Exchange proprietary protocol > · Novell GroupWise proprietary protocol > · Lotus (IBM) Domino proprietary protocol > · FidoNet (FTN) > · BITNET > · Direct file access - group Post Office > · Direct file access - mail spool > > > > -- > Grant. . . . > unix || die
RE: Email delivery protocols / methods.
This is tedious. -Original Message- From: cctalk On Behalf Of Dennis Boone via cctalk Sent: 05 July 2019 22:29 To: Grant Taylor ; General Discussion: On-Topic and Off-Topic Posts Subject: Re: Email delivery protocols / methods. > · FidoNet (FTN) As long as we're being silly, this isn't really one protocol. There are a number of different ones, which can probably mostly be characterized as thin wrappers (FTS-0001, Yoohoo(/2u2), etc) around common file transfer protocols (zmodem, xmodem, and others). De
Re: Email delivery protocols / methods.
> · FidoNet (FTN) As long as we're being silly, this isn't really one protocol. There are a number of different ones, which can probably mostly be characterized as thin wrappers (FTS-0001, Yoohoo(/2u2), etc) around common file transfer protocols (zmodem, xmodem, and others). De
Re: Email delivery protocols / methods.
On Fri, Jul 05, 2019 at 05:09:13PM -0400, Dennis Boone via cctalk wrote: > > · SMTP(S) > > FTP was used before SMTP existed. yep ;) > > De -- - d...@freebsd.org d...@db.net http://www.db.net/~db
Re: Email delivery protocols / methods.
On Fri, Jul 05, 2019 at 03:05:32PM -0600, Grant Taylor via cctalk wrote: > Here's pot stirrer for a holiday Friday afternoon: > > How many different protocols / methods can we collectively come up with > for how email can be transferred? > > I'm primarily thinking about between servers (MTA-to-MTA). But I'm also > willing to accept servers and clients (MTA-to-MUA). Where you can / > could run at least one server yourself. > > · SMTP(S) > · UUCP (rmail) > · MMDF > · X.400 > · Microsoft Exchange proprietary protocol > · Novell GroupWise proprietary protocol > · Lotus (IBM) Domino proprietary protocol > · FidoNet (FTN) > · BITNET > · Direct file access - group Post Office > · Direct file access - mail spool > > FTP > > -- > Grant. . . . > unix || die Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db
Re: Email delivery protocols / methods.
> · SMTP(S) FTP was used before SMTP existed. De
