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