All,
I am trying to use rc.local.s10.mhonarc from
http://www.ha-schneider.de/software/smartlist/
to set up an archive for a mailing list.
I have renamed rc.local.s10.mhonarc to rc.local.s30 and added following line to rc.custom
RC_LOCAL_SUBMIT_30 = rc.local.s30
rc.local.s10 and rc.local.s20 are already in use and since I do not know how to merge the recipe in rc.local.s10.mhonarc with either of the two, I renamed it to rc.local.s30 and added a new line in rc.custom.
Could someone please help me understand as to how it all works.
Thanks
Nishi
The following is a sample of the results of a search that I receive by email.
This there a way to hide the line number?
ARCHIVE egrep august latest/*
BEGIN---------------cut here------------------
latest/10:16:Monday, August 27, 2001
latest/11:16:Tuesday, August 21, 2001
latest/12:16:Wednesday, August 29, 2001
END-----------------cut here------------------
Thanks for your help!
Alan,
hi!
how can i modyfiy the text for the automatic subscribe/unsubscribe-mail?
The possibilities of a *subscribe.txt*-file in my folder are not enough for
me. I want suppress the information about the transmited data and translate
the rest of the mail to german.
TIA, martin
--
"Who needs horror movies when we have Microsoft?"
- Christine Comaford, PC Week
Hello:
Does SmartList have an archiving and (hopefully user friendly) search capability?
[I'm not interested in the archives of this Disc List, but of the list I run for my
'users'].
Thanks,
Mitch Darer
--
Mitchell Darer, WebMaster, mitch(a)focusing.org
The Focusing Institute, 34 East Lane, Spring Valley, NY 10977
http://www.focusing.org (845) 362-5222 (phone/fax)
At 11:41 AM -0400 7/28/00, Werner Reisberger is rumored to have typed:
> I never saw any
> admin reply to the numerous complains about spam messages.
Actually, that's not _strictly_ true, since I remember when Stephen was
actually maintaining the list (and probably anally have archives of the list
from that time somewhere on some floppy or MO cart from a long time ago and
far far away). But you're right, it's been _years_ since he's been around.
However, the list belongs to the maintainer (or at least the machine's
admin), not the members. You'll get no argument from me that the list should
be moved (I believe I said exactly that a couple of times), but to suggest
the admins need to take a poll to ask what they may or may not do with the
existing list is silly, to say the least. They are certainly able to move
this list to mailman without the list subscriber's permission - indeed, they
_have_ done so, which makes my point for me.
Whether we should move this list to a SmartList server is a completely
seperate issue...one which Philip should probably weigh in on, since he is
now maintaining the procmail/SmartList source and as such the de facto head
of our band of merry wanderers...
Charlie
Currently my Smartlist saves mail archive with permission 660 and
group of the list account, like in:
-rw-rw---- 1 slist slist 1860 Jun 6 09:38 4298
How may I change it to save with permission 644 or with a
different group? (I have already made ~slist a member of another
group), like in
-rw-r--r-- 1 slist slist 1860 Jun 6 09:38 4298
-rw-rw---- 1 slist web 1860 Jun 6 09:38 4298
I guess it would be somewhere in rc.submit but appreciate any hint.
Thanks,
Zhiliang
Rich noted:
> > Has anyone experimented with or implemented something like this?
>
> Not with metamail. I used stripmime because it was much more
> straightforward for me.
>
> Rich
I'll take a look at stripmime, too - thanks.
--
Rick DeMattia <rad(a)nshore.org>
The secret of the universe is|^&*||x|NO CARRIER
Has anyone had success using metamail -d and a severely pruned mailcap file, to
process incoming messages to plain text before other list processing? A number of
my subscribers are simply unable to understand the concept of plain text, yet I
don't want to permit text+HTML and assorted garbage to be distributed by the list.
I have been tinkering a little with a mailcap:
application/* ; cat %s >> /dev/null
image/* ; cat %s >> /dev/null
text/enriched ; richtext -e %s
text/html ; cat %s >> /dev/null
text/richtext ; richtext %s
Interactively
MAILCAPS=/that/specific/mailcap metamail -d < message-with-image-attached
seems to offer possibilities.
I know there are other solutions to this that use perhaps perl or some other tools,
but I'd like to use the stock metamail distribution to solve this if it will.
Has anyone experimented with or implemented something like this?
--
Rick DeMattia <rad(a)nshore.org>
The secret of the universe is|^&*||x|NO CARRIER
On Mon, 20 Jun 2005, dmacdoug wrote:
> On Mon, Jun 20, 2005 at 01:45:07PM -0500, Zhiliang Hu wrote:
> >
> > Yes I deleted it and when there is a post to the list, it is created
> > again, with the posting in the file. [Note: (the "cat" file in the
> > list dir has a permission 665, strange, ah? ... I have "umask 002" in
> > my rc.init).
>
> For whatever it's worth, my UMASK is 007. I wouldn't think anyone outside
> of user or group should need rights to the files created, certainly not
> execute rights.
My "umask 002" allows it to save archive mails with "664" permission,
which allows the web server to read (this should be 666-002=664 ...
but I don't know why this odd file is in a strange 665 mode).
[I tried to work the httpd through shared groups but some other
problems on the way]
> > I am not sure if this is a good idea but should I change the ../.bin/
> > files to add the path to the excutables? [like "cat=/bin/cat"; now it
> > is "cat=cat"]
> >
> > Zhiliang
>
> The problem with putting the explicit path into the variable assignment like
> that is that, although it might possibly avoid the error, this variable is
> assigned in at least half a dozen different scripts, so it would probably
> need to be modified everywhere. And it shouldn't be necessary. Also, it
> doesn't attack the root of the problem.
>
> I suspect that, in some file which has been modified, there's an error in a
> procmail script which is creating this extra copy of the messages in this
> file.
>
> I'm no procmail whiz, and every time I want to make one I have to relearn
> it, it seems, so I'm no one to follow, but I would start by looking at every
> file that I'd modified and doing a diff between it and an unmodified version
> to make sure that none of my changes, purposeful or accidental, could be
> doing that.
You are exactly right ... I have been doing just this. The trouble is
I migrated an old list with a number of rc files brough in, and it may
take somewhile to test each. I thought a sharper eye could help .. ;-)
> Don
Thanks a lot!
Zhiliang
Yes I deleted it and when there is a post to the list, it is created
again, with the posting in the file. [Note: (the "cat" file in the
list dir has a permission 665, strange, ah? ... I have "umask 002" in
my rc.init).
I am not sure if this is a good idea but should I change the ../.bin/
files to add the path to the excutables? [like "cat=/bin/cat"; now it
is "cat=cat"]
Zhiliang
On Mon, 20 Jun 2005, dmacdoug wrote:
> Oops I meant, have you tried deleting that file named cat? Sorry about the
> typo.
>
> On Mon, Jun 20, 2005 at 10:48:03AM -0700, dmacdoug wrote:
> > On Mon, Jun 20, 2005 at 09:55:52AM -0500, Zhiliang Hu wrote:
> > >
> > > I got a bunch of errors like following in my Smarlist log file:
> > >
> > > ../.bin/subscribe: line 1: ./cat: Permission denied
> > > ../.bin/subscribe: line 112: ./cat: Permission denied
> > > ../.bin/subscribe: line 123: ./cat: Permission denied
> > > ../.bin/subscribe: line 140: ./cat: Permission denied
> > > ../.bin/subscribe: line 142: ./cat: Permission denied
> > > ../.bin/arch_retrieve: line 1: ./cat: Permission denied
> > > ../.bin/arch_retrieve: line 312: ./cat: Permission denied
> > > ../.bin/procbounce: line 142: ./cat: Permission denied
> >
> > ...
> >
> > > One odd thing is every successfully posted mail is saved into a
> > > file called "cat" in the list directory.
> >
> > Have you tried simply that file named cat? It looks to me like it's trying
> > to execute that file rather than the binary file /bin/cat which should be in
> > your path. Why it's been created in the first place is another question.
> >
> > Don M.
>