|
Curiouser and curiouser. The above quoted part matches what I'd already surmised, but the rest just leaves me as confused as ever. I was under the impression that SMTP sends mail, and POP receives it. Am I laboring under an oversimplification?
A gross oversimplification.Think about this: If an SMTP server only sends, where does it send to? The act of sending something implies that there's a receiver, doesn't it? Surely they have to both be speaking the same network protocol?! So, for every SMTP that's being sent, there's SMTP software that's also doing a receive.
SMTP, POP and IMAP are just network protocols. There are different programs that use these protocols, and each protocol has it's own role.
There's the Mail User Agent (MUA) that interacts with the end user. Outlook is an example of this, but so is Pine. And OfficeVision. And the QtmmSendMail() API.
There's the Mail Transport Agent (MTA) that transfers the e-mail from system to system across the internet, and insures that it arrives successfully. Your iSeries' "SMTP server" is an example of this.
There's the Mail Delivery Agent (MDA) that receives e-mail and stores it in a user's "mailbox" where it waits for the user to read it.
All 3 of these roles use SMTP! The MUA typically only uses it for sending out mail. The MTA uses it for both sending and receiving. The MDA uses it only for receiving.
POP and IMAP only come into play after the mail has been delivered to the mailbox, and it needs to be transferred to the user's PC so they can read it in Outlook or Thunderbird or whatever. This step is not always used, however.
Originally, users would read their mail right on the server. The e-mail software would read directly from the user's mailbox. On the iSeries, I suspect that OfficeVision worked that way. On Unix machines, they used Pine or Elm to do stuff like that.
Indeed, that paradigm is still used today with WebMail. The webmail software frequently reads directly from the user's mailbox, so no further delivery is needed, and there'd be no POP or IMAP.
Likewise, an MUA on the same box with the MTA may not need to use SMTP to get the message to the MTA. There might be a different interface that doesn't require network access.
Here's how the model is supposed to work:a) Your e-mail client (MUA) sends the message to your local, trusted, MTA. It uses SMTP to do this.
Why doesn't it just send it directly to the destination? Well, what if that computer is down? What if there's some network error in an ISP between you and the destination? What if there's a company-wide mandate that all outgoing e-mail gets scanned for viruses?
For all of these reasons, and probably many more, it makes sense for the e-mail to be handed off to a "trusted agent" that runs on a computer that's dedicated to the task of making sure e-mail gets delivered. This is what an MTA is for.
b) The MTA attemps to forward the message to the destination MTA. The person who sets up the domain name for the destinatoin e-mail address can designate several SMTP servers that will receivie e-mail for their machine.
For example, if I want to send e-mail someguy@xxxxxxx, the MTA looks up the aol.com domain, and sees that it can send to the following mail servers:
aol.com has address 205.188.142.182 aol.com has address 64.12.50.151 aol.com mail is handled (pri=15) by mailin-04.mx.aol.com aol.com mail is handled (pri=15) by mailin-01.mx.aol.com aol.com mail is handled (pri=15) by mailin-02.mx.aol.com aol.com mail is handled (pri=15) by mailin-03.mx.aol.comIt will try each of these servers until one of them accepts of the e-mail. Remember, the role of the MTA is to make sure that it gets there, so if it can't get through to any of them, it'll keep trying after a suitable delay.
When it sends the message to one of these servers, it does so with the SMTP protocol. At the same time, the server that's receiving the message receives it with (drumroll please) the SMTP protocol.
c) Then, the AOL.com MTA might need to send it on to another MTA. For example, maybe mailin-03.mx.aol.com is only a "backup" server (I don't know if it is, I'm just saying "suppose that it is.") What that'll do is receive the e-mail when the other servers are too busy. Then, it'll send it on to the ultimate destination later.
This is done with the SMTP protocol. It keeps going until it gets to the mail server that considers the mail to be "local e-mail".
d) The final destination MTA will run a program (the MDA) that will take the message and save it to the user's mailbox. Since there are many different mailbox formats in the world, the MDA separate from the MTA. That way, you can have a different MDA for different types of messages. In tools like Sendmail, you can designate different MDAs for different domains.
Everything up to this point has been done with SMTP. And that's the end of the road, if you want to read your mail from the server.
Originally, mail software for the PC worked the same way. The PC would have an SMTP server, and it would receive the e-mail and store it in a mailbox. That didn't work well because people reboot their PCs. And they turn them off at night. And they exit out of their e-mail software.
So they found that it worked better if the mailbox was still maintained on a dedicated server, but that it could be transferred to the user's PC on demand. Instead of being pushed by an SMTP server to the PC, it would wait on the server, and PC could pick it up when they needed to.
That's what POP and IMAP are about. (Granted, we don't have an IMAP server with OS/400, but I'm sure there are 3rd party ones.)
e) The mail client connects using the POP protocol to see if there's any mail in the mailbox. If so, it downloads it for the user to read.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
