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

Valentijn Sessink valentyn at blub.net
Mon Feb 14 09:46:40 CET 2011


Hi,

Op 12-02-11 20:34, Gergely Nagy schreef:
> 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)

So isn't the built-in MTA a solution in search of a problem? Also, I see
some problems with the built-in SMTP destination. Misconfiguration now
is a problem for syslog-ng itself - instead of the external MTA. This,
of course, has two sides: when the misconfiguration consists of a
log/mailing loop, using an external MTA could be a serious problem when
tens of MTA instances are started in parallel; but an internal MTA will
bring the system to it's knees by immediately filling memory, disk and
the network with repeated messages - without any external help ;-)

However, at the moment your smtp destination does not seem to have a
"throttle" configuration setting, while program() does have one.

> * Tighter integration with syslog-ng allows for easier troubleshooting:
> one only has to look at one place

I'm pretty sure it won't be too hard to configure syslog-ng so, that
it's pretty easy to troubleshoot the MTA that it sends it's messages to.

But the main point is, that I don't think that an internal SMTP
destination will do any good for misconfiguration. I.e. misconfiguration
is a problem in itself, and no matter how many destinations you add to
syslog-ng, you won't be able to prevent misconfiguration.

> 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).

Being a Linux user, I don't think calling external programs is a problem
per se. Yes, it has overhead, but in this case, the overhead seems
perfectly acceptible.

A problem that was not yet mentioned is, that having an SMTP destination
now makes syslog-ng dependent on yet another library, libesmtp.

All in all, it sounds like the perfect solution for a certain
widely-used proprietary operating system, that has no proper built-in
SMTP possibilities. And because the SMTP destination is configurable
with ENABLE_SMTP, Linux builds can easily avoid the new dependency ;)

Best regards,

Valentijn


More information about the syslog-ng mailing list