Our email apps and programs as well as our mobile devices are once again able to use encryption when connecting to our server. Mail server encryption was fixed this evening. Thank you for hanging in there with us! This should be cleared up soon. We are taking steps to expedite the process where we can, but unfortunately we have no direct control over how long it takes them to make that decision. The good news is that this cautious behavior on the part of recipient mail servers should only last a short time, just until they decide we’re not going to blast them with spam. Also if possible, the email admin should put our mail server IPs (174.128.231.34, 174.128.231.35, and 174.128.231.36) in their exception list to be on the safe side. If it’s not in either place, they should contact their email admin, like you contact us, and have them check the mail server logs to see what happened after their server accepted the message. Either way they should put you in their trusted senders/exception list.
#COMCAST EMAIL SERVER SETTINGS FOR AVAST ALERTS MAC#
In this case the recipient should check their spam or junk folders in both their email program (Outlook, Thunderbird, Mac Mail, etc.) AND in their webmail to see if the message was put there. The other issue we’re seeing is that in some cases, our logs show a message as having been delivered, but the recipient says it wasn’t received. This way even if you have a dozen recipients, and their server is deferring us, they should all have received your message in about an hour. We believe we’ve mitigated this at least somewhat by adjusting our retry schedule to retry every 5 minutes during the first 65 minutes after you click Send. With zero day spam, spammers buy domain names and IP addresses in bulk, and within hours of registering the domain names, they blast out mass quantities of spam in an effort to get it all delivered before their new IPs end up on blacklists. We believe this is due to what’s known as “zero day spam”. So they’re intentionally imposing delays, so we have to retry, multiple times in some cases, before they accept mail from us. They’ll give you some credit, but not as much as if you had great credit. Because of this, these providers are treating us like a person who has no credit at all. We believe this is because we had to use new IP addresses for our mail servers, and while these IP addresses do not have bad reputations, they also don’t have good ones. We have noticed that some email providers, most notably AOL, Yahoo, domains hosted by MS Office 365, and possibly Verizon, are not accepting our mail for delivery right like normal. To all of our users who have been affected by this issue, we sincerely apologize for what we know has been a major inconvenience. If you know of anyone who had been receiving your email in their junk folder and never marked your email as Not Junk, please try sending to them again to see if you’re now delivered to their inbox. While we still do not–and may never–know the exact reason this was happening, the Microsoft tech with whom we’ve been working said this morning that their Product Team, which is at two step escalation, “fixed an old rule” in their spam filter system. Our tests are now going directly to recipients’ inboxes. After finally getting access and working with a tech for more than two weeks, we believe this issue has now been resolved. Initially we had trouble getting access to MS tech support as they seem to only want to work with their direct email hosting customers. – FIXED: Microsoft-Hosted Email Sending Us to Junk!Īfter pretty much everything else from the migration had settled down, Microsoft-Hosted Exchange, which hosts email for many businesses, was still sending all our email to its recipients junk folders.
0 kommentar(er)
