Similar to what Tyler was doing in #841, we're currently sending e-mails to MailTo into a ticket system. Crash reports are also being sent there, which doesn't really make sense.
I don't want to overcomplicate things, but I'm wondering if it makes sense to add a third mail option, for system errors (crash reports, MinDiskSpace, etc.). We have an Incident Response team, who are in charge of handling the notices, and an engineering team, which actually updates the Bro config, and does any sysadmin work, so for us it'd be really useful to have that split.
Thoughts? Does this seem like a reasonable change?
That sounds like crash reports are sent to the wrong place. We have
two options for mails:
Option("MailTo", "<user>", "string", Option.USER, True,
"Destination address for non-alarm mails."),
Option("MailAlarmsTo", "${MailTo}", "string", Option.USER,
True, "Destination address for alarm summary mails. Default
is to use the same address as MailTo."),
I believe the original intention was to use MailAlarmsTo for
everything to the IR team, and MailTo for all the adminstrative stuff.
Doesn't sound like that's still the case anymore but maybe somethign
we should go back to?
So, that lines up pretty well with what you said, with the exception of ACTION_EMAIL. I think most setups will want those going to the IR team AKA MailAlarmsTo. But then we're back in the situation where alarm summaries and notice e-mails go to the same place, which is annoying if that place is a ticket system. (That was changed in #814, not #841 as I previously said).
What I initially did was create another action ("ACTION_EMAIL_IR"), but that doesn't work well with extend-email/hostnames, which exits if the action isn't ACTION_EMAIL.
That sounds good to me. While I don't like overcomplicating things, I don't see any other way to do this without a 3rd option. I think the new names are clearer than the existing ones.