[syslog-ng] [PATCH]: Experimental SMTP destination

[Gergely Nagy]

On Sat, 2011-02-12 at 19:06 +0000, Alexander Clouter wrote: 
> Gergely Nagy <algernon at balabit.hu> wrote:
> > 
> > The usage is something like this:
> > 
> >        destination d_smtp {
> >          smtp(
> >            host("localhost")
> >            port(25)
> >            mail_from("syslog-ng alert service <noreply at example.com>")
> >            rcpt_to("Admin #1 <admin at example.com>")
> >            rcpt_to("Admin #2 <admin2 at 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 at example.com admin at example.com admin2 at example.com"
> 		template("From: syslog-ng alert service <noreply at 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]