Well, I would be laughing too, if the answer was so simple. However, I think it is not.
We're using GroupWise here. As far as I can tell, there's no option to turn on or off automatic line wrapping by the user. As an experiment, I typed a message from myself (on a Win PC using GroupWise) to myself (on a Linux host). In this message, I typed one long line with no hard returns. I examined the message on the Linux host, using both PINE, and catting the /var/spool/mail file. Both showed the message broken into lines shorter than 72 characters.
I'm stuck with this system. I don't run the email system, and the folks who do are not amenable to suggestion.
So, are there any alternative solutions?
Thank you, Charlie, for giving me a hand.
-Kevin Zembower
Charlie Summers charlie@lofcom.com 07/16/02 12:46PM >>>
At 9:47 AM -0400 7/16/02, KEVIN ZEMBOWER is rumored to have typed:
Are there any scripts or work-arounds for the problem of X-Command
lines
in the body of an email message being broken into two lines if
they're
longer than 72-80 characters?
ROTFLMAO!
(Sorry, couldn't resist.)
I don't know if something's changed in our organization, or if we just happened to not process any longer than this,
...or if client defaults were changed, or more likely people who don't know any better were hired...
but I can see in the mail logs that an X-Command that's too long gets broken into two lines, usually before the email address. These X-Commands then fail.
Ok, now sit down and brace yourself. THe solution requires no additional programming, indeed practically no computer-based work whatsoever on your part. But you're going to feel a little silly when I tell you the solution is to...
Tell your people to stop word-wrapping their outbound messages.
He, he...this isn't a procmail problem, nor is it a SmartList problem. The X-Command: is being wrapped by the CLIENT (that is, these people have word-wrap set to say 80-characters, and their client adds a hard return to wrap the text for a human reader), so teach your people how to properly turn off word-wrapping. In Eudora, it's simple to do on a per-message basis (there's a little clickable icon on each composition window); in Outhouse Expressed, lord only knows how many hoops they'll need to jump through.
But this "Suspicious X-Command Format" problem isn't yours, it's theirs.
Charlie (who _refuses_ to consider possible procmail-based solutions to rebuild the X-Command line when the senders are hard-wrapping their messages)
_______________________________________________ Smartlist mailing list Smartlist@lists.RWTH-Aachen.DE http://MailMan.RWTH-Aachen.DE/mailman/listinfo/smartlist
At 2:23 PM -0400 7/16/02, KEVIN ZEMBOWER is rumored to have typed:
So, are there any alternative solutions?
Stop using X-Commands and start manually manipulating the dist file. Set up a web-based front-end on a unix box using sendmail (or another "real" Internet email server) and send your X-Commands that way (unless this brain-dead server also force-wraps INBOUND email). Tell the idiots in MIS that their system is causing you a reproducable problem, and when they refuse to fix it, contact their superior with complete details.
(*sigh*) Ok, ok, so write yourself an overly-involved shell script invoked by rc.local.r00 that checks for a specific key in the mail, and builds with formail the X-Command: header field based on a specifically-formatted email message. (What a friggin' waste of time and energy, though.)
Charlie
In article sd342c82.076@ccp2.jhuccp.org, KEVIN ZEMBOWER KZEMBOWER@jhuccp.org wrote:
We're using GroupWise here. As far as I can tell, there's no option to turn on or off automatic line wrapping by the user. As an experiment, I typed a message from myself (on a Win PC using GroupWise) to myself (on a Linux host). In this message, I typed one long line with no hard returns. I examined the message on the Linux host, using both PINE, and catting the /var/spool/mail file. Both showed the message broken into lines shorter than 72 characters.
I'm stuck with this system. I don't run the email system, and the folks who do are not amenable to suggestion.
So, are there any alternative solutions?
It's supposed to be legal to break headers into multiple lines by adding whitespace at the front of each "continuation line." According to the mail specs, these headers should be considered equivalent:
X-Command: twp@rootsweb.com password subscribe joe@example.com
and
X-Command: twp@rootsweb.com password subscribe joe@example.com
So you could try forcing the issue by breaking the X-Command into these continuation lines yourself well before the 72-character limit. I don't know if SmartList/procmail will actually handle the continuation line correctly, but it seems like it ought to.
Tim wrote,
| It's supposed to be legal to break headers into multiple lines | by adding whitespace at the front of each "continuation line." | According to the mail specs, these headers should be considered | equivalent: | | X-Command: twp@rootsweb.com password subscribe joe@example.com | | and | | X-Command: twp@rootsweb.com password | subscribe joe@example.com
And there you have it. Tim indented the word "subscribe" when he sent his post but somewhere between his keyboard and my screen, the indentation was eaten by something beyond his control or mine. (Yes, I do regularly receive mail with indentations in the text.) The same thing is happening to Kevin's list maintainers.
My only suggestion is to tell them to leave a blank line below the top-of-the-body X-Command:'s arguments and any other text. Then, a recipe like this ...
:0Bbfw # note trailing period in condition * $ ^^X-Command:(.*<)?$password(>.*)^. | sed '2,/^$/s/./ &/'
will indent the wrapped lines into proper continuation lines. It does require the password to get onto the top line before the first break. Hmm... it is possible to get rid of the blank line at the neck (and thus move the X-Command: into the head) in the same sed invocation, but I'm too headachy to write the sed code for that right now.
In article 005301c22d05$2bc348a0$21985742@il.sprintbbd.net, David W. Tamkin dattier@ripco.com wrote:
Tim wrote,
| X-Command: twp@rootsweb.com password | subscribe joe@example.com
And there you have it. Tim indented the word "subscribe" when he sent his post but somewhere between his keyboard and my screen, the indentation was eaten by something beyond his control or mine.
Oof. That *is* disturbing.
(Yes, I do regularly receive mail with indentations in the text.) The same thing is happening to Kevin's list maintainers.
You're only assuming that it's the same thing. Kevin's chief problem is not indentation, it's that their internal mail system forces line-breaks at 72 characters. Your mail system is not forcing line breaks. Q.E.D. the problem they are having is not the same as the one you just witnessed.
Kevin's list maintainers may also have problems with indentation, but it doesn't follow from what we've been told.
I wrote,
Tim indented the word "subscribe" when he sent his post but somewhere between his keyboard and my screen, the indentation was eaten by something beyond his control or mine. ... The same thing is happening to Kevin's list maintainers.
Tim objected,
| You're only assuming that it's the same thing.
No, you're only assuming that they can't be. In my viewpoint, the two are the same.
| Kevin's chief problem | is not indentation, it's that their internal mail system forces | line-breaks at 72 characters. Your mail system is not forcing line | breaks.
No argument there. But where you see two symptoms, I see one disease.
Your text as delivered was so different from what you had typed that the intent was masked; I had to figure it out by seeing that the formatting conflicted with the meanings of the words. Their text as delivered is so different from what they type that the intent is masked; Kevin has to figure it out by seeing that the formatting conflicts with the meanings of the words. That's what I call "the same thing."
| Q.E.D. the problem they are having is not the same as the one | you just witnessed.
QED, what we just witnessed with the lost indentation on your earlier post is the same annoyance as Kevin's users are experiencing with the imposed line breaks: software outside the sender's control (or selection) that cavalierly reformats text in ways that end up masking the sender's intention.
You see one problem of software that removes desired indentation and another of software that inserts undesired line breaks; I see a single one of overruling the sender's specific needs with the software author's general formatting preferences in an arrogant or narrow assumption that (s)he knows how to present the sender's writing -- without knowing who the sender will be or what (s)he will be saying -- better than the sender does. In my view, the indentation matter and the line break trouble are not two unrelated issues; it should be one project to put some reins on automated reformatting.
On the other hand, Tim also wrote, addresing Richard Ball,
| I understood his message to say they were already putting X-Commands | in the body.
So did I.
On [2002-Jul-16] Tim Pierce twp@rootsweb.com wrote:
In article sd342c82.076@ccp2.jhuccp.org, KEVIN ZEMBOWER KZEMBOWER@jhuccp.org wrote:
We're using GroupWise here. As far as I can tell, there's no option to
[snip]
So, are there any alternative solutions?
It's supposed to be legal to break headers into multiple lines by adding whitespace at the front of each "continuation line."
[snip]
So you could try forcing the issue by breaking the X-Command into these continuation lines yourself well before the 72-character limit. I don't know if SmartList/procmail will actually handle the continuation line correctly, but it seems like it ought to.
If Kevin can't turn off line-wrap he probably can't enforce headers either :-(
Since x-commands are not common there isn't much of a performance penalty for using the Perl sledge-hammer to make things fit. So: put the x-command in the body on as many lines as needed and then in rc.local.r00 do:
:0 B * $ ^[ ]*/$\X_COMMAND:.*[^ ] { # Remove the X_Command from the body, and insert it in the header
# allow it to extend over multiple lines. the perl script concatenates the # whole body together and removes irrelevant whitespace. this is then fed back # to procmail to extract the command and put it in the header.
:0 fw |perl -ne 'if(/^$/ .. eof()) {chomp;push(@l,$_);}else{print;}if(eof()){forea ch (@l){$i++;last if /__END/}$l=join(" ",@l[0..$i-1]);$l.="\n";$l=~tr/ / /s;$l= ~s/^\s+//;$l.=join("\n",@l[$i..$#l]);print "\n$l\n";}'
:0 B * $ ^/$\X_COMMAND:.*[^ ] { :0 fw | grep -v "^$X_COMMAND:" | formail -I"$MATCH" }
}
Note: this assumes there are no x-commands in the headers (if there are you need to account for that case separately. I think the above comes out of code Alan Stebbens put out for handling this "problem".
Rich
In article 20020716202554.GA76902@actis2.merck.com, Richard G. Ball Richard_Ball@merck.com wrote:
On [2002-Jul-16] Tim Pierce twp@rootsweb.com wrote:
So you could try forcing the issue by breaking the X-Command into these continuation lines yourself well before the 72-character limit. I don't know if SmartList/procmail will actually handle the continuation line correctly, but it seems like it ought to.
If Kevin can't turn off line-wrap he probably can't enforce headers either :-(
I understood his message to say they were already putting X-Commands in the body. Our SmartList installation includes this recipe, which I believe does the same thing that yours did without the benefit of Perl:
:0 Bhfw # concatenate header and body * $^^$X_COMMAND: | formail -X ""
I'm not certain this is in the default code but I'm pretty sure I didn't write it.
On [2002-Jul-17] Tim Pierce twp@rootsweb.com wrote:
In article 20020716202554.GA76902@actis2.merck.com, Richard G. Ball Richard_Ball@merck.com wrote:
On [2002-Jul-16] Tim Pierce twp@rootsweb.com wrote:
So you could try forcing the issue by breaking the X-Command into these continuation lines yourself well before the 72-character limit. I don't know if SmartList/procmail will actually handle the continuation line correctly, but it seems like it ought to.
If Kevin can't turn off line-wrap he probably can't enforce headers either :-(
I understood his message to say they were already putting X-Commands in the body.
Oh. Then why did you say:
On [2002-Jul-16] Tim Pierce twp@rootsweb.com wrote:
It's supposed to be legal to break headers into multiple lines by adding whitespace at the front of each "continuation line."
[example snipped]
So you could try forcing the issue by breaking the X-Command into these continuation lines yourself well before the 72-character limit.
Which seemed to be asking Kevin to put short *header* lines into the message with whitespace to cause "continuation"?
That was why I emphasized the body-centric approach since Kevin was saying he was using x-commands in the body.
Rich
When Tim said,
: I understood his message to say they were already putting X-Commands : in the body.
Richard asked,
| Oh. Then why did you say: | | On [2002-Jul-16] Tim Pierce twp@rootsweb.com wrote: | > It's supposed to be legal to break headers into multiple lines | > by adding whitespace at the front of each "continuation line."
As anyone can tell from my post of a couple hours ago I wouldn't claim to speak for Tim, so I offer this not as an explanation of what he meant but rather as my reason for not seeing any contradiction in the two passages that Richard has quoted from him.
When X-Command: is placed at the top of the body, a recipe such as this:
:0Bhf * ^^X-Command: | formail -X ""
removes the blank line between the original headers and the X-Command:, making the X-Command: line (and any indented continuation lines that follow it consecutively) part of the head, where procmail will find it.
The more recent quote from Tim (the one presented higher in this post) describes the message when it leaves the sender's keyboard, before the application of that filter, when X-Command: is still in the body. The older quote (the one appearing later in this post) pertains to the message after it has gone through that filter and X-Command: is now in the head.
In article 20020717161707.GA85467@actis2.merck.com, Richard G. Ball Richard_Ball@merck.com wrote:
Oh. Then why did you say:
On [2002-Jul-16] Tim Pierce twp@rootsweb.com wrote:
It's supposed to be legal to break headers into multiple lines by adding whitespace at the front of each "continuation line."
Which seemed to be asking Kevin to put short *header* lines into the message with whitespace to cause "continuation"?
Because SmartList handles X-Commands in the message body by moving them into the header first with that recipe. At that point they should be treated like any other header. I apologize for not explaining myself better.
On [2002-Jul-17] Tim Pierce twp@rootsweb.com wrote:
In article 20020717161707.GA85467@actis2.merck.com, Richard G. Ball Richard_Ball@merck.com wrote:
Oh. Then why did you say:
On [2002-Jul-16] Tim Pierce twp@rootsweb.com wrote:
It's supposed to be legal to break headers into multiple lines by adding whitespace at the front of each "continuation line."
Which seemed to be asking Kevin to put short *header* lines into the message with whitespace to cause "continuation"?
Because SmartList handles X-Commands in the message body by moving them into the header first with that recipe. At that point they should be treated like any other header. I apologize for not explaining myself better.
Ahhh...(click!)...I understand. Sorry for the confusion.
Rich
smartlist@lists.rwth-aachen.de
-
Charlie Summers -
David W. Tamkin -
KEVIN ZEMBOWER -
Richard G. Ball -
Tim Pierce