Recommendations for sending automatic daily emails from a web service

Question

I am running a web service that is currently sending confirmation letters to new users via gtm smtp servers. Since I only get a few new users every day, this was not a problem.

I recently added new features to webapp, for which every day the user must send an individual message to each user. Think of it as regular messages that LinkedIn sends that report on the status of activity on your network. Each user message will be different. With thousands of users, this means that thousands of unique messages will be sent every day.

Edit:. Since then, I have found that these types of letters are called "transactional or relationships." Spamtacular has a good article on the difference between marketing and transactional email .

I do not think that using gmail smtp-servers will reduce it more, but I do not know for sure. I don’t know what the maximum outgoing gmail messages for each account (maybe 100 / day), but they limit outgoing mail to 500 recipients per message. I do not send any messages to 500 recipients, but I am going to send 1000 individual messages with each recipient receiving one per day.

I am interested to know all the recommendations for this (especially for Java web applications). Here are some of my thoughts and concerns about this:

• Should I set up my own outgoing mail server? If I do this, it seems to me that I will be worried about any other problems, such as preventing abuse of mail servers, tracking failures, allowing ways to refuse emails, etc. Are there any tools or services that will help with this? Maybe something like OpenEMM or services like MailChimp? But they are more focused on email marketing campaigns.
• I do not think that I myself had to handle webapp sending emails, as it is currently intended for new users. I think I should set up a separate messaging server that can access the same file / data store as webapp. Thoughts on this?
• Should I consider creating a message queuing service like JMS, RabbitMQ, ActiveMQ, etc.?
• Do I need to give users the option to opt out? Do I need to specify them as bulk messages? I really do not consider these email messages, but I am not sure what is considered suitable or suitable network text.

Any advice is appreciated. I am also very interested in open source tools or web services that simplify work and can speed things up as quickly as possible.

Thanks!

Answer 1

As for your first question, yes, you should set up your own mail server. Using gmail for this may work for a while, but they will probably close you in a short time when they see this kind of activity. You can subscribe to a business account and use the application mechanism to send messages. Here is a quota link for this service.

As for your second and third questions, it would be nice to have messages queued in a web application and sent by a centralized service, instead of the application sending messages on its own.

I usually just use the database table as a queue - the web application inserts rows for each message that is sent. The service application / scheduled task will capture new messages from the table and send them. This gives you more flexibility if you want to switch mail servers later, increase reliability if the mail server is disabled, simplify diagnostics if there are problems with recipients who do not receive messages, and the ability to resend messages. As for using JMS / MQ to do this - probably not necessary. The IMO database table used as a queue will give you more flexibility than a real JMS based queue system.

As for opt outs, YES - you have to give people the opportunity to opt out. I don’t think you need to indicate messages as voluminous.

Answer 2

On the architecture side of things, I will definitely consider decoupling the sending of email from the main service through some asynchronous message sequence (or facsimile using the database as an intermediary). Another advantage of this approach is that if the SMPT server \ network does not work, you can build retry semantics, in addition for future scalability you can implement several mail senders reading the same queue, or implement throttling or scheduling settings (i.e. Send n messages per hour) etc.