{"id":4648,"date":"2021-06-14T08:05:52","date_gmt":"2021-06-14T12:05:52","guid":{"rendered":"https:\/\/www.exchangedefender.com\/blog\/?p=4648"},"modified":"2021-06-08T11:03:58","modified_gmt":"2021-06-08T15:03:58","slug":"exchangedefender-advanced-features-policies-bulk-mailer-policy","status":"publish","type":"post","link":"https:\/\/www.exchangedefender.com\/blog\/2021\/06\/exchangedefender-advanced-features-policies-bulk-mailer-policy\/","title":{"rendered":"ExchangeDefender Advanced Features & Policies: Bulk Mailer Policy"},"content":{"rendered":"\n
<\/div>\n\n\n\n

Today, we are excited to showcase our brand new feature: Bulk Mailer Policy<\/strong>. This new feature was first announced last week as part as the new release of ExchangeDefender Advanced Features and Policies<\/a>. (It is available to all of our ExchangeDefender PRO clients.) Bulk Mailer Policy simplifies process of blocking or allowing mail from bulk mail operations that are increasingly used by developers and hackers alike to relay mail.<\/p>\n\n\n\n

<\/div>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
<\/div>\n\n\n\n

Bulk mail operations, such as AmazonSES and Sendgrid, are large scale SMTP networks designed to enable developers to reliably deliver and manage email subscriptions. As such, bulk mailers generate a new sender email address (envelope-from) that the mail would bounce to if the message could not be delivered for any reason. Every time an email goes out a new sender bounce email address is created by the sender \u2013 solely for tracking the delivery and activity of that one message. Long story short, it makes it very frustrating to build a policy against something that is random and changes often. <\/p>\n\n\n\n

<\/div>\n\n\n\n

ExchangeDefender Bulk Mailer Policy<\/strong> simplifies that process by maintaining a list of IP addresses the network is using (as defined by their SPF record) to relay messages. There are three options:<\/strong><\/p>\n\n\n\n

<\/div>\n\n\n\n

Scan<\/strong> \u2013 This is the default\npolicy; every message is scanned by ExchangeDefender for SPAM content and it\ngets flagged as SPAM\/SureSPAM if it looks like SPAM. <\/p>\n\n\n\n

<\/div>\n\n\n\n

Allow<\/strong> \u2013 This policy will\nresult in ExchangeDefender not scanning any mail from this network for SPAM\ncontent (viruses, malware, etc are still considered) and delivering it\nautomatically.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Block<\/strong> \u2013 This policy will result in ExchangeDefender automatically labeling the message as SureSPAM.<\/p>\n\n\n\n

<\/div>\n\n\n\n
\n\n\n\n
<\/div>\n\n\n\n

The Bad:<\/strong><\/p>\n\n\n\n

Bulk mail sending networks have minimal requirements for\nsubscription\/use, and many are actively abused to relay dangerous content. <\/p>\n\n\n\n

<\/div>\n\n\n\n

The Good:<\/strong><\/p>\n\n\n\n

The main benefit of this feature is that ExchangeDefender is actively tracking IP address blocks associated with each network, minimizing the amount of time IT has to spend managing allow\/block policy.<\/p>\n\n\n\n

<\/div>\n\n\n\n
\n\n\n\n
<\/div>\n\n\n\n

ExchangeDefender Advanced Features & Policies<\/strong> are available at https:\/\/admin.ExchangeDefender.com<\/a> and should be setup and managed by a competent IT staff that can manage the entire scope of the policy. The issue with bulk mailer networks is that they are massive, easy to access, and often tied into shared hosting environments that are frequently compromised \u2013 what makes them convenient is what makes them dangerous. Unfortunately, if your 2FA\/OTP or web site developer uses such networks, you have no choice but to allow the traffic through, and ExchangeDefender makes that easy! We make it just as easy to block them. Whether it should be enabled or disabled, and how, is something that each organization will have to assess and consider along with other cybersecurity policies that need to be in place. <\/p>\n","protected":false},"excerpt":{"rendered":"

[…]<\/p>\n","protected":false},"author":50,"featured_media":4649,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1,46],"tags":[],"class_list":["post-4648","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","category-product-features"],"_links":{"self":[{"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/posts\/4648","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\/50"}],"replies":[{"embeddable":true,"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/comments?post=4648"}],"version-history":[{"count":9,"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/posts\/4648\/revisions"}],"predecessor-version":[{"id":4658,"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/posts\/4648\/revisions\/4658"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/media\/4649"}],"wp:attachment":[{"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/media?parent=4648"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/categories?post=4648"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/tags?post=4648"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}