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

[Gergely Nagy]

Balazs Scheidler <bazsi at balabit.hu> writes:

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

It crashes, because it has a list of headers that it treats specially:
they have special getter/setter functions, and the Date header is one of
them, and it wants a time_t, yet, in the body, there's a string, and it
does not attempt to parse it, it just treats the string pointer as if it
was a time_t, and that leads to all kinds of nasty stuff, that in the
end results in a crash.

See the header_actions array in headers.c, and the set_date(),
print_date() functions in the same file.

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

Yep, agreed. I'll be sticking with libesmtp, and either fixing its bugs
and submitting them upstream, or working them around.

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

Hrm, that's a possibility, yeah, I didn't check \r\n, nor that part of
the libesmtp code (yet).

-- 
|8]