On 19 April 2017 at 10:45, Alexander Burger <a...@software-lab.de> wrote: > Hi Rowan, > > > On Wed, Apr 19, 2017 at 08:12:11AM +0200, a...@software-lab.de wrote: > > Rowan, are you sure? I tried your fix, but now it seems the mail > > body is lost? Any idea? > > OK, so I tried a different approach. According to "a CRLF may be inserted > before > any WSP", I simply use (peek) to see if the next line starts with white space. > Shouldn't this be enough?
Yes, that sounds more like "the right way" :-) ...as long as at least one byte of push-back is always guaranteed - like for POSIX ungetc() - and if it doesn't ever cause noticeable performance issues (apparently not - (till) seems to use the same lookahead anyway). My patch was a late-night quick-hack adapted from a sed-script of mine, to the subset of picolisp vocabulary I could easily recall, just to get the ball rolling (hence my mention that there were surely better ways to do it). As for my patch eating the message-body during your test, I can't imagine there is a difference between the spool-file (mbox) format on your mail-server compared to mine, so perhaps I fumble-fingered something while preparing the patch? otherwise the mailing-list might have messed with the attached patches when inlining them? I won't look into that though because your (peek) suggestion makes more sense (less invasive) anyway. PS: Even when using (peek) I think [A] the second patch (for not chomping the final "^J") may still be applicable (at least for the last email that appears in the spool file), and also *perhaps* [B] the first line of the main patch - for skipping trailing timestamp on the "From " line (but maybe that was just needed to deal with a side-effect of the sliding-window technique). They were both needed when testing on my internal Exim server, I'm not sure about Postfix. The second patch could be tested against your mail-server by sending it a mail with no trailing blank-line then triggering a run of the script immediately (so that the mail appears last in the spoolfile), and looking for something like this: > ... > abcdefg: this is the penultimate line > -- defg: this is the ultimate line > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe .having said that, I see from http://www.postfix.org/local.8.html > In the case of UNIX-style mailbox delivery, the local(8) daemon > prepends a "From sender time_stamp" envelope header to each message, > ..[snip].. > and appends an empty line. so maybe the worst that would happen on postfix is having a non-conformant empty line with two trailing "\r" characters... PPS: While tweaking to use the sliding-window technique, I used the following: * (chop) first line of each header * get (index) of the first " " in the first line * split the first line using (head) and (tail) based on that index * for each continuation line just (chop) then (conc) them to the tail without extra splitting-and-gluing-on-space and I think I saw a speedup (anecdotal, not officially tested). If so, then perhaps it is worth seeing if that part is useful, even when the 'peek' technique is more elegant than the sliding window technique. PPPS: I see you use (protect) to ensure spool-processing is uninterruptible by signals, but don't see file-locking of the spool-file, to avoid race-conditions with the mail-server during concurrent runs. Looking at: http://www.postfix.org/postconf.5.html#mailbox_delivery_lock and based on the output of "postfix -l" it should be trivial to add handling for its configured locking mechanism - just to avoid the "once in a blue moon" garbling/disappearance of an email being delivered during processing. -- Rowan Thorpe http://twitter.com/rowanthorpe "There is a great difference between worry and concern. A worried person sees a problem, and a concerned person solves a problem." - Harold Stephens -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
