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

[Gergely Nagy]

Balazs Scheidler <bazsi at balabit.hu> writes:

> Hi,
>
> On Fri, 2011-03-04 at 15:16 +0100, Gergely Nagy wrote:
>> (Quick note: I rebased my work/modules/afsmtp branch on top of the
>> current master)
>
> I'll review it, thanks.

I even pushed it now (along with the header()->extra_header() change).

>> > The same syntax could perhaps be used by a possible "sendmail()" destination, which 
>> > could spawn the local sendmail binary, instead of directly using SMTP.
>> 
>> I think I replied to this before - I'd rather extend program() to have
>> an option that would make it always spawn a new instance of the
>> program. Something like flags(always-spawn) or similar.
>
> That's ok, then sendmail() or better yet email() destination could
> become an SCL block, that uses a template() to format an email. The
> important stuff is to take care about proper escaping, so that users
> wouldn't have to care about that.

Yeah, a few template functions here and there, and we're good to
go. I'll happily prepare that once I'm done with the rest of my tasks :)

>> >> These are: Date, From, To, Cc, Bcc, Reply-To - trying to set either of
>> >> these will result in unspecified behaviour (ranging from mangled headers
>> >> to crashes, in case of Date). I will fix these at a later point. They
>> >> will probably be need to set via their own statements (header_date,
>> >> header_from, etc, or something along those lines).
>> 
>> This has partially been solved since: one can't set the mentioned
>> headers with the headers() statement, and has to use from(), to(), etc.
>> 
>> I do not have a solution for the date header yet (it can't be set in any
>> way at the moment).
>
> Is there a point in setting that? I mean I would never want to specify
> the date header, or do you have a specific usecase?

Nope, no use case. I was thinking that people might want to set the
message date to the date of the original receipt of the log message (by
the time we get to send it, the clock might tick a few seconds!).

On the other hand, solving the date problem (libesmtp has some annoying
properties, date handling is one of them) seems like too much work for
no gain, so Date will remain a forbidden header, unless someone presents
a valid reason against that.

>> Another problem is, that libesmtp parses the whole body, and tries to
>> extract headers even if they appear after the body. Thus, having a body
>> like the following will crash the module:
>> 
>>   ,----
>>   | body("Yadayada\nDate: CRASH, BOOM, BANG!")
>>   `----
>>   
>> The workaround for this will be to replace "\n"s in the body with "\n ",
>> to stop libesmtp from messing with the headers.
>
> hmm... that doesn't sound too good? are you sure libesmtp is the correct
> library to use, then?

It was lightweight! But the more I work with it, the less sure I am
about this decision.

I had another look at what's available, and libetpan
(http://libetpan.sf.net/libetpan/) sounds like a decent alternative. It
pulls in quite a bit of other dependencies, though.

There's also libtinymail (http://tinymail.org/) which has a lot less
dependencies, but a quick look through its API docs didn't seem promising.

> two NLs terminate the message, that's such an ancient rule, that should
> really be working with an SMTP library, shouldn't it?

\n\n terminate the header, the message is terminated with \n.\n (which
is guarded against by libesmtp).

It's not as bad as it sounds.

Let me try summing up how libesmtp works..

First of all, it stores the headers we explicitly set in a separate
structure, which is fine. When setting header values, libesmtp itself
does not guard against embedded newlines, but we can either replace
newlines with a space, to clean up headers, or add a space after each
newline:

  ,----
  | Header: blah blah
  |  blah blah
  |  blah
  `----

This is valid MIME. Replacing newlines is easier, though.

Anyway, when libesmtp gets around to process the body, it scans it for
headers, in case some were set there too. Sadly, I couldn't find a way
to stop it from doing so. Therefore, extra care will need to be taken to
format the body correctly...

Mngh. Now that I thought it through, I'll start to evaluate libetpan
instead, even if it has more dependencies.
  
-- 
|8]