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:


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

Reply via email to