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(a)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(a)lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/smartlist
Just to clarify, as the original poster:
I was talking about X-Commands in the body of the message. I don't
think I can, using GroupWise, control or change any headers other than
the To:, Subject:, CC:, and BCC: headers.
I'll be putting Richard's suggestion, using the perl script, into
effect this week, and will report back on my success in doing in, and if
it needs any further modifications.
Thank you all very much for your suggestions and clarifying comments.
-Kevin Zembower
>>> "Richard G. Ball" <Richard_Ball(a)merck.com> 07/17/02 12:17PM >>>
On [2002-Jul-17] Tim Pierce <twp(a)rootsweb.com> wrote:
> In article <20020716202554.GA76902(a)actis2.merck.com>, Richard G. Ball
<Richard_Ball(a)merck.com> wrote:
> > On [2002-Jul-16] Tim Pierce <twp(a)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(a)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
--
richard_ball(a)merck.com
(I regret the presence of the legal disclaimer but I have no control
over it)
------------------------------------------------------------------------------
Notice: This e-mail message, together with any attachments, contains
information of Merck & Co., Inc. (Whitehouse Station, New Jersey, USA)
that may be confidential, proprietary copyrighted and/or legally
privileged, and is intended solely for the use of the individual or
entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by e-mail and then delete it.
==============================================================================
_______________________________________________
Smartlist mailing list
Smartlist(a)lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/smartlist
I'm working on a freebsd 4.3-R server.
Went to the ports, installed procmail 3.22
Downloaded Smartlist 3.15 and untar-d overtop.
Went to
/usr/ports/mail/procmail/work/procmail-3.22/SmartList
added the user:group slist... edited sendmail.cf to add the trusted user.
Then I run:
./install.sh /home/slist
and I get:
make: don't know how to make gethome.c. Stop
Any suggestions?
Thanks.
-Gerry
This is not a strictly smartlist question, but hoped someone might
have a recommendation.
I am the administrator for a non-profit groups website (and email
lists). The members (including myself) are all volunteers, using their
own software (in other words, there is no standard!).
One of the lists (about 200 members) used to notify members of urgent
news has been set up as moderated and works fine (for me). The actual
list moderator uses Juno (need I say more). I had added a recipe in
RC.LOCAL.S10 to capture an "Approved" message from the body and add it
to the header (since he has no way of directly affecting the header).
This works great for me, but apparently, it is somewhat random under
the Juno web based email. It appears there is no way to turn off the
HTML formatting under the Juno email.
OK, so then I create a web form that allows the moderator to fill in
the message, subject and has a password. I thought I could just let him
fill it in and then send the message to the list using a CGI script. It
seems that he can access the list and fill it in but submitting it
strips all of the info so that the CGI is never called, and he just gets
a "Can not display page" screen.
Has anyone run into similar problems or might suggest a work around?
Thanks,
David W. Gulley
Destiny Designs
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? I don't know if something's changed in our
organization, or if we just happened to not process any longer than
this, but I can see in the mail logs that an X-Command that's two long
gets broken into two lines, usually before the email address. These
X-Commands then fail.
I'm not much of a procmail user. Is it possible to tell the rc.local.00
script that if it finds an X-Command in the first line of a body, it
should concatenate all the subsequent lines into one, until it comes to
the first blank line? Then, the rule for X-Commands in the body of a
message would be that the X-Command must be the first line in the body,
and must be followed by a blank line.
Thank you for your help and suggestions.
-Kevin Zembower
-----
E. Kevin Zembower
Unix Administrator
Johns Hopkins University/Center for Communications Programs
111 Market Place, Suite 310
Baltimore, MD 21202
410-659-6139
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? I don't know if something's changed in our
organization, or if we just happened to not process any longer than
this, 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.
I'm not much of a procmail user. Is it possible to tell the rc.local.00
script that if it finds an X-Command in the first line of a body, it
should concatenate all the subsequent lines into one, until it comes to
the first blank line? Then, the rule for X-Commands in the body of a
message would be that the X-Command must be the first line in the body,
and must be followed by a blank line.
Thank you for your help and suggestions.
-Kevin Zembower
-----
E. Kevin Zembower
Unix Administrator
Johns Hopkins University/Center for Communications Programs
111 Market Place, Suite 310
Baltimore, MD 21202
410-659-6139
I know you want to look at pussy, but first you need to learn The Truth about the adult industry:
Get Into Paysites Free!
If you take 2 minutes to read what I have to say you will have full access to some of the largest membership sites for free.
http://www.americanteensluts.com/fpp/rune/rune2.html
This costs you nothing!
At 9:52 AM -0400 7/13/02, smartlist(a)informatik.RWTH-Aachen.DE is rumored to
have typed:
> <html><!doctype html public "-//w3c//dtd html 4.0 transitional//en">
> <html>
> <head>
> <meta name="GENERATOR" content="Mozilla/4.77 [en] (Windows NT 5.0; U)
>[Netscape]">
> <title> Free porn passes to all the top sites
> </title>
Hum...interesting (but not terribly surprising) that Mailman can be fooled
by something so embarassingly simple. SmartList wouldn't be (assuming
foreign_submit is unset, which is the only way to run a list nowadays), since
the list name wouldn't be within the dist file. (If one sets up a digest the
"normal" way, subscribing the digest to the interactive, it might get
distributed to a digested list, however.)
Charlie
My SmartList log file is filled with these line:
procmail: Extraneous deliver-head flag ignored
It occurs in clusters of various sizes.
Anyone know what's causing it and how to get rid of it?
Thanks,
Harshal
=====
http://www.mumbai-central.com : Where Mumbaikars meet
__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
The main new feature of confirm 1.2.6 is a check of the given email address
for conformity to RFC822. The most requirements of RFC822 are matched, one
exception are addresses with the local part in double qotes (I never
heard about a need for it).
If someone sends an invalid address like bla;user(a)dom.com an error message
is send back and no subscription or cookie creation happens. On the other
hand addresses with uncommon characters in the local part (*+#?%$) are
allowed.
confirm 1.2.6 is available at
ftp://ftp.pure.ch/pub/smartlist/
Werner
