Sometimes a mail going through my Smartlist is seen all mail body
multi-parts in full text, like in:
___________start quote________________________________
--Apple-Mail=_550744D4-79AF-4AF1-944D-3EAEDC8521DF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
Hi everyone,
....................................
.......................................
............................
--Apple-Mail=_550744D4-79AF-4AF1-944D-3EAEDC8521DF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">Hi everyone,<div class=3D""><br class=3D""></div><div =
........................
..............................
.......................................
_________________________________end quote__________________
and sometimes an attachment is sent as BASE64 coded ascii text, which
often not being able to be decoded by most recepient mail clients. I
wonder does anyone see the similar, and what I should look into to
correct this?
Thanks in advance,
Zhiliangh
On Fri, 15 Jul 2016, Miletic, Joyce wrote:
> Date: Fri, 15 Jul 2016 15:53:13 +0000
> From: "Miletic, Joyce" <jmiletic(a)navisite.com>
> To: "smartlist(a)lists.rwth-aachen.de" <smartlist(a)lists.rwth-aachen.de>
> Cc: Zhiliang Hu <hu(a)animalgenome.org>
> Subject: Re: setup Smartlist with Postfix - alias config problem
>
> When you say, "When re-installed it works just fine.", did you mean that
> you re-installed into a different location from /home/smartlist?
>
> --Joyce M
Installed into the working location.
Zhiliang
Now I am setting up Smartlist with qmail (on a RH mamchine).
qmail is installed and tested.
Previously I only copied Smartlist over from a similar platform (RH
Linux). Now I decided to install from the source:
I unpackaged SmartList-3.15 over procmail-3.22 (I cannot find
procmail-3.15, thus by tweaking the folder name I managed to have them in
the same dirrectory "procmail-3.15").
Now when I run
> cd procmail-3.15/SmartList
> sh install.sh /home/slist
it spit out endlessly the following line:
install.sh3: line 3: cd: .: Not a directory
install.sh3: line 3: cd: .: Not a directory
install.sh3: line 3: cd: .: Not a directory
...
that evenually I had to kill the process.
Is it a version problem or else?
Zhiliang
Figured out:
it appears that the uid/gid/path are all built into the flist binary upon
install, such that when the working location of the list is different from
its installation location it cannot find the ".etc". When this happens it
turned to "/" looking for it (guessing).
When re-installed it works just fine.
Zhiliang
On Thu, 14 Jul 2016, Zhiliang Hu wrote:
> Date: Thu, 14 Jul 2016 23:13:54 -0500 (CDT)
> From: Zhiliang Hu <hu(a)animalgenome.org>
> To: smartlist(a)lists.rwth-aachen.de
> Subject: setup Smartlist with Postfix - alias config problem
>
> I am setting up Smartlist with Postfix, and put in /etc/aliases a line =
>
> like:
>
> myteam: "|exec /home/smartlist/.bin/flist myteam"
>
> the test mail gets bounced with this error: cannot open input.
> Command output: flist: Can't find ".etc" in "/"
>
> Why it's looking for ".etc" under "/"? I do have /home/smartlist/.etc/ =
>
> that's parallel to /home/smartlist/.bin/, and everything in ~smartlist =
>
> account looks identical to my old smartlists. I wonder if it's a wrong =
>
> error or something is broken somewhere?
>
> Zhiliang
> _______________________________________________
> Smartlist mailing list
> Smartlist(a)lists.RWTH-Aachen.DE
> http://MailMan.RWTH-Aachen.DE/mailman/listinfo/smartlist
>
I am setting up Smartlist with Postfix, and put in /etc/aliases a line
like:
myteam: "|exec /home/smartlist/.bin/flist myteam"
the test mail gets bounced with this error: cannot open input.
Command output: flist: Can't find ".etc" in "/"
Why it's looking for ".etc" under "/"? I do have /home/smartlist/.etc/
that's parallel to /home/smartlist/.bin/, and everything in ~smartlist
account looks identical to my old smartlists. I wonder if it's a wrong
error or something is broken somewhere?
Zhiliang
Mark - Thank you!
Zhiliang
On Thu, 18 Feb 2016, mark david mcCreary wrote:
> Date: Thu, 18 Feb 2016 10:17:22 -0600
> From: mark david mcCreary <mdm(a)internet-tools.com>
> To: Zhiliang Hu <hu(a)animalgenome.org>
> Cc: smartlist(a)lists.rwth-aachen.de
> Subject: Re: site to download Smartlist
>
>> On Feb 18, 2016, at 9:54 AM, Zhiliang Hu <hu(a)animalgenome.org> wrote:
>>
>> I need to set up Smartlist on my new server ... however the
>> http://www.procmail.org site has been down for at least the past
>> couple months (what's going on?). Anyone knows an alternative site
>> to download the latest Smartlist?
>>
>> Zhilang
>
> Good thing this mailing list is still working then :-)
>
> I'm not aware of any alternative sites, but I put up my copy of
> the tarball at
>
> http://www.mccreary.com/filechute/SmartList-3.15.tar.gz
>
> I think you will find that is the latest and greatest version.
>
> I also have a procmail tarball, if you need that. Although procmail
> should be part of the Smartlist tarball.
>
> Hope that helps.
>
> mark
>
>
> mark david mcCreary
> Internet Tools, Inc.
>
> 1302 Waugh Dr. #438
> Houston, Texas 77019
>
> mdm(a)internet-tools.com
I need to set up Smartlist on my new server ... however the
http://www.procmail.org site has been down for at least the past couple
months (what's going on?). Anyone knows an alternative site to download
the latest Smartlist?
Thanks,
Zhiliang
Problem: a person on the distribution list whose email accountname is the same as the beginning of the listname CANNOT submit to the list. Even if "person(a)xx.yy.zz" is in the file accept(dist) or accept2, when they attempt to submit to "personlist(a)xx.yy.zz" they are seen as "Not on the accept list".
I have the lastest software bits for Smartlist, in particular, for multigram.c
I can see that the problem results from multigram returning an error (when it should not).
For example, with "person(a)xx.yy.zz" in the accept file (linked to dist), and
given this in file "msg":
> Subject: got this?
> Date: Mon, 1 Dec 2014 14:07:25 -0800
> To: personlist <personlist(a)xx.yy.zz>
> From: person(a)xx.yy.zz
>
> That is really great.
> el persono
this formail|multigram pipe from rc.submit returns "worked":
if cat msg|formail -X"From " -xFrom: -xReply-To: -xSender: -xResent-From: -xResent-Reply-To: -xResent-Sender: -xReturn-Path: |../.bin/multigram -b1 -m -l28672 -Lzoology.ubc.ca -xbpersonlist(a)zoology.ubc.ca -xbpersonlist-request(a)zoology.ubc.ca accept accept2; then echo worked; else echo failed; fi
While this, with bpersonlist => personlist, fails:
if cat msg|formail -X"From " -xFrom: -xReply-To: -xSender: -xResent-From: -xResent-Reply-To: -xResent-Sender: -xReturn-Path: |../.bin/multigram -b1 -m -l28672 -Lzoology.ubc.ca -xpersonlist(a)zoology.ubc.ca -xpersonlist-request(a)zoology.ubc.ca accept accept2; then echo worked; else echo failed; fi
If someone could point to the unanchored match in the impressively dense code of multigram.c, I would be grateful. This problem happens often for me where we have a guy einstein(a)xx.yy.zz wanting to submit to his own lab's mailing list "einsteinlab(a)xx.yy.zz"
Thanks,
Alistair
Problem: a person on the distribution list whose email accountname is the same as the beginning of the listname CANNOT submit to the list. Even if "person(a)xx.yy.zz" is in the file accept(dist) or accept2, when they attempt to submit to "personlist(a)xx.yy.zz" they are seen as "Not on the accept list".
I have the lastest software bits for Smartlist, in particular, for multigram.c
I can see that the problem results from multigram returning an error (when it should not).
For example, with "person(a)xx.yy.zz" in the accept file (linked to dist), and
given this in file "msg":
> Subject: got this?
> Date: Mon, 1 Dec 2014 14:07:25 -0800
> To: personlist <personlist(a)xx.yy.zz>
> From: person(a)xx.yy.zz
>
> That is really great.
> el persono
this returns "worked":
if cat msg|formail -X"From " -xFrom: -xReply-To: -xSender: -xResent-From: -xResent-Reply-To: -xResent-Sender: -xReturn-Path: |../.bin/multigram -b1 -m -l28672 -Lzoology.ubc.ca -xbpersonlist(a)zoology.ubc.ca -xbpersonlist-request(a)zoology.ubc.ca accept accept2; then echo worked; else echo failed; fi
While this, with bpersonlist => personlist, fails:
if cat msg|formail -X"From " -xFrom: -xReply-To: -xSender: -xResent-From: -xResent-Reply-To: -xResent-Sender: -xReturn-Path: |../.bin/multigram -b1 -m -l28672 -Lzoology.ubc.ca -xpersonlist(a)zoology.ubc.ca -xpersonlist-request(a)zoology.ubc.ca accept accept2; then echo worked; else echo failed; fi
If someone could point to the unanchored match in the impressively dense code of multigram.c, I would be grateful. The problem happens a lot for me where we have a guy einstein(a)xx.yy.zz wanting to submit to his own lab's mailing list "einsteinlab(a)xx.yy.zz"
Thanks,
Alistair
Charlie - Thanks for the clarification.
I have been using it for plain text only. Now this is straight.
Zhiliang
On Mon, 17 Mar 2014, charlie(a)lofcom.com wrote:
> Date: Mon, 17 Mar 2014 13:04:07 -0400 (EDT)
> From: charlie(a)lofcom.com
> To: smartlist(a)lists.rwth-aachen.de
> Subject: Re: mail body
>
> Zhiliang wrote ..
>
>> I wonder which part of the
>> smartlist converts mordern mails to old fashioned plain text(?),
>
> It doesn't. It treats "modern mails" the same way it treats "antique
> mails;" as a stream. If you want only plain-text mails in your list,
> you need to reject or convert multipart outside of SmartList. (Well,
> ok, you can call your rejection or conversion routine, like the demime
> perl script, from any of the rc.submit.* you want, but I mean that
> SmartList cannot natively change multipart to plain text. Truth is,
> IMHO, one of the things that makes it such an excellent tool even now
> is that it _doesn't_ munge the body.)
>
>> and if I
>> can take that part out (e.g. is it in "rc.submit"? etc).
>
> There's nothing to remove. SmartList is working exactly as-designed;
> passing the message on to the list mostly the way it found it (header
> changes notwithstanding).
>
> Charlie