I am considering the possibility of setting up a simple SMTP+IMAP email server for internal use on an extra small Azure VM. When I say internal use I don't mean "used by internal users", but for use as part of a larger system and to serve the main purpose of receiving email messages for audit/logging purposes which are then handled based on rules, which trigger actions. Occasionally there might be an automatic response back.
My question is whether a simple email server can be hosted inside an Azure VM, because what I see on the Internet from a preliminary search is that Azure does not support Reverse DNS (they do assign almost static IPs nowadays though), which will then caused the occasional auto-response outgoing emails to be marked as spam.
My question is: Is that the case or is there some setup that would allow to workaround this?
Note: This is just a preliminary research type of question. I am not an administrator.
EDIT: To those who would jump in and say use SendGrid. I am not going to be sending newsletters, but mainly receiving emails. Also an Azure extra small instance is $9/month where as SendGrid Push API (which won't let let poll as I would like to) starts at $90/month which is ten times the cost.
EDIT 2: My preference is to implement a poll-based system (poll the server for new emails every X hours) rather than implementing a push+queue based system (most 3rd party servcies provide a Push API that pushes each email to a web url)
EDIT 3: I would prefer not to use a 3rd party service, because I don't want the content of the email and attachments to go through them.
EDIT 4: Look, I am not looking for an advice on how to set it up or which 3rd party service to use. What I am asking is "Is it possible to set up an email server which can receive email and send the occasional email out which won't be marked as spam due to limitations of Azure? If there are limitations - what are those and how can they be worked around?"
Answer
No.
You can't be reasonably sure your outgoing email will be delivered, as many destinations simply blacklist, firewall, or even null route all major cloud providers' IP blocks due to the heavy abuse seen from those ranges - not just from email but via other services as well.
And even if your mail is delivered today, that's no guarantee it will continue to be delivered in future.
You really do need a mail server outside of Azure (or EC2 or whatever) to process your outgoing mail, though it does not necessarily need to be a third party mail server. If you have the expertise, you could do it yourself.
When I put a service on EC2 which had to deliver to a mailing list, I found from testing that almost 3/4 of the list addresses would not accept mail from there. I ended up sending everything to a smarthost located outside EC2. Interestingly, this also improved performance...
Having incoming mail on Azure would be no problem, as the above issues don't apply.
No comments:
Post a Comment