I'm doing this on the system I have this e-mail account with,
eskimo.com. It's an old-fashioned geek's ISP, where I have a shell
account on a shared server, rather than a slice, or fancy web-thingies
to handle everything. They're running up-to-date procmail, smartlist
and sendmail.
I've asked support if there are any local configuration considerations
that might be affecting things. I should have a reply in a day or so.
The issue I have is things that ought to work don't, and I suspect
something about the context prevents it, or else I've missed something
I'm supposed to be doing, like escaping characters or putting ticks or
quotes around the regex... though I've not seen any examples that tell
me I should.
I'm trying to extract the boundary string from multipart MIME formatted
messages into a variable so I can do futher processing. This is
happening in rc.local.s00.
The header data will look like a variation on these examples:
Content-Type: multipart/alternative
boundary="a=bunch-of/stuff:and_random=junk"
Content-Type: multipart/alternative;
boundary=a=bunch-of/stuff:and_random=junk
What's reliable is Content-Type: multipart/* occurs on one line; the
boundary string will not contain quotes, backslashes, semicolons or
whitespace; the boundary string is either at the end of the first line
or on a line of its own; whether multi-line or concatenated, the
various pieces are separated by semicolons or whitespace.
As I understand it, the egrep for procmail recipe condition lines
assumes the c flag, and treats multi-line headers as single lines.
Thus, the following recipe works up to a point, even though the '.'
token should not ever match a newline.
I know there are recipes out there for doing this, but I'm stumped as
to why the following approach doesn't work (yet) and am trying to learn
the reason before I just give up and do something else.
Here's the basic strategy:
TESTVAR = 'some initial value'
:0 fhw
* ^content-type:.*multipart.*boundary=\/.*
{
TESTVAR = $MATCH
}
In the two examples above, it yields the following in $TESTVAR:
Example 1) "a=bunch-of/stuff:and_random=junk"
Example 2) a=bunch-of/stuff:and_random=junk
One initial oversight of this recipe is that it won't deal with a multi-
line header where there's another sub-header after the boundary= line.
It would just tack on the rest of that header, right to the end of the
last line. It ought to be easy to stop at the end of the boundary
string, but it's not, as I explain below.
At this point, I start to hit a brick wall. Nothing that's supposed to
work seems to work in this context...
I'd like to get rid of the quote marks. This recipe will strip the
leading quote, at least, but will not match anything if the boundary
string is unquoted, as it is on many messages:
:0 fhw
* ^content-type:.*multipart.*boundary="\/.*
The following ought to solve that problem by matching either 0 or 1
occurrences of the double quote after the equals sign:
:0 fhw
* ^content-type:.*multipart.*boundary="?\/.*
It doesn't. The string still shows up in $MATCH and $TESTVAR with both
quote marks intact. WHY?
Every other syntax I've tried (dozens of them!) refuses to function in
this context, either not changing the value of TESTVAR, setting it to a
null string, or blithely ignoring the quote mark and letting it go
through into $MATCH.
After the \/ token, it seem to be TRIVIAL to match any character that
wasn't a quote, semicolon or whitespace, and that would capture the
entire boundary string... AND solve the multi-line problem -- but,
again, absolutely none of the applicable syntax wants to work here.
So, what is it about the context that refuses to let me do an elective
match on the leading quote mark and prevents almost anything except .*
from working after the \/ ? There must be something pretty basic I'm
missing here, but, damn! I've been studying this for a week and a half
steady, and I have *not* seen an explanation for this behavior.
Am I missing something else, obvious or not? Does it seem like
something in my environment is screwing it up?
I have not turned on logging yet, but will shortly. Am I right to
assume procmail logging is more important than smartlist's for this?
Any help or insight would be appreciated.
Thanks,
Mike D.
[Mike Devour, Citizen, Patriot, Libertarian]
[mdevour(a)eskimo.com ]
[Speaking only for myself... ]
I've been running SmartList for a lot of years now, mostly never need to touch it. But I've needed to move to new hardware for quite a while -- just hadn't gotten around to it. Thanks to Santiago for pointing out that SmartList is available as a package for Debian! That makes the move easier. Also, the Debian package has the Confirm package installed -- installing Confirm is another thing I should have done a while ago. Many thanks to Werner for all your good work on Confirm.
Question -- The Confirm emails come From: SmartList <list-request(a)foo.com>, while the regular subscription reply just comes From: list-request(a)foo.com. Where is the setting to control the display name, so I can replace "SmartList" with something else, or eliminate it?
Since I've never used Confirm before, I haven't run into this in the past, and I was hoping someone could point me to where the setting is located.
Thanks!
Merrick
_________________________________________________________________
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/201469230/direct/01/
M.G. Devour wrote ..
> I see from the archives that traffic on this list has been slow for a
> number of years. I wonder if there are still any enthusiasts around?
As Roger says, some of us still prefer something that doesn't use tremendous amounts of resources just to send mailing list mail. But truth is, fewer and fewer of us actually care to dig into the guts of a system...most people today want a web page to hold their hand while configuring and "managing."
Look at it this way; the low archived content means it's working _really_ well for everyone...yeah, that's it...no one has _any_ problems with it.
Charlie
Hello,
I see from the archives that traffic on this list has been slow for a
number of years. I wonder if there are still any enthusiasts around?
I'm doing some configuration work and have some questions about regex
syntax in a procmail recipe in rc.local.s00. I'll post the details if
there are signs of life!
Thank you,
Mike D.
Santiago Vila wrote ..
> I see no way to change this illiterate message.
That message is hardly "illiterate." It may not suit you, which is certainly your call (I've edited mine, in fact, for some lists), but there's nothing whatsoever wrong with it as it stands. Insulting someone else's work isn't a good way to request help.
> That text in embedded in a script called "confirm".
You've answered your own question. With the confirm add-on (confirm is not a part of the official SmartList distribution, but is an add-on available elsewhere), edit the confirm_add script. If you are unsure how to edit a shell script, contact your provider.
Charlie
Gregory Higgins wrote ..
> "Reasonable good" is incorrect English (or at the very least,
> incorrect American).
The add-on was written by someone who does not speak English as a first language, and is not an American (please read the confirm_add shell script for his name and location), so he cannot be expected to write proper American English. The Internet is, to the surprise of many in my country, not limited to American citizens.
> The incongruency grates on the ear and leaves a distinct flavor of
> illiteracy on the tongue.
Again, poppycock. A single grammatical mistake alone does not imply the writer was an illiterate or semiliterate person (you, after all, made one in your post dropping the object when referring to "incorrect American" when you meant "incorrect American English," and I'm certain you can find multiple grammatical and spelling errors in this posting, knowing my failings); it simply implies the guy screwed up _one word,_ using an adjective when an adverb was required, or screwed up _one letter,_ transposing an "e" for a "y" if one wanted to minimize the error even further. If you don't like it, change it - but don't suggest someone who wrote a much-needed add-on for SmartList without payment or even the promise of gratitude, is illiterate. He is clearly more literate, when it comes to computer programming _and_ English, than most of us here.
Basically, everybody needs to lighten up a little; the guy did one helluva lot of work so we wouldn't have to, and griping about one word which is so painfully trivial to change seems to me churlish and petty.
Charlie
charlie(a)lofcom.com wrote ..
> Santiago Vila wrote ..
Actually, he didn't, Get Meek <get(a)meek.net> did. Apologies for the somewhat...er...illiterate error on my part.
Charlie
The smartlist implementation at my ISP sends the following awkward
confirmation message to those who try to subscribe:
It has been requested that the following address:
testonly(a)test.net
should be added to the whatever mailing list.
The address has NOT yet been subscribed to the mailing list.
To subscribe you need to confirm the subscription
request by sending an email to the address:
whatever-request(a)oreg.net
with the Subject string:
CONFIRM s10240515293893
With a reasonable good email program a reply to this
message should be sufficient
I see no way to change this illiterate message. Can anyone on this list
help?
On Wed, 26 Aug 2009, Santiago Vila wrote:
> Date: Wed, 26 Aug 2009 02:26:33 +0200 (CEST)
> From: Santiago Vila <sanvila(a)unex.es>
> To: Zhiliang Hu <hu(a)animalgenome.org>
> Cc: smartlist(a)lists.RWTH-Aachen.DE
> Subject: Re: flist:_Permission_denied
>
>>> In my system:
>>>
>>> # ls -l /var/list/.bin/flist
>>> -rwsr-xr-x 5 root list 25432 ene 18 2007 /var/list/.bin/flist
>>>
>>> Those are also the permissions of the executable inside the .deb.
>>> Either those permissions were lost during the conversion to .rpm,
>>> or maybe you changed them after installing the package.
>>
>> I didn't change it. Now I chmod my flist to be:
>> -rwsr-xr-x 5 list list 25432 Jan 18 2007 /var/list/.bin/flist
>> and I still get the same "deferral:
>> /bin/sh:_/var/list/.bin/flist:_Permission_denied/" error.
>
> Two things:
>
> 1. The permissions/ownerships are not the same yet. My flist is owned
> by root, yours is still owned by list.
In my old smartlist settings it was all owned by ~list.
Okey, now I did "chown -R root list" (tested; didn't help).
I suppose it has to be owned by the ~list because ~list handles the
processes (it's the case at least in a number of my old installations).
> 2. flist is an ELF binary. Why is he trying to execute as a sh-script?
> Does your /etc/aliases have entries like these ones?:
>
> foo: "|/var/list/.bin/flist foo"
> foo-request: "|/var/list/.bin/flist foo-request"
>
> (or whatever the qmail-equivalent might be).
Yes, exactly. No idea how shell gets in the way. Any suggestion for
alternatives?
Thanks,
Zhiliang
