On 2015-08-15 21:29 +1000, Erik Christiansen wrote: > > The assignments and substitutions of these environment variables > > are handled exactly like in sh(1) (that includes all possible > > quotes and escapes),
> It would be a mistake, I think, to expect that mutt replicates sh > internally, just to inflict on itself a $LINEBUF limit. That system > commands are executed in a subshell is confirmed here: > >>> > Environment variables set inside the shell-interpreted-`|' action part > of a recipe will not retain their value after the recipe has > finished since they are set in a subshell of procmail. To make sure the > value of an environment variable is retained you have to put the > assignment to the variable before the leading `|' of a recipe, so that > it can capture stdout of the program. > <<< But this has no bearing on the situation being discussed, since we're talking about an assignment _outside_ of a recipe action. > I.e. environment variables set by shell actions are set by the > implementing (sub)shell. Since the shell can do it all, why would one > hobble things by unnecessarily involving mutt? ... > Verifying shell behaviour is one thing, but your point, AIUI, is that > excessive pipe output to an environment variable should overflow mutt's > rcfile-reading line buffer. To test that hypothesis, I think it'd be > more germane to set LINEBUF to 128 (the minimum possible), and throw a > full two-line subject header at mutt. ITYM procmail. Actually, I _know_ that procmail expands such assignments eagerly just as sh does. How do I know? Because I do the following: DUMMY_SLEEP_SINK=`sleep 600` at top rc level, without ever using DUMMY_SLEEP_SINK afterwards. And it works as expected. Now, that still leaves the possibility that the manpage text regarding LINEBUF overflow somehow doesn't apply, but I think any reasonable Unix lawyer will conclude that it does. > If that could trigger an abort, then you'd have a point in theory, i.e. > that a message with 3500 lines of subject header could cause mutt to > abort the message when using a 250K LINEBUF. I don't know how many hundreds > of millions of posts there are in the world's mail archives, but if this > discussion is for real, then I invite you to show me _one_ such post in > the wild. (One with 2048 characters of subject, even? That's over 27 > lines of 72 characters.) Does it really seem so far-fetched that a spammer, for instance, will pull such a trick to ensure their spam is seen? I don't use procmail for this (Subject) purpose, but I have gone through my rcfile and where I saw similar constructs (potentially unbounded shell output assigned to variables) I added "| head -c $LINEBUF". -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court.
