Balazs Scheidler <bazsi@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]