I have a PHP web app that is going to send out about 1,000 emails. I would love to test the performance beforehand. Is there any kind of service that provides dummy email addresses to send to, for this kind of testing? I can't find anything that's not just a general bulk-email service. The key here is I just want dummy addresses to send to.
If you have the ability to just purchase a domain name from a hosting service, I know at least 1&1 gives you like 2500 email addresses per domain so you could literally spam yourself to death and not worry about any other 3rd party. You can pick up a domain name for like
When you say "test the performance", do you mean you want to know about your deliverability rates, or how your emails look?
Deliverability Rates
This is entirely dependent on your SMTP server and the reputation of the IP that it will be sending from along with your domain's SPF records and the content of your email. To maximize this, I would recommend using a marketing email service such as MailChimp or MadMimi.
Appearance of Emails
You could always just send yourself a test email to see how it looks. An alternative is to use a service like PostageApp that has a built in template designer that has both an easy email preview function and a test send email function.
(Full Disclosure: I am the Product Manager of PostageApp.)
If you use "Post Hoc" you can send email to an unlimited number of email addresses. Post Hoc acts like an SMTP server, and receives the email messages that you are sending, but it does not forward them on anywhere. You do not need to set up any email inboxes ahead of time, so there is no problem if you have 1000 different unique email addresses. They do not need to be from a single domain -- you can use any email address you want. It stores the email messages received so that you can inspect them if necessary. You would run it locally so that there is no concern about network problems, and it is very low overhead since it does almost no processing of the email. This way, the performance measure will be mostly the sending side processing. Best of all, it is open source and freely available:
Find it on GitHub: GitHub for Post Hoc
Also see the blog post: PostHoc: Testing Apps that Send Email
Related
We are hosting customer data on behalf of companies/clients, and one of our tasks is to send out a very specific transactional email from us (with our email address as sender and reply-to) to clients customers.
We are trying to move away from storing the personal part of a customers data, including his email address. Of course, in order to be able to send out an email to a customer we need to at some point have access to the email address, but in our view it's a step in the right direction to retrieve the email address from the client during a session instead of retreiving it from our own database.
The problem now is that our unwillingness to have email addresses stored anywhere rules out using email service providers like Sendgrid. Instead we need to send out lots of emails through our own server, and this might hurt deliverability. I've been looking for a kind of "self hosted Sendgrid". One who will enable us to send bulks of emails, and one we can tweak to not store the sent emails.
One solution I've found is sendy.co who defines themselves as:
Sendy is a self hosted application that runs on your web server.
This sound promising, but then I read that emails are sent through Amazon's cloud:
Sendy uses multi-threading to send emails via Amazon SES.
I suppose this leads us back where we started, because then Amazon is storing the email addresses.
As I understand, the high deliverability that ESPs achieve is not only caused by state-of-the-art email headers, but also by their servers being recognized by Google/Gmail, Microsoft and other email hosts. So maybe a high deliverability just isn't possible without an ESP. But is there an alternative approach that lets us acheive relativly high deliverability without needing to involve a 3rd party server to do the sending?
The reason that people tend to pay for this service is because it is reasonably difficult/complicated/time consuming. If sending this email is a core part of your business, you'll want to hire a deliverability engineer to handle this. If it's not, I'd start by contacting the various transactional ESPs and see if you can find one that has an enterprise offering they're willing to tailor to this use case.
I think that I'm a little late to this. I hope that you figured out your question by now.
If you haven't then:
One alternative that you can try is to host your own server with an on-premise option. I would check out SocketLabs Hurricane MTA.
SocketLabs is a cloud ESP, like Sendgrid. But they also have a powerful on-premise option.
https://www.socketlabs.com/blog/introducing-hurricane-mta-3-0/
I created event registration web sites (you can imagine something like http://www.eventbrite.com/), which allow users to subscribe for event updates. When subscribed, we send mass emails (with the same content) to those users.
It was ok before, but recently I noticed that GMail always put the email into Spam folder.
As any texts would always go to Spam folder, I suspect that my domain was blacklisted by Gmail.
1) Is there a way to request google to put my domain into the whitelist?
2) Let's say it can't and I decide to register for new domain.
Is there a way to avoid the mass email to be marked as spam by Gmail? (may be something like what Facebook email notification do?)
Yes, don't send mass email :-) If you really want to avoid being considered a spammer, send out emails with less recipients, and don't swamp the mail server with them. Let's say, for example, you have thirty recipients for a given update. You can send out emails with one recipient every minute for a half hour.
Now the numbers may be different (and will of course depend on the success of your site) but the basic theory will stand up for quite a while.
As to how to get yourself whitelisted in GMail, that's really up to the recipient. They can usually do it by simply adding your email address to their contact list.
Keep in mind whitelisting there refers to individual GMail accounts, GMail itself does not whitelist IP addresses.
It does blacklist them if you misbehave but that generally means you get delivery rejects when trying to send. The fact that your messages are going in to the mail system and being delivered to spam folders indicates that this is an account-based thing, not a global GMail blacklisting of your IP/domain.
In any case, the place to report problems for GMail delivery problems is here.
As a school, we send out mass emails to our parents about events and issues. There's no way we have the time to spend sending out one email per minute. What we did was sign up with AOL as a business account, and we are allowed to do "bulk mailings" until they get multiple complaints. However, gmail clients usually have to list us as a valid sender or else those emails end up in spam folders. Works the same for clients using college alumni accounts from edu addresses. Gmail is the only one who regularly gives us this problem for our recipients on their email servers. We let parents know at orientation that they will have to specifically admit our emails via some setting on gmail.
I am build a tool that initiates an SMTP transaction with a domain to see if (a) that domain can receive emails and (b) the desired address exists on that domain. I will be batching large groups of email addresses (10,000+ at a time), but I don't want to bombard the server and get blacklisted. Are there guidelines for how often is it safe to communicate with an SMTP server?
I know about the VRFY command, but it is not implemented across the board. I plan to attempt to use the VRFY command and fall back to using,
MAIL From:<user#example.com>
RCPT To:<first.last#example.org>
QUIT
to see if the message will be deliverable. Again, are there guidelines on how often I can initiate an SMTP transaction like this on a domain?
Edit:
The purpose of this is to create a tool that my organization can use to (a) clean some bad emails from several largely inactive lists so that we do not have to pay our email delivery system to send potentially thousands of emails that will bounce, and (b) check an email when a user subscribes to a list so that we reject emails like aoghuifdgsiuvb#gmail.com.
First of all, spamming is bad. Always ask user wheter she wants to receive newsletters.
"Unsort" mail addresses by domain, leaving the "distance" between e-mail addresses with same domain as big possible.
I think it's not the programmer's decision. There should be a config value which tells a minimum amount of time between two mail sending to the same domain. You should set up a limit also for that config value, avoid setting it to zero or low value.
The only universal guideline I believe can be offered is "don't do this". If you behave like a spammer, you will be treated like a spammer. In the optimistic scenario, sites will already have controls in place, and silently throttle or block you. In less ideal scenarios, they will initiate actions against you on the (reasonable) assumption that you are collecting addresses for a spam list.
A better soluton would be to actually follow through the whole SMTP session, sending a user an email with a verification code/link. This has the advantage of showing that the user actually has control of the address in question and it keeps you from looking like a spam bot.
Volume is not as much the issue as reputation. Let the user know you're about to send them an email in your web flow. This means they're much less likely to mark it as spam.
some hosts have clear and defined guidelines as to how many emails can be sent per hour.
So i guess this would depned onyour hostng service provider, UNLESS your hosting your own mail server off course.
Let say I have a website that allows users to send articles on that website to a friend.
The way it works is that when the "send to a friend" link is clicked a form appears and it allows users to fill in the details and an email is sent to their friend.
The user can put in a "from" email address and a "to" email address into this form and a small amount of content.
When the email is received the from email address appears in the FROM and REPLY TO.
This website also sends a great deal of its own email communications to its users.
My question is:
Is there risk to allowing users (bots, attacks etc) to use this application to send emails from my SMTP, and how great is the risk?
My assumption is yes, this is not ideal.
Is it possibly worse than "not ideal"?
I do not know about bots using your form. Should it be a problem? I don't know.. I do know they program bots to be pretty clever, using your custom forms and all.
I do know that some email servers check if the FROM email address has the same IP address as the IP the mail was sent from. So imagine I put in my hotmail email address, and the mail server sees your server, it might flag the email as spam.
In the past I've an e-card websystem. It was a small joint venture with a girl I knew. She created the (cute) cards and I build her an e-card system. The website was pretty simple. Select card, enter email address, placing senders email address in the FROM and sent the email that you would have received an e-card.
Life was good...
Until I found that my entire web server IP was blacklisted at three major spam filtering mechanisms. And that 15% of all email recipients who used to receive e-cards from my site, would not receive their e-cards, because all my emails were blacklisted as spam from the get go. We have receive many many emails from angry "customers" demanding that their e-cards did not arrive. (I still find it funny how some people demanded the service, especially since it was a free service, go figure). My automatic reminder function was telling them the e-card still were not viewed, and they perhaps mistyped the email address, so that might have ticked them off :P
It was pretty annoying for my other customers as well, since they relied on sending out played newsletters and such and calling me that over 20% of the customers did not receive the newsletters.
Sending e-mails is hard. You should also check out Jeff's blog about this. So, learn from my mistake, and please put an email address associated with your email server in the FROM. This will spare you a lot of headaches ;)
yes this is definitely not ideal if this is a public website that any bot can access. but there are easy ways for you to limit spam use.
have your code limit any email
address to send ~50 emails a day and
only ~10 an hour based on your
needs. a bot would probably try to
send a million at once so limit them
on an hourly and daily basis.
store every email communication in a
database and come up with a good
program to monitor the most active
email senders. if you can verify
that an email is trusted, then let
them send as many emails as they
want
think about this site itself, it has very defined actions and reputation guidelines that limit you until you have proved you are trusted.
It may depend on whether you do any authentication to determine who's allowed to send emails. If the user has to be logged in to send articles, then you're probably fine. Bots will fail because they'll never be logged in.
The risk will increase the greater traffic you get to your site, and yes it's probably less than ideal. Unprotected, a bot will inevitably find your unprotected form, and start sending emails from your server.
There are some pretty easy solutions though, the most common probably being to implement something like Captcha
Fairly safe. I assume you do check the "From" address, if only by sending it one (standard!) mail first and asking the owner of that email address to confirm they are really humans ? This prevents most bots from finding and abusing your form. Of course, a directed attack with a human responding to your verification email will still allow spamming. But you've got a much better trail if you have received at least one reply from the alleged "From" address.
However, I don't think this will work reliably. The introduction of techniques like SPF will mean that mails from "example.com" will only be accepted if they originate from an outgoing SMTP server in the *.example.com domain. If you're faking emails with From: addresses #example.com, the receiving SMTP server will see that you are in fact not part of *.example.com and reject the email - and probably blacklist your IP range for good measure.
Given multi-tenant application, How are vendors implementing email notifications from an email account setup and programming perspective:
Sending emails could come from a generic account: eg notifications#VendorName.com or noreply#VendorName.com, this seems reasonable considering reply addresses and lilnks can be contained within the email contents.
Receiving Emails: How would an application receive email, for instance; to generate support tickets or assign comments in an email to a project/task. I have seen ID's within the subject and some reply to addresses containing the account name eg: notifications#AccountName.VendorName.com
I realise one can programatically connect to a pop3 server and receive emails and look for the IDs with the subject, but is there a way of setting up and receiving email to a single pop3 account from multiple sub-host name email addresses (not sure on terminology there) eg: noreply#AccountName1.VendorName.com or noreply#AccountName2.VendorName.com and check the Account Name from the address? (similar to checking subdomains on a URL)
Any practices, experience, comments or sughestions?
(not sure its relevant, but using C# asp.net-mvc and services etc)
For sending notification emails, we have a notification send to address associated with each account and simply send from our domain to that address. Our from address is monitored and replies end up in the CSR work queue.
For inbound emails, we use FogBugz (from the makers of Stack Overflow) for case tracking. That accepts new cases via email (e.g. cases#mycompany.com). Tickets are auto-created from the email. My only complaint there is that the customer needs to check an obscure link for case updates (no "my cases" web portal, but maybe that will come out in an upcoming version of FogBugz).
We have a custom field in FogBugz to indicate the customer the ticket is from. We could theoretically write a plugin to FogBugz that auto-assigns that using the senders domain, but I guess the CSR's haven't complained loudly enough yet :-)
We (at muHive) are an inbound email/social conversations management product. If you are looking at a handling inbound email or social media conversations from customers, we have an impressive toolset.
For our own outbound needs, the simplest way is to use an Email sending API. Don't bother with SMTP sending by yourself. We use Amazon SES and have also tried Sendgrid which gave us additional benefits like delivery status and email parsing.
There are two ways in which you can handle multiple accounts to a catch all email address. If your target system can differentiate between different customers and assign tasks to the correct representatives based on either the content/sender, ask all your customers to send an email to support#company.com.
As you rightly said, you could also create *accountName_support#company.com* email addresses and use different accounts on whatever CRM/Support solution use to manage these emails.
Another approach is to have your customers send you an email to support#company.com and you use a rule based system (like muHive) to forward these mails to the appropriate account executives based on the customer/account who sent the mail.