{"id":1188,"date":"2018-02-28T10:11:14","date_gmt":"2018-02-28T15:11:14","guid":{"rendered":"http:\/\/www.exchangedefender.com\/blog\/?p=1188"},"modified":"2018-02-28T10:11:14","modified_gmt":"2018-02-28T15:11:14","slug":"exchangedefender-address-book-lockdowns","status":"publish","type":"post","link":"https:\/\/www.exchangedefender.com\/blog\/2018\/02\/exchangedefender-address-book-lockdowns\/","title":{"rendered":"ExchangeDefender Address Book Lockdowns"},"content":{"rendered":"

Effective March 1st, ExchangeDefender will only allow delivery to email addresses that exist in our Service Manager or ExchangeDefender Admin Portal. This is a non-event for 99.999% of our clients (it\u2019s only being mentioned because it\u2019s a refresh of the AUP\/TOS policy) and it is intended as a security precaution against threats we\u2019re seeing in the wild and on our honeypot networks.<\/p>\n

The Problem<\/strong><\/p>\n

ExchangeDefender as an SMTP proxy will scan and deliver any email targeted at a protected domain. Even though we sanitize each message and do not permit dangerous content through, if the email address does not exist on the clients server, the message will bounce to the sender. Now, imagine that sender doesn\u2019t have an SPF\/DMARC, and imagine that the address itself is spoofed \u2013 now send that message a few thousand times and an attacker can destroy a mailbox simply by overloading with non-delivery receipts and bounce messages. <\/p>\n

Why this happened in the first place<\/strong><\/p>\n

Bad automation. It happens, and when it happens on a scale of ExchangeDefender, it creates an issue. So to minimize complaints, we just stopped actively enforcing address book validation. To those of you protecting servers on networks outside of ExchangeDefender\u2019s control (think Google, Office 365, etc) the management and addition of new addresses will become automatic. Here is a peak at our new support portal. It should make a lot of you very happy.<\/p>\n

\"screen1\"<\/a><\/p>\n

Figure 1:<\/strong> Service Manager.<\/em> Instead of having a ton of accounts in the listing, everything is now logically grouped by a Company. This way whenever you go to manage one client you only see the users belonging to that client and any addition or modification will pull pricing, configuration and meta data from that organization\u2019s settings. This should virtually eliminate mistakes, billing issues and configuration problems.<\/p>\n

<\/p>\n

\"screen2\"<\/a><\/p>\n

Figure 2:<\/strong> Adding a new mailbox.<\/em> The process is streamlined, clean and remarkably simple. The reality is that IT departments are no longer in charge of this anyhow, neither are our MSP partners. Businesses want the ability to control memberships, configurations, distribution lists, permissions and everything in between. <\/p>\n

<\/p>\n

\"screen3\"<\/a><\/p>\n

Figure 3:<\/strong> Mailbox permissions, settings, etc<\/em>. There are several screens for this but needless to say we\u2019re looking to expose a lot of the features that can be managed granularly in a way that businesses expect them to. Let\u2019s face it, your average office manager dealing with the new hire isn\u2019t about to fire up remote PowerShell; Strong passwords, additional features, granular control, public folder and distribution group membership templates, etc are all coming soon.<\/p>\n

Other really cool stuff is coming very soon as well, we\u2019re pretty excited with what we\u2019re building and delivering\u2026 but the focus for us always remains on the security and safe communication \u2013 and everything that supports it goes hand in hand.<\/p>\n","protected":false},"excerpt":{"rendered":"

[…]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-1188","post","type-post","status-publish","format-standard","hentry","category-exchangedefender"],"_links":{"self":[{"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/posts\/1188","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/comments?post=1188"}],"version-history":[{"count":1,"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/posts\/1188\/revisions"}],"predecessor-version":[{"id":1189,"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/posts\/1188\/revisions\/1189"}],"wp:attachment":[{"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/media?parent=1188"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/categories?post=1188"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/tags?post=1188"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}