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

[Gergely Nagy]

On Sun, 2011-02-13 at 09:27 +0000, Alexander Clouter wrote: 
> Bill Anderson <Bill.Anderson at bodybuilding.com> wrote:
> > 
> > On Feb 12, 2011, at 16:08, "Alexander Clouter" <alex at digriz.org.uk> wrote:
> > 
> >>> * Tighter integration with syslog-ng allows for easier troubleshooting:
> >>>    one only has to look at one place
> >>> 
> >> It does not answer "where did my email alert go?"  Did syslog eat it?  
> >> Did the smarthost toast it?  Was it lost further upstream?
> > 
> > How is the any different than any other destination? SMS, MongoDB, 
> > SQL, etc. all have the same problem if it isn't where it is expected. 
> > Even files.
> > 
> I phrased this badly.  My point is that you have to look in the mail 
> logs anyway, any syslog-ng logs is not going to tell you anything a call 
> to the local sendmail binary does not.

That's not entirely accurate. If the problem is persistent, and can be
reproduced with syslog-ng running in debug mode, my driver will echo
back most of the SMTP session, so one can easily see whether the problem
is between syslog-ng or the SMTP server used.

Calling sendmail may or may not reveal that information: if you have a
local mail setup that works, sendmail will accept the message. Then when
the local MTA tries to deliver the message, it will encounter the same
error then, and one will have to dig into the logs, which varies from
MTA to MTA.

With the program destination, one will need to assume that if there's
network outage or any other error, the MTA will queue the mail and retry
later. While this is true in most cases, it's not always the case. Thus,
when one has an MTA that doesn't do this, program() can easily lead to
lost messages.

Using a built-in driver that uses syslog-ng's built in queuing will not
have such problems.

-- 
|8]