Charlie said:
"Smartlist does not have capabilities out-of-the-box to permit "disable mail" (receive suspension), "receive digests" (smartlist deals with digests as seperate lists), or "receive copies of their own posts" (there is no way for a subscriber NOT to receive copies of their own posts)."
In the .bin directory within the 'subscribe' script (lines #'s are according to my distro):
90: NOT_METOO="" 91: 92: #$formail -k -xSubject: <$tmprequest | 93: # $grep 'no.*[^a-z]cop.*[^a-z]please' >/dev/null && NOT_METOO=" (-n)" 94: 95: $multigram -a "$subscraddr$NOT_METOO" dist >/dev/null 96:
119: # if $test -z "$NOT_METOO" 120: # then 121: $echo "By default, copies of your own submissions will be returned." 122: # else 123: # $echo "As requested, copies of your own submissions will not be returned." 124: # fi
Not sure what this means, but it could mean that this can be uncommented to have no copy returned to sender, when sender has subscribed with 'no copy please' included in the subject field, however why one would want to do this, i am not entirely sure??
(Aside: I apologize, because i had to mess with the subject by removing a 'Re:' in order to make my mail client send this!!)
--Joyce
On Thu, 26 Feb 2004, Joyce Miletic wrote:
Charlie said:
"Smartlist does not have capabilities out-of-the-box to permit "disable mail" (receive suspension), "receive digests" (smartlist deals with digests as seperate lists), or "receive copies of their own posts" (there is no way for a subscriber NOT to receive copies of their own posts)."
In the .bin directory within the 'subscribe' script (lines #'s are according to my distro):
90: NOT_METOO="" 91: 92: #$formail -k -xSubject: <$tmprequest | 93: # $grep 'no.*[^a-z]cop.*[^a-z]please' >/dev/null && NOT_METOO=" (-n)" 94: 95: $multigram -a "$subscraddr$NOT_METOO" dist >/dev/null 96:
119: # if $test -z "$NOT_METOO" 120: # then 121: $echo "By default, copies of your own submissions will be returned." 122: # else 123: # $echo "As requested, copies of your own submissions will not be returned." 124: # fi
See also multigram.c, line 917:
#if 0 /* metoo support removed, not supported by sendmail */ if(chkmetoo) printf("%s\n",strcmp(mp->hard+strlen(mp->hard)+1,NOT_METOO) ?metoo_SENDMAIL:nometoo_SENDMAIL); else #endif
I have the feeling that this metoo/nometoo thing is a "sendmailism", because the manpage for the MTA I use (exim) says this:
-om In sendmail, this option means 'me too', indicating that the sender of a message should receive a copy of the message if the sender appears in an alias expansion. Exim always does this, so the option does nothing.
At 3:13 AM -0500 2/26/04, Joyce Miletic is rumored to have typed:
Not sure what this means, but it could mean that this can be uncommented to have no copy returned to sender, when sender has subscribed with 'no copy please' included in the subject field, however why one would want to do this, i am not entirely sure??
At 7:48 AM -0500 2/26/04, Santiago Vila is rumored to have typed:
See also multigram.c, line 917:
None of this was finished, AFAIK, and was "stubbed" for future work.
I am also, frankly, unclear on the current status of SmartList; my guess is that it is feature-frozen in the "canonical" release (bug-fix only), although we users are always screwing around adding things that make our lives easier. (Witness the confirm routines which SHOULD be added to cannonical release, IMHO, etc.) Enlightenment from anyone in the procmail/SmartList dev team would be greatly appreciated (although I'm not certain anyone on the dev team actually _reads_ this list anymore).
Anyone who needs it is more than welcomed to rework/add/test the NOMAIL routines; if you do, please feel free to share with the rest of us in the class.
Charlie
On [2004-Feb-26] Charlie Summers charlie@lofcom.com wrote:
I am also, frankly, unclear on the current status of SmartList; my guess is that it is feature-frozen in the "canonical" release (bug-fix only), although we users are always screwing around adding things that make our lives easier. (Witness the confirm routines which SHOULD be added to cannonical release, IMHO, etc.) Enlightenment from anyone in the procmail/SmartList dev team would be greatly appreciated (although I'm not certain anyone on the dev team actually _reads_ this list anymore).
It looks pretty clear there is no future for Smartlist, which is a shame. Steven put togther a very nice package for its time but the world has changed around it and Smartlist desperately needs to be brought up to date. Don't get me wrong, I still like working with it (I even selected my webhost *because* they give me procmail and smartlist) but, out-of-the-box, it is missing much needed functionality (and even with add-ons it still needs lots of hand-holding).
Rich
------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan as Banyu) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. ------------------------------------------------------------------------------
smartlist@lists.rwth-aachen.de
-
Charlie Summers -
Joyce Miletic -
richard_ball＠merck.com -
Santiago Vila