No Emails Recieved if only one address fails

[dpetzel]

I've got everything up and running and liking things so far. One issue I noticed is that I seem to not get any emails if there is a failure on just one address. I'm using Amazon SES and have two email addresses configured under receivers. One is verified email address and one is not. I see the following message logged into the log (odd its an info rather than error?): level="info" msg="Unable to send notification: 554 Message rejected: Email address is not verified." and I do not get the email notification. If I remove the unverified email from the Array, I do get the email as expected.

It might also be helpful if it logged the recipient it was trying to send to as part of the message

[darkcrux]

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.

[dpetzel]

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.

[aisrael]

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.

[dpetzel]

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

[hunter]

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.