No Emails Recieved if only one address fails about consul-alerts HOT 5 CLOSED

Hmm.. this seems to be an Amazon SES issue not having production access which requires that receivers need to be verified. This is not the usual case with a typical SMTP server as far as I know. The notification data together with the sender and receivers are sent tot he SMTP server so this may just be an isolated case with SES.

Here's more info on SES's response code: http://docs.aws.amazon.com/ses/latest/DeveloperGuide/smtp-response-codes.html

I might do some investigation and testing with both SES and some other SMTP server.

from consul-alerts.

Totally understand the error itself is an SES issue, but the issue I'm trying to raise is that the entire notification failed for single bad recipient. I think the error could technically been anything IE what if one of the addresses was malformed?. The issue (as I see it) is that given a "working" and a "non-working", the working one should have gotten delivered.

from consul-alerts.

I think it depends of how we're 'delivering' the outbound email to Amazon SES / SMTP.

If we're sending a 'single' email with multiple recipients, then it's totally out of our control how AWS SES behaves if any particular recipient fails.

On the other hand, we can send multiple individual emails each with just one recipient, and this should avoid having the entire message or alert fail from being sent if one recipient fails.

The downside:

• More logic & effort on the consul-alert email sending part (decompose to multiple emails, need a queueing system, what to do if all emails fail or, say, the SMTP server stops responding midway)
• Now you're paying AWS multiple times per alert since you're sending multiple emails

Personally, I think the issue is isolated to AWS SES, and at this point the effort to send multiple emails per alert isn't worth it.

On the other hand, if we were to consider supporting multiple emails, then I would extend it to possibly have not just different addresses, but even different SMTP servers per recipient (e.g., one email to an internal recipient & SMTP server, another via AWS SES).

Or, multiple, different endpoints entirely (AWS SNS, SMTP, etc.?)—but that's just making it more and more complex.

At that point, personally, I'd look at delegating the delivery of alerts to another, more robust or feature-rich service and just have consul-alerts trigger or generate them. Unless we really want to extend its functionality to include that.

2c.

from consul-alerts.

Valid points. I think I agree with you, that the added complexity may not be worth the effort.

from consul-alerts.

I'd filed #5 which would probably serve as a more feature-rich service (Pagerduty). Important though that we're giving a basic (bug-free-as-possible) alternative for those who don't want to pay for a premium services.

from consul-alerts.