Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
[Our website] is very dependent on being able to successfully send email to its members. We are currently having trouble reaching all our members, especially hotmail users.
What do you recommend we do to improve our sending of email?
We are sending heavily user customized emails. So a third party solution would need a good api
to support this.
Possible solutions:
Would sending email through the app
engine help for delivery rates?
Does returnpath help? http://www.returnpath.net/
Update:
Some good comments on how to improve and test our own email sending capabilities. Another option would be a third party solution.
We're sending updates on your networks activities, registration emails, new comment emails, new follower emails these type of things. Especially your networks activity is highly individual and problematic with most third party emailing solutions. Would need a very flexible email solution.
Are there sufficiently capable solutions out there?
We had a similar issue a while back.. You probably want to read up on Microsoft's Sender ID:
https://www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx
and look at the link called "Sender ID SPF Record Submission Form".
Postmark and Sendgrid seem to offer a very decent api to use for sending email and improving deliverability. As a bonus stats are also handled by them.
1 ) using shared ip
2 ) sending more than 1000 email per hours may cause Spam
3 ) sending from root server without SMTP login may cause this problem
4 ) contents email has links from websites blocked from RBL ( Real Time Blacklist )
5 ) ...
I'd in general be pessimistic about the IP reputation of platform-as-a-service type offerings. Testing Google AppEngine is on my to-do list, but I've there's been much talk about Amazon EC2 presenting a real problem -- these products are not very efficient preventing use by spammers, and reputation is taking a hit.
As for the practical steps of setting up outbound email, Jeff Atwood has a very nice and nearly comprehensive article on his blog.
What I'd certainly suggest is:
Make sure your sending IP has a reverse DNS.
Check your IP reputation for example at senderscore.org (though that's heavily US centric)
Make sure bounces are handled on your side, and postmaster#your.domain is reachable
Set up SPF and DKIM. SenderID if you want to.
Sign up for all feedback loops at major mailbox providers / ISPs and act on spam complaints -- if your user complain, you're doing something wrong. Also, set a "friendly name" on your From: address, as some mailboxes will only display the local part -- " Update" is friendlier than only seeing "automatic" (Gmail does this).
Watch the volume you send. If it's high from the start (>1000s/day to each major ISP) you may get blocked outright.
You'll find a lot of deliverability tips, most of the time from interested parties (email service providers). A relatively reputable resource is deliverability.com, backed in part by Return Path. Of course, going with a commercial email service provider might be a solution for you, but your use case is quite specific and you'll need real-time individual messaging, not marketing newsletters, if I understand you right.
I worked for a company that re-sold Return Path's tool -- so take this with a pinch of salt: It' won't help you get delivered. It can, however, be a valuable tool tracking down where your problems are. It is on the other hand expensive, and hiring a specialist that can go through your specific case might be more affordable. Or reading a lot and experimenting a lot yourself.
#chryss does a great job pointing out the important factors that need to be taken into consideration:
-- reverse DNS, sender reputation, list management (ie, cleaning lists of addresses who have marked your email spam, invalid addresses, etc and keeping track of hard and soft bounces and acting accordingly to those events), SPF records, DKIM signatures, ISP feedback loops, ISP rate limits. Also, email content is important to keep in mind.
Generally speaking, this is all pretty complicated and annoying stuff to deal with, especially as your email volume increases.
In terms of IP reputation with PaaS systems, the key thing to remember is this:
-- if you share an IP with someone who earns a poor reputation (say, a spammer on EC2), that reputation will negatively affect your deliverability. On the other hand, if you send from a dedicated IP, you have the opportunity to earn your own reputation - if you are a good sender, follow best practices, and your customers want the emails they expect to receive from you (which they should since it sounds like you are sending mostly transactional emails), you will maintain a great reputation and should enjoy good deliverability (granted all of the technical stuff mentioned above is taken care of).
We generally keep an eye on deliverability "chatter" online, and send out all the cool/useful stuff that we find on a daily basis through our twitter feed -- feel free to follow us: twitter.com/sendgrid. We are also beginning to ramp up our own blogging, so you can join the conversation if you like: blog.sendgrid.com.
If you want a comprehensive solution without having to do a lot of troubleshooting/fact-finding, just check out SendForensics.com. Disclaimer: I am affiliated with the company.
Regards,
Russ
Deliverability issues generally happen if there is something wrong with any or all of the following elements:
Email Content
Server Configuration
Email address and Domain reputation
IP address reputation
More information here
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
The mail server I manage is clean according to 92 blacklists checked by MXToolbox.
But ...
host mx.ecentral.com.cust.b.hostedemail.com[64.98.36.4]
refused to talk to me: 421 4.7.1 Service unavailable; Client host
[My Server IP] blocked using tms.urbl.hostedemail.com; Your IP has been
sending too much spam
How does one get off of this list? What puts one on their list but not on any of the ones with more obvious rules? Is hostedemail.com some kind of rogue provider?
Thanks!
What's crazy about this (to me, anyway) is that both hostedemail.com and urbl.hostedemail.com have no A records and no website, not even a redirect or a single page that would give people the bare minimum information about their blacklist or service. That's not how professionally run blacklists are managed these days.
My users are getting this:
host mx.DOMAIN.org.cust.a.hostedemail.com[216.40.42.4] refused to talk to me: 554 5.7.1 Service unavailable; Client host [1.2.3.4] blocked using urbl.hostedemail.com; Your IP has been manually blacklisted
It's the reference to manual blacklisting that flummoxes me. None of my servers are in any of the blacklists checked by MxToolbox (and like most mail admins, I work hard to keep it that way), so if someone has taken the time to manually add the IP address of one of my servers to the list then this sounds as amateur as my own manual blacklist I use on my servers when I have no patience waiting for a spammer to be shut down or blacklisted. And it has been there for at least a week; I haven't bothered checking last week's logs, as a week is long enough to determine whether or not a server is (still) sending spam.
After some research I found this post:
What does this error mean when emails are bouncing back to sender?
That led me to:
https://fbl.hostedemail.com/
... which is actually a branded CNAME for fbl-opensrs.app.returnpath.net that leads to:
https://fbl.returnpath.net/
So at the end of that long trail I ended up signing up for Return Path's FBL for their short list of 22 ISPs (including, as far as I can tell, a couple of individual companies' email systems). In doing so I have now agreed to them sharing my "Personal Information with business partners or other third party sponsors of sweepstakes, contests and similar promotions from time to time" (seems like a bizarre provision for the terms of service for a B2B company, especially one whose raison d'être is about reducing spam, but what choice do I have?), but I am none the wiser yet on why my one server's IP address has been blacklisted.
However, like #StephenB, I am going to abuse my standing as an OpenSRS reseller (an account I have all but abandoned because of their crappy service) and send their support department an email. I expect I'll get the usual "not my department" reply, as happened sometime last year when someone was registering phishing domains spoofing one of my user's domains. I'll post the results of that in a comment when/if I hear back.
UPDATE: I did email OpenSRS reseller support and (to my surprise) they responded within the hour to (belatedly) inform me of the FBL. Another seven hours later they de-listed my IP and the delayed mails in the queue went through.
I brought up some of my points above and this was their reply:
Thank you so much for your feedback, certainly your concerns are understandable. At OpenSRS/Tucows we're always looking to provide a better service, and definitely we can see your point as far as blacklist/delisting goes, for the time being I believe the reason for this is due to a lack of resources to put something like this together, but certainly I can assure you it is on our radar. I will pass this information along to our managers so that we can ensure your voice is heard.
Platitudes, but nevertheless positive platitudes.
UPDATE 2: Well, the platitudes didn't last long. They blacklisted my IP again, and this time I was just patronised instead:
I am just replying back on the RBL listing you inquired about and I can confirm the IP was once again de-listed but I did get some additional information for you as requested. I needed to do a bit of checking but the IP x.x.x.x is provided by RIPE Network Coordination Centre, the IP assigned to the user by the hosting provider carries the reputation of the rest of the CIDR. The nature of VPS/Shared IPs is to be disposable, and it is not suitable for sustainable mail services. I would suggest that you should be renting a dedicated IP/CIDR directly from ARIN or any other static IP provider to avoid further listings from happening in the future since its [sic] not necessarily your customers being listed but the IP being listed. But of course for the time being we have de-listed the IP but assuming nothing changes its [sic] likely it will be listed again in the future. Let me know if you have any questions from here.
We've been using VPSes for mail since 2008 (after a lot of thought and research), and have never in that time had an issue. I understand the sentiment that VPS IPs have a lower reputation in the minds of sysadmins with long memories, including myself, but in this day and age this is like saying that "I don't like x nationality because of what they did to my great-grandfather during the war." Properly maintained blacklists are supposed to have a memory hours long (in most cases; not all, of course), not generations long, and OpenSRS/Tucows/Hostedemail are blocking data centres worldwide full of legitimate mail servers, that nobody else are blocking. I diplomatically told them they're using thinking that became obsolete around the end of the last century.
I already have one of their customers (that our users were having trouble emailing) talking to us about moving.
If WiTon Nope's answer was correct at one point, it doesn't appear to be accurate anymore. They blacklisted my server as well, for no apparent reason, and it took a week of chasing them to get that resolved - and it appears that the only reason it didn't take longer (or got resolved at all) is because I'm already an OpenSRS reseller for domain registration (I don't use their EMail service, and I certainly won't be after this experience). Even then, I had to resort to calling them, because the attempts I made to contact them via their reseller support EMail & Twitter were all ignored. Oh, and unlike nearly every other RBL I've dealt with, they fail to provide any method for requesting delisting.
Also, the suggestion to check MX Toolbox doesn't seem to be relevant, since they don't actually monitor urbl.hostedemail.com - and same as with Daniel Wilson, my server wasn't on any of the (more than 40) RBLs that MX Toolbox does monitor.
To top it all off, once they finally DID resolve the problem, they refused to provide any useful details, like ANY reason for having listed my server, or even so much as confirming that there WAS a reason in the first place. I try not assume that people are acting in bad-faith, but I can't think of any reason not to provide the justification for the listing - unless they discovered that was no valid reason for blacklisting the server, and are just trying to weasel out of admitting that they screwed up.
hostedemail.com is used by OpenSRS providing email hosting service and it's not a blacklist directory. You don't have to worry you have to wait for couple of days while your IP will be refreshed accross all mailservers and dns globally.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
My server needs to send emails on the behalf of my client, and the client wants this email to at least appear to originate from them.
The easy way is to just spoof the From address. The hard way is to get the client's username and password, and actually send from that account.
My questions are:
Will spoofed email trigger spam filters? (In my test, Apple Mail did not think it was spam.)
Is this considered a bad practice, or unethical, or in any way frowned upon?
The emails are going out only to people who have specifically and explicitly requested the email, and it will likely be a small number of people (less than one per day). We are not sending out spam at all.
Because this is an important client, I don't want to do anything that would reflect negatively on them (or myself).
Thanks. Hope this isn't too subjective.
Email spoofing is not completely preventable, since the basic protocols from email exchange don't verify anything.
This might help you decide:
http://en.wikipedia.org/wiki/Email_spoofing
Which says historically:
In the early Internet, "legitimately spoofed" email was common. For example, a visiting user might use the local organization's SMTP server to send email from the user's foreign address. Since most servers were configured as "open relays", this was a common practice. As spam email became an annoying problem, these sorts of "legitimate" uses fell out of favor.
I would think it is acceptable as long as the message is spoofed to a return address you would like people to respond to.
However, it would be more standard and appropriate to use email/pass.
I suppose it depends on how difficult this would be in your situation, but if reasonably able, don't spoof.
You said:
The emails are going out only to people who have specifically and explicitly requested the email, and it will likely be a small number of people (less than one per day).
If the email contents have perhaps a small footnote, I don't think it would be terrible. I have seen similar things from many companies. It's your decision.
I am currently developing an email server in C, and the end goal is to be able to send millions of emails to millions of people every day. Many organizations have email lists with large numbers of users that they email every week/month/etc.
The big question: how can I prevent the server and the emails from being marked as a spam? All of the SPAM-prevention stuff I've seen so far deals mostly with poor configurations, or at least does not require large numbers of emails to be send every hour. I have yet to see anything that addresses the scope of millions-of-emails-per-hour.
Here are some assumptions you can make:
EVERY single email sent is legitimate
all SPF records and MX records are accurate, up-to-date, and valid
all other common SPAM-prevention tactics are being used (reverse DNS is good, DKIM is used, return-addresses are valid, etc etc etc)
emails are one-to-one (ie, I'm not CC'ing 1000 gmail addresses; I'm sending one email to each address)
Here are some questions to get us moving in the right direction:
should I limit the number of emails sent to X emails per minute per domain? If so, how do sites like GMail and MailChimp get around this? note: there are no ISP restrictions; this is only an issue for the receiving mail server...
should I limit the number of connections to a domain at a given time? (eg, will Google think I'm a spam agent if I open 10/100/1000 simultaneous connections to gmail servers?)
how many bounce-backs (5xx errors on an address) should I accept for automatically removing that email from a subscription list? does this affect a server's spam rating?
is there anything else I should or should not do?
Final note: please remember this is a programming question, NOT a library question - I don't want to use someone else's service; we are writing our own for a reason. I'm looking for practical programming advice.
This is not a programming question, but here goes:
I strongly recommend you join your local mail operators mailing list, as well as "Spam-L" mailing list. Read the archives, and see what issues others are having.
The short answer is that destination servers can, and do, use all sorts of methods to try to prevent spam. THere are many things you will need to be aware of in order to have good deliverability, and those things change all the time.
First and most important, remember:
Free speech also includes free listening.
Nobody has to accept or transmit your mail.
Independent operators, businesses and individuals have a perfect right to refuse your mail for any reason or no reason. ISPs are limited only by their contracts with the customer and common-carrier laws, which generally give them broad discretion in what is considered spam and how they block it.
Their system, their rules. If you want your messages delivered, you must cooperate with receiving ISPs. This may mean jumping through hoops, or complying with requirements you think are stupid, or pointless.
Ensure you are not listed by SpamHaus. Most ISPs small and large use SpamHaus DNSBL service. Presence on one of SpamHaus' lists asserts their opinion that your mail meets their listing criteria. Because of SpamHaus' high reputation, most ISPs will simply block all mail you send based on their opinion.
Make sure you process unsubscribes.
Make sure you process non-delivery reports. You may not want to kill a subscription on the first NDR, as there can be intermittent network or server problems which can result in non-delivery, or even erroneous reports that an address is incorrect. But if you get several over the course of a month or two with no successful deliveries, you should kill the subscription.
Join a pay-for reputation service. These may require posting a bond which you may lose if you send Spam. SpamHaus offer one. There are others.
Get professional advice from someone like Return-Path. You will have to pay for this also.
Monitor. The hoops you have to jump through change all the time. Ensure you are aware of emerging deliverability problems.
Join feedback loops. most large ISPs offer feedback programmes where you can get feedback on how users are perceiving your mail, whether they are reporting it as spam, etc.
Ben had some good practical advice, but for others with this problem, here is what I have discovered in the past month:
Email is all about REPUTATION. You will never be able to throw together a server, ip, and/or domain name and expect to be able to send out millions upon millions of emails.
On Stack Overflow, we have a rating system (up and downvotes) to estimate the value/trust that person has with the SO community. But it takes time and effort to get points. It's the same with email - you have to start sending out small amounts of email that people actually open up and read (and would never mark as spam), and then slowly send out more and more every month until you reach the goal of millions and millions of emails.
Everytime someone "downvotes" - marks the email as spam, flags the domain, flags the ip address, deletes the email without reading it, etc - you get a hit against your reputation. You need to be continually monitoring and putting effort and best-practices into your reputation if you want to gain good standing with people.
So start small, expand in a stable and steady manner, and always keep a watchful eye out for abuse, misuses, good and bad feedback, or anything else that might affect your reputation.
It's not only possible, but very practical; you just need to give it time and effort.
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.