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

[Balazs Scheidler]

Hi,



On Fri, 2011-03-04 at 16:53 +0100, Gergely Nagy wrote:
> Balazs Scheidler <bazsi at balabit.hu> writes:
> >> >> 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.
> 

I did review the libesmtp code this time, and as far as I can see,
libesmtp tries to be smart by extracting headers from the message body,
and it adds them only in case they are missing and would be required by
SMTP.

> >> 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've checked this and the problem is that libesmtp is quite strict about
that header/body separator. It must be "\r\n" and not just a mere "\n".
I'm not sure why it crashes though.

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

I don't like that. It is complete with MIME envelopes and base64
encoding which seems a bit heavyweight.

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

true, I wanted to write separate the header from the body.

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

using \r\n would work. Let me see if I can create a patch to fix thes
problems.  

-- 
Bazsi