I have an ec2 micro instance running Centos on which I deploy my projects for testing purpose. Lately I developed a system which sends users email upon some events using sendmail. As I am the only one who use the system, the amount of emails sent per day is less than 50 and they are typically very simple emails.
After a few days I notice that the emails get delayed a lot after I issue send command, sometimes up to 15 minutes, and when they come, they come in batch (that is, several emails are delayed and then arrive at my inbox at one time). I understand there are reasons why we pay for email services like SES, but does sending email really take that much resources and why so?
Does your server have a fully-qualified domain name? Sendmail injects a delay when the sending host doesn't have a FQDN
To get one
first, in /etc/hostname, change your hostname from whatever to a FQDN like whatever.one-of-your-hosted-domain-names.com
then, in /etc/hosts, add a host entry like:
99.123.45.67 whatever.mysite.com
Reboot and try to send a mail to yourself again. Sendmail wil not delay at all.
Related
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.
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.
In a couple of recent projects, I've written an e-mail queue as a database table that is checked every minute by a cronjob. The cron script waits a few seconds in between sends.
The reason I did this was because I read somewhere that it helps your e-mail not end up in the spam folder if it's not blasted out from the same server all at once. I don't remember where I read it.
What do you think? Should I just mail things immediately or is an e-mail queue a good idea?
What are some pros and cons to this approach?
EDIT: Added last paragraph.
Do you have control over your SMTP server? If so, then there's no point in doing an email queue PHP-side. The SMTP server will already have queueing capabilities. If you're worried about blasting a particular receiving server, you can always turn on your SMTP server's throttling (if it has it), something along these lines.
I am relatively new to arena of emails. Just drilling out tutorial by tutorial about email internals. My requirement is I need to send emails and receive emails from my webhost. For this to happen, I need an smtp server(daemon) running right? I recently studied about MTAs, which are responsible for transferring emails from one host to the other. So this smtp server(daemon) acts as an MTA. And I also studied sendmail is an MTA, which boils down to sendmail runs a smtp daemon in the background. Right?
It's probably fairer to say that sendmail is an SMTP daemon than to say it runs one, since sendmail is pretty monolithic. But basically you have it right - in order to receive email, you need an MTA listening on port 25 when an incoming connection comes. There are many choices for an MTA. I prefer postfix because it's not monolithic, it has a very easy to read config file, and it has a good security model. Other good choices are exim and qmail.
For outgoing mail, you need a program that can figure out where the mail is supposed to go, and make a connection to that receiver's port 25. Once again, just about any MTA will do that for you, but some programs that want to send mail will attempt to do it directly instead of invoking the local MTA. The problem with that is that they then have to duplicate all the things MTAs give you, such as knowing how to fall back and retry when the mail receiver can't be reached.
You need to run daemon to receive emails and to resend emails if they failed to be sent for some reason.
To send them, you just invoke sendmail which will connect to the destination's sendmail (which, of course, runs as a daemon), send you mail and exit.
If you sending this from a website, you may use mail functions of your scripting language, because spawning a process is quite costly thing under a heavy load.
I have to make a newsletter sending utility application which will collect the list of subscriber from our central database and send out the newsletter. I've considered the possibility to be blacklisted due to flooding if I just flush out all emails at once, so I decided to go on a desktop-based softwer which will email those slowly.
my question is
what is the max emails per hour that may be addressed to the same email domain (recipient/incoming server)?
or what should be delay between 2 e-mails to the same server for it doesn't consider it flooding?
whichever of the above applies more appropriate to the real-world of mail servers configuration...
thanks
I make Thread.Sleep(2000) after every 2 mail
It's really going to vary by configuration, so there's not necessarily a one-size-fits-all answer. You might want to check with your ISP - it's probably them or their upstream that you'd need to worry about.
Since you're sending a newsletter, could you add multiple recipients via BCC rather than individual messages? That should be less "abusive" to all concerned.
I've implementing sending to max 600 e-mails per recipient domain. That seems to be working fine for some time now and sounds like an OK solution.
Still, some SysAdmin insight on this would be appreciated.