On 15.08.15 06:31, Ian Zimmerman wrote: > On 2015-08-15 21:29 +1000, Erik Christiansen wrote: > > >>> > > 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.
The point being made in its context is that procmail runs external commands in a forked sub-process, thus expecting something different in certain circumstances doesn't make much sense. But let's find evidence which can make your case more convincing. Taking a look in variables.c, where asenvcpy(src) copies assignment text to buf, using memcpy, the only application of a linebuf limit is w.r.t. the _name_ of the variable. However, in allocbuffers(lineb,setenv), buf is malloced to a size of lineb+2, which is LINEBUF+2. Thus procmail has in fact not handed the environment variable assignment to the shell, but implements that final copy from stdout itself, with the consequential LINEBUF limitation. (In sputenv(a), we read "/* ... then add it to both environments */", so without unravelling all the memcpy and strcpy stuff going on in the various functions, it does seem that procmail is also maintaining a private copy.) ... > > 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? Now you've lost me. If procmail aborts the spam, then it won't be seen, and we're well rid of it. It is a bit far-fetched that a spammer would help us by sabotaging his efforts. It would only serve to obviate any need to consider my upthread observation: "If they ever did materialise in the real world, my response would probably be a recipe which sent them to /dev/null." Would it, in fact, not be your proposed "| head -c $LINEBUF" which would preserve the spam, helping it to get through? With a default LINEBUF of 2048, I still see this as a non-event (it does observably not occur in the wild), which would cause no undesirable outcome if it were artificially forced. It's been interesting, though, to have a look at what could have been an issue if it could reasonably be triggered, such that the abort would have been anything but welcome. Erik
