On Sat, 2011-02-12 at 19:06 +0000, Alexander Clouter wrote:
Gergely Nagy <algernon@balabit.hu> wrote:
The usage is something like this:
destination d_smtp { smtp( host("localhost") port(25) mail_from("syslog-ng alert service <noreply@example.com>") rcpt_to("Admin #1 <admin@example.com>") rcpt_to("Admin #2 <admin2@example.com>") subject("[ALERT] $LEVEL condition in $PROGRAM!") header("X-Program" "$PROGRAM") header("X-Facility" "$FACILITY") body("Hi!\nThe syslog-ng alerting service thinks you might be interested in the following message:\n $MSG\n-- \nsyslog-ng\n") ); };
The sysadmin in me does say a pipe to 'sendmail' is probably more straight forward, flexible and reliable: ---- destination d_mail { program("sendmail -f noreply@example.com admin@example.com admin2@example.com" template("From: syslog-ng alert service <noreply@example.com>\nSubject: [ALERT] $LEVEL condition in $PROGRAM!\nX-Program: $PROGRAM\nX-Facility: $FACILITY\n\nHi!\nThe syslog-ng alerting service thinks you might be interested in the following message:\n $MSG\n-- \nsyslog-ng\n.\n")); } ----
The closing '\n.\n' does the EOF.
Yes, that's a possibility, indeed, but that assumes one has a sendmail command installed.
Further plans include authentication & starttls support. libesmtp supports both, I just didn't have time to write the neccessary glue code yet.
A task that should be left surely to the local MSA (mail submission agent)?
Yep, that is an option indeed, and has advantages over a built-in driver. However, it is an option that I do not like all that much. Having a built-in smtp destination driver has a few advantages over using a program destination: * You don't need an external application (my #1 reason, apart from "because I could"). * No need to fork off to launch the external program (though, this isn't a big issue, since email alerts will probably be rather rare, so the fork & launch overhad is negligible) * Tighter integration with syslog-ng allows for easier troubleshooting: one only has to look at one place * Safer: If $MSG happens to be multi-line, and one manages to craft a message with an embedded "\r\n.\r\n", we're in trouble. Similar things could be done to the headers aswell. Of course, that can be guarded against, but then the program destination becomes considerably different, and one would need a wrapper program. Or escaping template functions (which would be useful, if we don't have any yet..) That, and having the option to do it without an external program was one of the driving forces behind the code (I really, really don't like calling external programs, if I can avoid it). -- |8]