I work for a company that builds embedded systems and we are currently developing a system for residential consumers, our primary focus until recently has been industrial and commercial applications.
One feature of this product is the ability for the device to send emails directly. The problem is the SMTP library is merely a client (as it should be) and thus requires configuring to connect to a mail server.
There is currently a debate going on as to whether we should be providing the mail server configuration information out of the box. At the moment the debate has split our team pretty much between the developers and management.
The developers think it will be too onerous for the "average" user to provide the FQDN or IP of the server, port, user, password and "from" address. Therefore, it would be preferable to only require the user's email address for the configuration to be complete.
Whereas management is worried about resource utilization (of course everyone is hoping for millions, or at least thousands, of users for our system!) and a "nefarious" user stealing the information we provide and using it for illicit purposes; while the developers don't think this is likely, as management pointed out, it would only take one spammer getting a hold of the account information and then we would be forced to shut it down for everyone.
The current compromise is to provide a unique email account for each device simple for relaying emails from our product to the user's email account. Obviously, this creates a management nightmare particularly because we are using a 3rd-party email hosting solution at the moment and can not automate the creation of these emails. Management does not like that fact that we have designed everything else to be automated and then throw in a nice big speed bump by manually creating each email account and then manually configuring each device to use this account.
Of course the developers suggested bring the email service in house but that creates other problems that we can not afford.
Which leads me to my question for the community, have you ever dealt with this problem? What solution did you decide upon? Why was that the best solution for you?
Since management is worried about a "nefarious" user free-riding your company's email service (besides that thought isn't that absurd) the only chance you have to not force people to go thru the hassle of configuration or to not burden you guys with manually creating accounts is to provide each client with a unique ID. This ID will allow you to shut down the service for the mallicous user.
One way to do this would be to configure each client to embed a unique ID in the header of every email. See this question. On the server side you would then have to implement a blacklist and check every email's header against it.
That's all, without further knowledge of your tech-stack it's impossible to provide a more detailed answer.
Related
Microsoft Live Custom Domains are now shutting down. I have been using this service for e-mail hosting for all my Microsoft Azure Websites, but now it is gone and no viable replacement is in sight. Do you have some idea what alternative approach exist for hosting multiple mailboxes for multiple websites hosted on Azure?
Your cheapest option is to have one (single) google apps account which will cost you around $5 per month. Make it something very general like mail#yourdomain.com. Then in the google apps dashboard make it a catch all address. This will make the single inbox catch all email for accounts such as Sales#, support# bob# or whatever at your domain.
Then you can set Gmail filters to sort (label) each incomming message based on who it was sent to. For example you can have messages sent to frank# automatically labeled as frank.
Next you want to create regular old gmail accounts for all of your individual users. I am going to follow the example of creating a box for frank#company.com for this instance.
Create Google Apps primary account (catch all) as mail#company.com
Create Gmail account for frank.company#gmail.com (regular gmail account)
Create filter rule on Google Apps account for all messages sent to frank#company.com to be forwarded to frank.company#gmail.com. You can further mark them as read or delete them upon forward.
In the frank.company#gmail.com create a sending alias as frank#company.com. Google will give you a 4 digit code, and now when logging in as frank.company#gmail.com i can both send as frank#company.com and recieve all email since its forwarded to this account.
Also make sure to set default reply:to addresses in case you send from the frank.company#gmail.com address.
Using the technique above you can get all the benefits of having a pro google apps account (dkim, spf, 25gb inbox) and with a little bit of configuration you can setup multiple gmail accounts which run off the single account. We use the technique above and it works flawlessly. The only thing that doesn't work is mailbox delegation, which is not that great.
If you wanted to save the $5 you could get away with using something like GoDaddy free email forwarding, but then you would be limited to godaddys 250 message limit per day.
The approach above just works.
I feel your pain. Had to have some tough talks with many of my customers when the free Google Apps option was discontinued.
I found two routes:
Find a hosted Exchange type solution. This has the advantages of any hosted solution. It is managed for you. You can get started with around 50 USD / user / year and services are provided by the likes of Microsoft, Google and Rackspace, like stated in the other answers.
(Which is the route I chose) Host your own Exchange server on AWS EC2 or Azure. Thanks to Microsoft License Mobility, you can install an Exchange license on a cloud server and provide email addresses for your customers` domains yourself. This will allow you to share the cost of the Exchange license between all your customers and if you reach the critical mass, this can save a lot compared to the pay-per-user-per-month models for most hosted solutions.
I am stil looking for a free alternative, but have yet to find one that can match the features that were available in the free version of Google Apps.
EDIT: I was thinking about this again last night and came up with another idea. I am not a Linux guy, so I would not be happy to do this for production mail server. For someone who is "bilingual" (i.e. ok with both MS and Linux solutions) or of a more adventurous nature than me, could take route 2 with a linux server and an open source mail server solution. I am sure this will lower the cost even more significantly, since you will not need to pay for the mail server licence and also per-hour instance costs for Linux servers are lower. This might even create a whole new revenue stream.
Zoho provides a Google Apps like deal for 5 users for free:
https://www.zoho.com/mail/zohomail-pricing.html
Up to five users
5GB/User
25MB attachment limit
Web access only
Email hosting for single domain
I just finished installing a mail server in Azure in a Linux virtual machine. So far seems ok.
The total cost of operation is about 10€ a month since neither Ubuntu (the OS) nor iredMail (the mail server) nor Postgres (the database) have any licensing fees.
Regarding the block on Azure IPs I do believe that most users saying that did not correctly configured their servers. And by that I mean that they didn't configured the PTR reverse DNS on Azure, which allows other mail servers to check if that IP is allowed to send and receive mail from that domain.
Also make sure you add the SPF DNS entry for your mail server. You can't blame a mail server to blacklist you if you don't minimize the risks of SPAM.
Hope this helped you.
Useful links:
IredMail Server - http://www.iredmail.org/
Reverse DNS in Azure - http://azure.microsoft.com/blog/2014/07/21/announcing-reverse-dns-for-azure-cloud-services/
First of all you need to identify how much and what all services do you need?
If it is just an IMAP/POP3 Email Box, then best option is a Virtual Server or Virtual Machine with cpanel, once installed with daily backup runs good for years, you get unlimited email accounts and unlimited space !!! You can increase your VM dynamically up when you need it. Drawback is, it takes little maintenance once in a while. But most likely cpanel auto update is very stable and I have VPS running for 5 years and every year we are just increasing our disk space.
If you want calendar along with live docs editing etc, then you have to go with Google Apps which is cheaper then MS Exchange. But if you need strict Exchange kind of services, then you will have to go with hosted Exchange.
I will not recommend spending money for Rackspace or any such Cloud Email which is priced per user, which is total waste of money as they do not offer anything apart from linux server with cpanel. Those services are only for non IT people. Since you have already asked question on Stack Overflow, you can easily setup and manage cpanel based linux OS.
you could run a Ubuntu VM in Azure and set up Postfix
You can install a Free Mail Server on a Virtual Machine on Azure like:
https://www.hmailserver.com/download
I have found the same problem myself.
The only alternative in the past would have been to use Google's equivalent service, but they have also stopped it.
Realistically, there isn't a free answer to using custom domains with emails that I am aware of. Both Microsoft and Google offer paid for services, but cost per user/mailbox, per-year - compared to their free services this is a big jump in price.
Google charge £33 per user/mailbox, per year.
Microsoft are slightly dearer at £39 per user/mailbox, per year, but include access to online versions of Office for each user too.
For my situation, the Microsoft route may be the better option, based on my customer preferences but I am sure that the Google service is equally adequate.
Hope this helps. (But let me know if you find a better alternative!!!)
How many real people do you have reading e-mail? As many as you got mailboxes? If not, then I really suggest you go for Exchange Online from Microsoft which goes for $4 per user (not mailbox) per month.
The trick is, that once you've set up your domains, you create a Shared Mailbox through PowerShell and while doing so, you give the real people (you pay for) the rights to read and send as. The cool thing is, that the user does not need to do anything. The mailbox simply appears in their Outlook.
We've written a simple email client. We've some basic whitelist/blacklist functionality in there but nothing more than that. We've noticed a few emails containing malicious code and I 'assumed' the mailserver should take care of that.
So should this be a responsibility of the mail server / host or of the email client itself?
Both
If you have to use the word assume you better just go ahead and handle things on your end.
Both, either or neither.
Neither is obliged to do it. So as Robert Greiner says, you should not assume.
The reality is that if you are selling your email client, or even giving it away, you need to consider what your customers expect.
If you expect them to use your client alongside well configured, decent mail servers and standalone antivirus software, you might not need to do it yourself.
Just make damn sure that the end user knows what they are (and aren't) getting from you, and have an appropriate licence agreement.
You almost certainly won't be able to write and maintain your own antivirus updates, unless you can afford to spend millions on R&D each year, so if you are going to take care of it yourself, look at integrating with the API of an established (not necessarily market-leader) antivirus provider. You will probably need to pay a licence fee to integrate with and distribute their software.
However, my personal expectation would be to not rely on mail server and client and have my own desktop antivirus program.
Does it make sense to create a service whose only responsibility is to send emails for other services?
Let me try to express my doubts more clearly and give a little bit of context. BTW, you can ignore the term "SOA" if you like. My intent in including it was to communicate that I am talking about a distributed system that is partitioned by function.
The reasons why I am uncertain as to whether an "Email Service" is appropriate or not are:
It provides a technical function
rather than an organization
function. It doesn't compose the
email messages, it just processes
them. Would it make sense to have
the Email Service compose the
messages by responding to domain
events? Would this be beneficial or
harmful?
It seems to introduce dependencies
into all other services which
utilize it. Particularly, I can't
see how one could avoid RPCish
interactions between the client and
the Email Service. Even if you use
messaging, the messages would be of
the command style (telling the Email
Service to send an email) which as I
understand it are inappropriate for
communications between services
since they increase coupling due to
the knowledge the client has to have
about the service it is consuming in
order for it to tell it what to do.
Unless of course the Email Service
composes the messages in response to
domain events from other services
(see point 1).
It is questionable how much
"service" it provides. In other
words, isn't the SMTP server already
the "Email Service"? Of course, the
custom "Email Service" might provide
things like queuing and parsing of
delivery reports. How much and what
should be in the Email Service for
it to really be necessary?
The alternative would be to have each service within the organization be responsible for sending out it's own email messages. However, this would mean that each service would have to be dependent on the SMTP server, but is that any different from being dependent on a custom "Email Service"? It would also mean that each service would be responsible for queuing and delivery management. Is this beneficial or harmful?
In addition, the email messages are considered domain entities, meaning that the organization is interested in the messages themselves in addition to the events that initiated them and the information that they carried. This means that users will be interested in viewing the messages that were sent out within context. For example you might look at a customer's account and ask to view the messages that were sent to that customer (these messages might include: account created confirmation, order placed confirmation, order shipped notification, experience feedback request, etc.).
I apologize if my question makes certain assumptions or is unclear, but based on what I've written, can anyone suggest an approach or discuss an approach that they have taken and how it worked out? I've already looked around SO for similar questions and googled on the topic but did not find anything that really applied, but if anyone can point out any resources I would greatly appreciate it. I would also be interested in answers that point out things that I might be overlooking or misunderstanding. Any sort of discussion on the matter seems valuable to me.
It depends on the context. What is a service? Is it a technical resource or a business resource?
If you were working at a technical level, partitioning a large technical soluiton into smaller parts (separation of concerns, etc) then I'd agree that an email service might well fit into this.
If the services are business services (e.g: "customer credit check") then an email service wouldn't fit into this.
And of course there's no reason why you can have both: a "top" layer of business services, implemented by a (technical) solution (that is composed of various sub-systems and layers) which includes a collection of technical services.
What are the risks, if any, of sending out massive amounts of emails over SMTP? Specifically, this question is regarding the risks of being labelled/blacklisted as spammers of spoofers.
Our mails are legitimate, however. Our system needs to send out reminders to our corporate users on a daily basis, which may number into the thousands, say. Our worry is that with such a setup, our domain might end up being blacklisted by the receiving organisation, thus rendering our reminder service useless.
Does anyone have any information on what might be a "safe" volume of emails to send out to avoid being blacklisted? Or can we just churn out emails with abandon?
You may be able to contract a third-party organization to take care of this for you. I know there's a lot of "direct marketing" companies that will let you use their API to send mass email (newsletters, etc). They can do the work of negotiating to get off blacklists - that's what you pay them for.
I haven't used Sendloop and don't know if it has the functionality you want, but it's probably a good example.
See: How to conduct legitimate email campaigns
In your reminder service, just follow some basic spam guidelines. Identify where the message came from, why the user got it, the link to "opt-out" or discontinue the reminders, and you'll be fine. Any blacklists you do get on will certainly remove you if you have this information in your messages.
Additionally, should you get blacklisted for some reason, have another server on a different network that you can use as a backup should your primary server get blacklisted temporarily for any reason.
Oh, and one final note - usually your entire "domain" (i.e. whatever.com) doesn't get blacklisted. Specific IP addresses or specific servers are usually what get blacklisted.
As long as you're mailing over clean IPs and domains you should be fine. You say your mailings are "legitimate" so there's no reason to worry about ISPs blocking you.
However, as you also mentioned, the volume can become a challenge. Broadly speaking, sending "thousands" of messages should be a non-issue. But... hundreds of thousands, say 250K messages a day on up, is when you start to qualify as a "high-volume" sender.
Once you start sending at this bulk level, you must run a tight ship. ISP filters will look for any clue that you're a black-hat mailer/spammer and will promptly block your deployment if anything looks off.
Make sure your list(s) are spic-and-span; all bounces, duplicates, typos and honey-pots have been scrubbed-out. Your IPs have been properly warmed-up, your DNS and domains are clean and properly registered and you remain responsive to your list recipients.
Basic common sense and following through on all the tiny, simple but crucial details goes a long way.
I'm implementing a email newsletter sender service using .NET and Windows Server technologies. Are there comprehensive guidelines which could help avoiding emails being trapped by spam filters and other mechanisms?
They should cover all aspects of (legal) bulk mail sending: SMTP configuration, DNS, HTML content, images, links within content etc. A simple example: is it better to embed images or load them from a server?
It would be great if you could provide some empirical data to show the efficiency of some measures taken.
Although I don't have a definitive answer, I think this is a very important question.
Here are few tidbits I know about it
Choose a clean hosting/smtp server. IP addresses of spamming SMTP servers are often black-listed by other ISPs.
Send a simple introductory email to every subscriber, asking them to add your sender address to their safe list.
Be very prudent in sending to only those people who are actually expecting it. You wouldn't want pattern recognizers of spam filters learning the smell of your content.
If you don't know your smtp servers in advance, its a good practice to provide configuration options in your application for controlling batch sizes and delay between batches. Some servers don't like large batches or continuous activity.
Unless you have a very specific reason to host the newsletter yourself, I think you'd be much better off using a third party service. There are lots out there, and some are very cheaply priced.
It'll save you on development work
(no point in re-inventing the
wheel).
Their system will handle all
the unsubscribe link stuff that you
need to include in email newsletters
to comply with CAN SPAM laws or
whatever.
They handle the spam
reports that you will inevitably get
if you have a list of any non-trivial size.
They keep records of who signed up,
how they signed up, and their IP
address, and can present those on
receipt of a spam report to prove
that their service wasn't sending
out spam.
You can use double-opt in
(or confirmed opt in), for extra
evidence to prove that the people
you're sending emails to actually
signed up to receive them.
If you really do need to host it yourself I'd suggest you search the web for "email deliverability". Things that are known to help include properly set up SPF records, DomainKeys/DKIM, correct DNS settings (reverse DNS especially - best to just use an online service to check your DNS settings). You can test a lot of these things by sending an email to check-auth#verifier.port25.com.
It's best to avoid using spammy words in your email - always a bit of guesswork this but you some words can trip filters.
But I'd guess that by far the most important thing is to be sending your email from a trusted server that maintains good relationships with ISPs (i.e. ensuring that ISPs don't think that the server is sending out spam). This is a big reason why it's much much easier to get a third party to handle everything for you.