daknetworks.com

You are here: Blog Paying for a SMTP Relay

Paying for a SMTP Relay

Paying for a SMTP Relay

I manage a server that handles email for a medium sized company. It processes about 1,000 messages per hour or 24,000 per day. The box sits inside the office humming away for about 10 years.

Then one day, for some reason, executable content comes through the email service which isn't picked up by ClamAV. Then, for some reason, a user opens an email that's obvious-to-me-but-not-to-them that they shouldn't open. Then, for some reason, my choice of antivirus at the time (Panda Cloud) does nothing and... poof. Cutwail virus city. This thing starts sending out spam by the thousands every minute and the IP address is quickly put on blacklists all across the world.

Great.

If you are given a map and dropped into nowhere, you can usually find your way around pretty quickly. If you're dropped in the middle of nowhere, it takes longer to find your way out.

I discover they're on a blacklist pretty quickly. Through blacklist diagnostics, I can see that a cutwail virus is on the network. I wait till the end of day and start to scrub client pc's and think "I'm too old of this stuff."

I find a client pc, disinfect it with Microsoft Saftey Scanner and feel good. I put in for delisting and wake up the next day to find they were re-listed for the same reason.

I missed a client pc behind a closed door. Executives. The reason the world spins slowly.

Finally getting physical access by persuasion that there's an obvious problem, I disinfect the second client pc as well. Feeling really good, I put in for another delisting. The next morning they stay that way.

Good.

The next few days were spent delisting from any blacklist or RBL at MXToolBox.

Now here's the problem, despite delisting, the IP address is on-radar at larger outfits like Yahoo & AOL who run their own internal spam metrics. Because of poor stats, the server is still getting blocked.

To ease this, I switch over to the ISP smtp server which is used to work fine for quite a long time: smtp.fdn.com. That doesn't work. They were bought out. So I use the newer smtp server: smtp.nuvox.net. That doesn't work. They were bought out by Windstream. I don't know the smtp server for them.

I call support knowing that large customers get to talk to knowledgeable people in a few minutes. Obtaining that Windstream's smtp server is: mailhost.windstream.com, I start using that.

Everything is going good.

A few hours pass.

Rrrrrriiiiiinnnnggg!!!! Rrrrrrriiiiinnnngggg!!! Rrrrrriiiinnnnnngggg!!!

"I'm not getting email!"

I look in the logs: "Too many recipients in the past hour."

So Windstream has an hourly limit on sending. This used to not be so. Normally it isn't a problem but when blast company wide messages go out, the server spikes above that level.

I switch back to the internal smtp.

Everything is going good.

A few hours pass.

Rrrrrriiiiiinnnnggg!!!! Rrrrrrriiiiinnnngggg!!! Rrrrrriiiinnnnnngggg!!!

"I'm not gettting email!"

I look in the logs: "(DYN:T1) http://postmaster.info.aol.com/errors/421dynt1.htm"

So AOL has dynamically blocked the IP address because it went too high on the stats.

I switch back to the Windstream smtp.

My only problem is AOL. If they would remove the DYN:T1 block, my life would be normal again.

I switched back and forth between the internal smtp and the Windstream smtp for the next several days hoping the block would be removed.

After getting enough complaints because of too much delay, I realize I'm too old for this and my hobby projects in my 20's which are now production projects in my 30's probably need to be shutdown. I just can't take it.

I look for outside help.

I remember hearing about Amazon smtp services or simple email service (SES). It's part of their Amazon Web Services (AWS) or their cloud services.

I sign up feeling like they are a good partner.

Their documentation takes a few reads because of the whole credentials aspect. They have a set of credentials for accessing the service but they have a different set for accessing SMTP. This set is created automatically.

Their documentation is also confusing about SSL/TLS on port 465 but I test it out over the next few days and get it working in my test. Here's what I used

SMTPSmartHost=email-smtp.us-east-1.amazonaws.com

smtp-auth-proxy=service
Debug=disabled
Passwd=not-posted-in-plain-text
PeerPort=465
Userid=AKIAILKTFOYH47NR5MEA
status=enabled

Unfortunately, the service won't work for forwarding accounts. In other words, if I receive emails on behalf of someone and forward them onto their private email address at for example, AOL, it bounces with a message about the sending domain being invalid.

Back to the drawling board.

You would think that an SMTP service for large volume would be easy to find and obtain. Well, it's easy to find enough. Like most, I go to google and type "smtp services."

Cutting out the details, here's the services that make my short list:

  • MandrillApp
  • Ongage
  • Critsend
  • Mailgun
  • MailJet
  • SendGrid
  • Dyn

I moved on to the next service on the list, MandrillApp. Super easy. Create an account and the credentials are right there, easy to understand and ready to be used.

  • Host smtp.mandrillapp.com
  • Port 587
  • SMTP Username This e-mail address is being protected from spambots. You need JavaScript enabled to view it
  • SMTP Password any valid API key

I turn them on over the weekend and montior it. Everything is great. It even has detail stats on the sending such as percentages and graphs that make you feel good. The problem becomes, you lose control.

Managing my own server, I can watch the outgoiong process in real time. If the receiving server gives a message, I can see it. When you outsource this to another company, you don't get to see anything. You have no idea what is happening. All you know is that there is a problem.

Over the next few days, I deal with issues such as mail stuck in the queue with no way to send it, message sending limits being lowered to 29 messages per hour with no way to lift them and rejected messages with no reason why. Messages aren't getting through.

No one can run a business without messages getting through.

I contact their support through email and wait about 24 hours for a response each time. The responses are all the same, they sound great but in the end the service is automatic and their's nothing they can/will do.

So I ask the ultimate question, "What's the point of having a sending service that doesn't help you send?" I didn't pay them to be critics on what I was sending, I pay them to send, period. If they are not going to help me do that then we are not a good fit.

I change the sending back to local server. I move on.

I cannot have another experience like the failed MandrillApp trial run. Being afraid, I breeze over Ongage, CritSend, MailGun and MailJet. They all seem to be similar. Built for developers so that a product can automatically send messages to their clients.

They really aren't services that help send messages on a day to day basis. Most of their documentation starts talking about send limits and unsubscribes.

I decide using the local service is the best option just like that past 10 years. I made some changes to limit the number of messages that can be sent per second and I dish sending off to the ISP smtp server. It seems to be working OK with only a few hiccups.

AOL has seemed to stop blocking with these low limits and the passing of 30 days time from the original incident. My only issue is some Yahoo servers are still blocking. Not all. Only some. Arrrrgggghhh. I'll deal with it.

I'll have to work on the IP reputation in the near future by turning on SPF, DKIM, and DMARC. Believe it or not, I turn towards friends and I have one who runs scanmailx.com. I'll test the service out but know that the developers are some of best around.

Contact Dak Networks

We are not taking on new clients at this time.