{"id":406,"date":"2012-05-23T09:00:53","date_gmt":"2012-05-23T14:00:53","guid":{"rendered":"http:\/\/www.exchangedefender.com\/blog\/2012\/05\/making-sense-of-exchangedefender-smtp-alerts\/"},"modified":"2012-05-23T09:00:53","modified_gmt":"2012-05-23T14:00:53","slug":"making-sense-of-exchangedefender-smtp-alerts","status":"publish","type":"post","link":"https:\/\/www.exchangedefender.com\/blog\/2012\/05\/making-sense-of-exchangedefender-smtp-alerts\/","title":{"rendered":"Making Sense of ExchangeDefender SMTP Alerts"},"content":{"rendered":"<p>For the past week we have been running the newly updated version of the ED SMTP alerts and I\u2019 have got to say this is probably the most overwhelming response to a product that I\u2019ve designed since being with ExchangeDefender. There were many partners who forgot they had the feature enabled, and for the first time, received alerts about issues connecting to their clients. My biggest fear when re-enabling the alerts was possibly upsetting partners with emails that they may consider useless or something they \u201cdon\u2019t\u201d want. Surprisingly, the response from every partner I spoke with since enabling the feature was positive and I heard many partners say \u201cWe\u2019ve been waiting for this.\u201d  <\/p>\n<p><a href=\"http:\/\/www.exchangedefender.com\/blog\/media\/Making-sense-of-ExchangeDefender-SMTP-al_8295\/Alert-Icon.png\"><img loading=\"lazy\" decoding=\"async\" style=\"background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px\" title=\"Alert-Icon\" border=\"0\" alt=\"Alert-Icon\" align=\"right\" src=\"http:\/\/www.exchangedefender.com\/blog\/media\/Making-sense-of-ExchangeDefender-SMTP-al_8295\/Alert-Icon_thumb.png\" width=\"166\" height=\"132\"><\/a>Throughout last week and yesterday I\u2019ve made minor modifications to the alerts to include more verbosity and to have threshold values for failures. Now, alerts will wait for three consecutive failures before sending an alert to the partner. Alerts will only be sent once per hour for consecutive failures. Once the connection error is cleared, the admin email on file for the domain will receive an \u201cup\u201d email.  <\/p>\n<p>Now, alerts will contain more helpful, verbose information.  <\/p>\n<p>For example, here is an alert about backpressure  <\/p>\n<p>ExchangeDefender had trouble communicating with the MTA (xx.xx.xx.xx) for domain.com MTA Experiencing Backpressure To resolve this, please review the following articles:  <\/p>\n<blockquote>\n<p><strong>Exchange 2010: <\/strong><a href=\"http:\/\/technet.microsoft.com\/en-us\/library\/bb201658.aspx\"><strong>http:\/\/technet.microsoft.com\/en-us\/library\/bb201658.aspx<\/strong><\/a><strong><\/strong>  <\/p>\n<p><strong>Exchange 2007: <\/strong><a href=\"http:\/\/technet.microsoft.com\/en-us\/library\/bb201658(v=exchg.80).aspx\"><strong>http:\/\/technet.microsoft.com\/en-us\/library\/bb201658(v=exchg.80).aspx<\/strong><\/a><b><\/b><\/p>\n<\/blockquote>\n<p>And here is an alert about the SMTP connector rejecting emails because authentication is required  <\/p>\n<p><strong>MTA Rejected Mail From Command. It is possible that anonymous relay is not enabled for the SMTP connector and that authentication is required.<\/strong>  <\/p>\n<p><strong><\/strong> <\/p>\n<p>Currently the alerting system will alert for:  <\/p>\n<blockquote>\n<p>&#8211; Incorrect IP restrictions (MTA answers, but rejects the connection because the IP restrictions do not allow ExchangeDefender)  <\/p>\n<p>-SMTP Authentication Required, not allowing anonymous relay  <\/p>\n<p>-Exchange experiencing Backpressure  <\/p>\n<p>-Connection failed \/ timed out<\/p>\n<\/blockquote>\n<p>The next upgrades will save the SMTP test debug output to SQL to allow partners to review the SMTP transaction logs and allow partners to control the threshold values for failures.  <\/p>\n<p>Travis Sheldon<br \/>VP, Network Operations, ExchangeDefender<br \/>(877) 546-0316 x757<br \/>travis@ownwebnow.com  <\/p>\n","protected":false},"excerpt":{"rendered":"<p> [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-406","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/posts\/406","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=406"}],"version-history":[{"count":0,"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/posts\/406\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/media?parent=406"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/categories?post=406"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.exchangedefender.com\/blog\/wp-json\/wp\/v2\/tags?post=406"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}