I have a basic question about mail servers. Usually any general server (not necessarily mail servers) handle all kinds of related requests i.e. both direction interaction with client (like sending and receiving msg to and from client) but in case of mail servers, there are 2 different servers -- one for outgoing messages called outgoing server following SMTP protocol and another for incoming messages called incoming server following POP3/IMAP protocol. Why so? . For that matter couldn't the 2 protocols be accommodated in one single protocol to handle both direction message flow. Also, typically are these 2 servers hosted on same machine in a general business?
Because the protocols are old. In the old Unix tradition, and ignoring UUCP for now:
SMTP came first, to transfer mail between sites, and mail was read locally on the server/network using a text mode client when logged in. There was no need to fetch mail, you used the 'mail' command, and it accessed your local mail spool (a file containing your mail, sitting on the file system, that the SMTP server appended to).
Later on, came the development that people wanted to read mail on their own hosts so a protocol was invented to serve that. The POP server would read that same spool file, and allow you to download all your messages to your intermittently connected client computer. SMTP was reused for sending mail because it already existed and was easily adapted for that purpose.
These days, there are usually three servers of note: SMTP submission server, SMTP transmission server, and IMAP. The submission server is where end users of the service submit their e-mail to be forwarded onto the final host, for example the Google server a Gmail user submits their email to (on port 465 or port 587, usually, with authentication). The transmission server is responsible for delivering and receiving email between sites (eg. when Yahoo and Gmail exchange mail for their customers with each other, on port 25). And IMAP is used by an end user to fetch their email.
These three services, on large sites, are generally served by separate servers on separate hosts. On very large services, like Gmail, they are separate pools of servers.
On a small business host, they were often just one machine.
There are newer and more integrated protocols. For example, both EAS and EWS have mail fetch and submission contained in the same protocol.
Personally, I regret that almost nobody uses UUCP anymore :)
The separation of shipping, management and collection of mail has a historical, philosophical and design basis.
This is in line with the spirit of the Unix world: "do one thing but do it right" and "make everything as simple as possible".
How complex the issue of e-mail is and how much technology it covers, read here:
https://en.wikipedia.org/wiki/Email
and then see the relevant RFCs in the footnotes for details.
It is difficult to implement a monolithic program that takes into account all the nuances of e-mail and at the same time
keeping it simple (Simple in SMTP). Such a monolith would be a nightmare to develop, maintain and administer,
and the post office has changed many times since the 1970s.
As for the second question, there is no reason to use the same physical machine, but there are also no contraindications other than the amount of resources available.
Related
Lets say i install an smtp server but no backend store where emails can be stored. I do not install any imap/pop3 server either.
What would happen to received email?
EDIT : I am talking about emails for virtual users and not local operating system users
Unix/Linux system by default store incoming messages to local email domains in per OS account mailbox-files usually /var/mail/username. Some command line tools (e.g. mail) allow access to "system mailbox (file)"
I'm not 100% sure what the question means...
In a mail/interop context the answer to this is: This is a local matter. A mail (IMAP/SMTP) server has to store mail somewhere when it's received, and it has to read it somewhere when it's accessed (IMAP/POP/JSONthings), but how it's stored is deliberately not specifed. The standards cover how you talk to the servers via the internet. How they talk to their disk is not. Put differently, internet matters are standardised, local matters are left completely up to the software used.
I've implemented email blasting system with C#.net application using System.Net.Mail.
Previously, this system was implemented with VB Script using CDO.Message.
After I deployed my new system and run it for blasting(sending emails), I got the exception(Error in processing Number of messages exceeds maximum per connection) in production SMTP Server.
I know that this error is because of the SMTP server setting, but my client argues that the previous VB script can work with this SMTP Server setting.
That's why I want to know the difference between CDO.Message and System.Net.Mail, for instance, is there control of connection sessions, etc.
Please kindly advise me. Thanks.
'CDO' is a COM implementation for sending mail whereas 'System.Net.Mail' is a managed way to send mail using SMTP (which is typically a relay to another mail server). You are likely to find limitations in sending a larger number of concurrent emails with both as a server can only handle so many. Concurrent requests - similar to a highway only being able to handle a finite number of cars at any one time.
A client is moving from their old hosting to mine. They have a few email accounts on the old hosting and I want to move all the emails on the old hosting to mine. How can I do this? If I download them with POP can I then upload them to the new hosting?
The answer depends on the mail server that you are using. Yes, you can download all the mail messages with POP3, but the upload to your mail server will depend on the type of mail server. I am not aware of any mail servers that provide a tool to import mail messages.
Most mail servers store the email message in a file, and you can certainly drop the files in the folder where they are stored, but that does not mean that it will be visible, you will have to deal with how the mail server index those files.
I suggest looking at the specifications for your mail server.
If you access both accounts with IMAP (most hosts support this now) instead of POP, you can literally drag and drop the messages between folders/inboxes for the two email accounts.
Also, depending on the type of hosting they're moving from/to, you may be able to use a feature of your new server's control panel to do the importing...unless you're doing it manually on a vanilla VPS or dedicated. There are still options, but you'd need to confirm here how your new server is setup and what the old server looks like.
If you're only talking about a couple of accounts with a few folders each, you may just want to consider IMAP as your path of least resistance. The transfer will primarily depend on your own Internet connection, as most hosting companies have connections faster than yours.
Lastly, if both servers share a similar format for the mailbox, you might want to just rsync the email over to the new server (assuming you have root access on both servers) to the proper email directory. Depending on the email box format, you may be able to simply run a server command to "convert" the mailbox to the format your server is expecting.
I have a VB6 app which is used by a large number of clients.
I need to allow the clients to be able to send emails to me. In the past I have done this using Microsoft MAPI controls. However, not all of them have an email client installed, since they use webmail instead.
Is there any other method anyone can recommend which would allow them to do this?
SMTP
You can use CDO for Windows to do this if we make a few assumptions:
Your users are all on Win2K or later.
The users will never be behind a firewall blocking SMTP or proxying all SMTP port use to a corporate server.
You have an SMTP server that you have an account you can let the user-mails be sent with.
You embed the server's address and account credentials in your program.
Sometimes using an SMTP server listening on an alternate port will address the second issue, but often such an alternate port is even more likely to be blocked.
SMTP is Dying
Abuse over time has made SMTP less and less viable for automated/assisted user contact. There are just too many variables involved in trying to open some sort of "clear channel" for SMTP communication as people work harder to fight spammers and such.
Today I would be much more likely to use either WebDAV or a Web Service for this. Both use HTTP/HTTPS which is more likely to get past firewalls and usually get by most proxy servers as well. WebDAV is often more "slippery" at this than Web Services, which more and more proxies are bocking. You can also use something more RESTful than SOAPy since the traffic "smells more like" user browsing to proxy servers.
WebDAV is a Clean Option
There are even free WebDAV providers offering 2GB of storage with a main and a guest user. The guest account can be given limited rights to various folders so some folders they might post your messages to, other folders they might get data from (read only folders), etc. For a paid account you can get more storage, additional users, etc.
This works well. You can even use the same hosting for program version files, new version code to be downloaded and installed, etc. All you need on your end is an aggregator program that scoops up user posted messages and deletes them using the main user/pw.
You still need to embed user credentials in your program, but it can be a simpler matter to change passwords over time. Just have the program fetch an info file with a new password and an effective date and have the program flip the "new" password to "current" once run on that date or after.
WebDAV support in Windows varies. From WinXP SP3 forward you can simply programmatically map a drive letter to a WebDAV share and then use regular file I/O statements against it, and unmap the letter when done. For more general use across even Win9x you can build a simple WebDAV client on top of XMLHTTPRequest or use a 3rd party library.
Web Services Have Higher Costs
Just to start with you have server-side code to write and maintain, and you have to use a specific kind of hosting. For example if you built it using PHP you need a PHP host, ASP an ASP host, ASP.Net an ASP.Net host, etc.
Web Services can also be more problematic in terms of versioning. If you later update your program to provide different information in these user contact posts you have to make another Web Service as well as changing both the application and the aggregator. Using WebDAV you can just make a "new format" folder on the server and have the new program post the data there in the new format. Your aggregator can simply pull from both folders and do any necessary reformatting into your new local database/message repository format.
This is merely an incremental additional effort though and a Web Service might be the way to go, even if it is just something written like an HTML Form GET/POST acceptor.
Although this question is for VBA you may find it of interest. Sending Emails using VBA without MAPI
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
This question got me thinking, and I now realize that I don't know anything about the internals of MTAs.
What exactly does an MTA do? Everything after the SMTP protocol seems like dark magic to me. Let's say that I wanted to code a minimalistic MTA (or MDA) just for sending emails, what would I need to learn/do?
Edit: I don't actually plan on writing an MTA, I just want to understand how it works internally.
--- edit after somehow noticing you talked about possibly writing a MTA ---
To write a MTA, you need to open a server socket. When someone connects, you need to send and receive text (ascii) data on that socket in compliance with the SMTP protocol. SMTP is very chatty, so you can expect a few rounds of communication.
The initial round of communication typically tells you whether SMTP is supported or ESMTP is supported. The second (optional) round of communication is to determine security / encryption / feature support. Eventually the "client" side will ask to send a message to a particular address / set of addresses. When done, the server will indicate that it's ready to get the body of the email message. When the body of the message (and it's optinal attachments) have all been transmitted, the MTA will tell you it received the message fine. At that point in time, the MTA will act as a client to other MTAs discovered via DNS MX records to get your email closer to it's destination MTA which will copy it into someone's inbox.
So an MTA is needed because mail delivery on the client side is the equivalent to handing a physical letter to a post office. Post offices are responsible for inter-postoffice routing (which parallels to MTA-to-MTA transmission). The destination Post office is then responsible for delivery of the letter to the post office box or home address (which parallels one's computer inbox).
They don't call it e-mail for nothing.
--- original post follows ---
A MTA will accept a mail message, see if it can forward or deliver it, respond if it can be forwarded or delivered, and then forward or deliver it if it indicated it could.
How the message gets closer to it's final destination usually has a bit to do with DNS. MX (mail exchange) records in DNS indicate servers which are responsible (or at least closer to the responsible server) for particular email domain names. It is not possible to fully understand how a mail message gets closer to it's destination without understanding how DNS works.
A MTA typically looks at the delivery address, and either is configured to be the "end point" of the email address's mail domain, or knows that server XYZ is one hop closer to the email address's mail domain. If it's an endpoint, it will copy the message from the wire into someone's inbox. If it's relaying it will "forward" the message to the next MTA.
Here ya go: http://en.wikipedia.org/wiki/Message_transfer_agent
Quickly, the MTA receives the raw message, decides where it's ultimate destination is, and then forwards the message on to that destination.
A very simple MTA can be written the delivers only to local inboxes. The MTA is an "easier" part of the system to write because you can behave badly but still be functional, so your interoperability with other systems is less of an issue (that's where much of the complexities of email lie nowadays, that and spam/virus checking).
The real contract of an MTA is simply that if you accept the message from the system sending it to you, you accept responsibility to deliver that message. Thus, when that socket closes with an acknowledgement of acceptance, the delivering systems job is done and it's all in your hands.
If you happen to do a crummy job, mail is lost, and it's your problem. But it's still fun to play around with.
Edit: The original tutorial I linked to has gone 404. Here's another that's ok: https://troubleshootguru.wordpress.com/2014/07/06/mail-server-components-mta-mda-mua/
In short, a MUA is a user client that uses SMTP to send an email to an MTA. The MTA is a server that is responsible for routing the MTA to its destination. If that destination is another server, the MTA hands the email to an MDA. The MDA is a client on the server that uses SMTP to forward the email to the other server, which is also an MTA.
So what do you need to learn? If you want to write an MUA or MDA, you need to learn how to open a socket to another computer, send SMTP commands, and receive SMTP responses. If you want to write an MTA, you need to learn how to listen for socket connections on a port, receive SMTP commands, and send SMTP responses.
If you like Java, try the code on this page as a starting point for a client.