SmartList FAQ (Frequently Asked Questions)

1.1: Introduction:

1.2: History of this document:

1.3: What is SmartList?

1.4: Is there more documentation available?

1.5: How does SmartList work?

1.6: Where can I get SmartList?

1.7: Is there a SmartList Support mailing list?

1.8: Is there an archive of the mailing list?

1.9: What's the purpose of the rc.local.* files?

They let you enhance or alter the function of SmartList by calling procmail scripts at different states of email processing.

1.10: How can I see what's going on (diagnostics)?

If SmartList sends out messages to the maintainer or the list, it adds message headers beginning with "X-Diagnostics:". Every maintainer should read these header lines to recognize problems with the list.

SmartList usually creates by default in every list a log file called "log". If you want to trace a problem with a list you can set the variable VERBOSE in rc.custom to "on". Subsequently, every processed message will create a lot of debugging information in the log file.

Don't forget to turn it off later.

2: Basic List Administration

2.1: What does "uncomment" mean?

This question seems very trivial but experience showed that many people have problems understanding how to (de)activate a variable in the rc.custom file.

To uncomment a line in the file, remove all hashmarks (#) from the front of the line (if there is more than one, be sure and remove them all), and change the value if necessary. For example, the moderate section in the standard distribution looks like this:

#moderated_flag
##moderated_flag=       yes             # uncomment this to make the list
                                        # moderated (you must create a

For example, to turn your list into a moderated list, remove the two hash marks from the line that says "moderated_flag = yes", so the section now looks like this:

#moderated_flag
moderated_flag=       yes               # uncomment this to make the list
                                        # moderated (you must create a

Note that, anything after a hashmark on a line is considered a comment, and anything before any hashmarks (if any) is uncommented. So, you can uncomment a feature setting, and still have a comment on that line, out towards the end.

To turn something off, uncomment the corresponding flag/variable name and don't assign anything to it. This turns the flag off by removing it from memory.

NOTE: The config files ship with the current running default commented out with a single hash (#), so you can see what the default is. You should probably leave that line alone. The line after that, commented with two hash marks, is typically the one you want to uncomment to change SmartList's behavior. For example, this default configuration allows non-members to send messages to the list:

#foreign_submit =       yes
##foreign_submit                        # uncomment this line if you
                                        # want to restrict submitting to
                                        # people on the accept list

Remember that in these cases if you uncomment the line that is single-hashed, it makes no difference, since the single-hashed commented line shows you what the default in rc.init is. So if that is what you want, you can leave things alone (both lines commented), since it's already set that way. If you want to change the flag, you would uncomment the double-hashed lines, like:

#foreign_submit =       yes
foreign_submit                          # uncomment this line if you
                                        # want to restrict submitting to
                                        # people on the accept list

NOTE Be sure the text editor you use saves text in "UNIX" text format, with only a newline character at the end of each line, and not a carriage-return or carriage-return newline pair. Many windows and Mac based text editors insert that carriage-return, and this can break your configuration files.

If you end up with carriage returns in your text files, you can remove them with perl, like this: (this particular example assumes the file you want to clean is rc.local.s20, change this file to be the one that needs cleaning):

perl -p -i -e 's/\r//' rc.local.s20

2.2: How do I make the list Open/Closed?

2.3: How can I disable automatic unsubscription?

2.4: How can I prevent certain people from automatic unsubscription?

Everything in the dist file preceding the line containing: '(Only addresses below this line can be automatically removed)' is write protected from changes by multigram (i.e. these addresses can never be automatically/accidentally unsubscribed).

2.5: How do people subscribe/unsubscribe to the list?

By sending a message to the listname-request address with the message 'subscribe' or 'unsubscribe' in the body or the subject of the mail, if the list is open, they will be added to it, if it is a closed list the request will be forwarded to the list maintainer.

2.6: How do I change the admin password for my list?

The password is stored in the rc.custom file.

2.7: How do I enable 'auto help'?

By uncommenting the appropriate "auto_help" line in the rc.custom file the list will respond to every undecipherable request message as if it requested help. Messages that will still get through to the maintainer are those:

• that seem to come from a daemon.
• which look like a reply.

2.8: How can I tell SmartList to notify me when someone subscribes/unsubscribes?

By setting the cc_requests or cc_unsubrequests variables in the rc.custom file to yes (making sure to uncomment it).

2.9: How can I automatically subscribe people who post to the list?

Instead of rejecting submissions by people not on the accept (dist) list, you can enable "force_subscribe". This will cause people submitting mails to the list to be autosubscribed to the list if they were not in the dist file.

2.10: How can I add a short message file to the top or the bottom of all the mailing list messages?

2.11: How can I keep the automatically added messages from multiplying when people quote them all the time?

A small refinement here: if you add something like this:

#
# Appending a disclaimer to every outgoing mail:
#

:0 fbBw
* ! to unsubscribe
| cat - footer.txt

then (assuming that the phrase "to unsubscribe" appears in your footer.txt file), the footer won't be repeated if some bozo list member quotes an entire message without trimming the footer. (Answer submitted by Doug Landauer)

An even cleaner solution, developed by Paul Thomas and Era Eriksson is to pull in content from your actual footer.txt to check and see if that text already exists in the message. This has the advantage of tending to automatically track changes you might make to your footer.txt file...

TEXT=`sed -n '2 p' <footer.txt`
:0 fbBw
* $ ! $\TEXT
| cat - footer.txt

What this does is load the variable TEXT with a line of text from your footer.txt file (the second line, in this example), and use that data for its test. Note that you need two $'s -- one to say "here's the variable I want to interpolate" ($TEXT) and one in front of the condition to say "interpolate variables in this condition". Also note that $\TEXT is a special form of $TEXT where regex specials will be escaped in the interpolated value. So if the second line of the footer says "*** cut here ***" then that is not a valid regular expression, but "\*\*\* cut here \*\*\*" is.

2.12: How can I automatically send files to new subscribers?

You can create a file named "subscribe.files" in the list directory. It can contain any number of archive-server commands. The results (i.e. the files requested) will be sent to the new subscriber.

2.13: Can I add comments to the addresses in the dist file?

2.14: How does someone access the archive server?

2.15: What does "delink" mean?

delink is a shell script in the .bin directory of your SmartList installation which lets you remove the hard link from a file. This is important for list files like rc.init which are by default hard linked across all lists.

Usage: delink filename

A set of files which are hard linked together have the quality that a change made to any of those files will be reflected in all of them. In other words, all files in a hard linked set are always identical. This is because linked files are the same file, simply pointed to from different places on the machine. So, to make changes to only one file of a link set, you must first get that file to not simply be a reference pointer to the other link members, but be a distinct file.

If you want to make one file in a hard linked set different from the others, perhaps to customize one list differently from the others, then you must first remove that file from the hard linked set, using the delink tool or the equivalent.

You can use the showlink tool to get some idea of what a file is hard linked to. Note that the showlink tool is only designed to show hard links within the SmartList file tree.

If you cannot run shell commands against your list control files, you may be able to delink a file by copying the file to be delinked to a new name, then moving that copied file back to the name of the original file you were trying to delink.

Alternatively, you can delink a file by downloading it (scp, sftp or ftp), deleting the file from the server, and re-uploading it.

2.16: How do I add another list of accept addresses?

By default, the accept list (those who can submit to the list even if foreign_submit is off) is linked to the dist list. You may want to add another list of valid submitters, such as to allow both list and digest recipients to post to a list.

Additionally, you may want to add yet another accept list, which could include the list owner, or other valid senders:

1. Unlink rc.submit.
2. Find the line that ends with:

    -x$listaddr -x$listreq accept accept2
   

3. Change it to:

    -x$listaddr -x$listreq accept accept2 accept3
   

(Tip o' the hat to Paul Thomas)

Here is another hint, submitted by Scott Pallack:

I use 3accept instead of accept3. My list has both normal (dist linked to accept) and digest (dist linked to accept2) subscribers and I can put additional addresses, such as the listowner, alternative addresses for list members, etc., into the 3accept and still be able to do things like:

grep -i user@domain.net acc*
cat acc*|grep @|sort|uniq|wc
cat acc*|grep @|sort|uniq -d

etc.

2.17: Hello, Is there a list of x-commands somewhere?

Send the X-Command 'help' to your server. ;)

2.18: How to track bounces from addresses not on list?

Through the magic of email forwarding, it's possible for a list to sustain bounces from addresses that are not directly subscribed. The scenario is that address A, subscribed, is configured to forward to address B. For whatever reason, email to address B starts bouncing, and your list gets 'error delivering email to B' even though address B is not on the list. This situation often leaves no useful clues that an admin might use to remove the actual offending email address (A).

The most reliable way to track this one down is by the use of a "probe." This is a special mailing that goes out to all list recipients such that each email is unique. Smartlist is not capable of generating such emails, so an admin must create such a system using their favorite scripting language. Each email body should contain the subscribed address to which it's being sent (address 'A' in our scenario above).

Note: Probe generators are very simple to write, and tend to be highly customized. If you have trouble with the idea of creating such a thing, contact your local guru, or take the time to learn a smattering of Perl, Python, or a similar scripting language. Remember that the only people who will actually receive your probe are recipients in good standing, so the probe should be worded to strengthen your list community...

The pseudocode would look something like this:

	Open dist list file.
	Loop: for each email on list...
		Create unique email message. (e.g. include current address)
		Inject message into email system.
	... Next in loop.
	Close dist list.

A sample email might look like this -- in this example you would replace all instances of 'A@example.com' with each individual email address on your distribution list, one at a time:

--- cut here ---
To: Hapless List Subscriber <A@example.com>
From: Beleagured Email List <List@my-list-server-domain-example.net>
X-Original-Recipient: A@example.com
Subject: Administratrivia

Greetings.

This email is being sent to you at A@example.com

You are receiving this email because you are subscribed to
Beleagured Email List <List@my-list-server-domain-example.net>

Here is some hopefully useful information about this list, to take
the sting out of receiving what is essentially a piece of junk email...
--- cut here ---

In creating a probe email, samples of the offending bounce email may be helpful to craft the probe such that the tracing information survives the bounce process. In order to keep the signal-to-noise ratio higher, some list admins use a probe to send 'Administratrivia' -- list rules, charter, instructions, web sites, etc.

Sometimes, bounce return messages contain so little information that it is not possible to determine the offending address from a simple probe. In such cases, it may be necessary to send out probes to successively narrower subsets of your distribution list, and use a process of elimination to home in on an offending address. This process generates a lot of noise on a list, and can be quite problematic on large or high volume lists.

3: Remote Administration

3.1: How do I use X-Command for remote administration?

3.2: Can I issue X-Commands from the message body?

3.3: How do I subscribe/unsubscribe people to my list?

3.4: How do I get a list of the subscribers?

3.5: How can I prevent the accidental multiple subscription of an address with x_command?

Modify the x_command script with the following patch:

51,66c51,60
<          $echo $2 | $multigram -c -l32000 dist >/dev/null
<          if test $? -ne 0; then
< 	   $echo "From $2 " >$tmprequest
< 	   $echo "From: request ($listreq)" >>$tmprequest
< 	   $echo "Reply-To: $2" >>$tmprequest
< 	   $echo "To: $listreq" >>$tmprequest
< 	   $echo "Subject: subscribe $2" >>$tmprequest
< 	   $echo "$2" >$tmpfrom
< 	   $test -z "$subscribe_log" ||
< 	    $echo "x_command: subscribe" >>$subscribe_log
< 	    $subscribe <$tmprequest ||
<    	   $echo "X-Diagnostic: Unscreened, not subscribed"
<      else
<        $echo ""
<        $echo "$2 is already subscribed!"
<      fi
---
> 	 $echo "From $2 " >$tmprequest
> 	 $echo "From: request ($listreq)" >>$tmprequest
> 	 $echo "Reply-To: $2" >>$tmprequest
> 	 $echo "To: $listreq" >>$tmprequest
> 	 $echo "Subject: subscribe $2" >>$tmprequest
> 	 $echo "$2" >$tmpfrom
> 	 $test -z "$subscribe_log" ||
> 	  $echo "x_command: subscribe" >>$subscribe_log
> 	 $subscribe <$tmprequest ||
> 	  $echo "X-Diagnostic: Unscreened, not subscribed"

3.6: Is there a web interface for administering SmartList?

3.7: Why isn't SmartList adding/removing names even though it says it is?

4.1: How can I restrict who can subscribe to my list?

4.2: How can I restrict who can post to my list?

4.3: How can I prevent that someone (un)subscribes someone else without their knowledge?

Disable the variable auto_unsubscribe in rc.custom or use the confirm addon.

4.4: Is there a possibility to authenticate postings with SmartList?

No. email is an insecure tool and messages are easy to fake. SmartList cannot make it more secure. Each message could be faked on a list. To make email more secure use PGP or other encryption packages for email usage.

4.5: How can I restrict who can access the archive server?

4.6: Can SmartList confirm (un)subscriptions?

4.7: How can I allow posts only from a certain domain, without using the accept file?

4.8: How to bounce messages with a certain word in the subject?

If the string you're filtering against is "foobar", then put something like this in rc.local.s00

    :0
    * ^Subject:[ ]*.*foobar.*
    | formail -rtk -I "Subject: Posting of follow-up rejected (was: $MATCH)"

4.9: How to automatically notify posters of messages bounced for being too large?

"By default, posts that are too long are forwarded to the list owner, who has to write the person manually to explain what's happened. It would be more convenient if SmartList would send them an automated notice..."

Try this in rc.local.s00:

:0 w
* !< $size_limit
|formail -rk -I "X-Loop: $listreq" -I "From: $listreq" \
 -I "Subject: Sorry, message size for $list is max.: $size_limit bytes!" |\
 $SENDMAIL -t

It should bounce the whole message, mentioning the max. message size in the subject.

Tip 'o the hat to Werner Reisberger for this solution.

4.10: How do I allow digest recipients to post to the regular list?

Create a symlink or hardlink from the digest dist list to become the regular list's accept2 file.

4.11: How to restrict postings from a particular sender?

5.1: How do I turn a non-digest list into a digest?

5.2: How often do digests get sent out?

5.3: Can I force a digest to be sent every day, even if it is small?

5.4: How can I add a message to the beginning of every digest?

5.5: Is there a way to make the digest go out without being an attachment?

(Thanks to Charlie Summers for this one.)

Yes. Change your subscribers' email client, since it's the client that is causing the problem, not SmartList. (Sensible clients should "explode" the multipart/digest issue into separate messages, not treat the entire digest as an attachment.)

If for some reason this isn't an option, then here is a workaround. In .bin/digest change:

Content-Type: multipart/digest; boundary="----------------------------"

... to:

Content-Type: text/plain; charset=US-ASCII

Note that this will REQUIRE you to reject HTML email, since if you accept it in your list the messages in your digest will look like left-over doggie doo with all the HTML tags all over the place...

This will also affect EVERY digest on your server, unless you understand enough shell scripting to add an if/fi conditional to change it only for a specific list. (It's simple enough to do, but shouldn't be attempted unless you have done some shell scripting.)

Later came this follow-up from Charlie, explaining how to make this (or other) change to one list only, without editing the global scripts:

SmartList (possibly by design, but it seems to me more an unintentional although beneficial side effect of the PATH order) will use scripts first in the list directory, then in the ~slist/.bin/ directory. So if one wanted to change the list-d digest to text/plain while leaving the others multipart/digest, one could copy (cp) the .bin/digest shell script into the list-d/ directory, and alter that copy to taste while leaving the .bin/digest shell script alone for use by the other digests on the server. You can use this method to completely change the digest header look on one digest without affecting any other list, too.

I still like the if/fi method myself since it keeps everything together in one shell script for easy reference and debugging, but may find cp'ing the .bin/digest script a _whole_ lot easier.

6: Interaction of SmartList with Message Transfer Agents (MTAs)

6.1: Does SmartList run with Postfix?

6.2: Does SmartList run with qmail?

Yes. If you use the sendmail replacement of qmail you don't need to change anything within SmartList.

For large lists Tracy R Reed <treed@freeside.ultraviolet.org> suggested the following:

To: djb-qmail@koobera.math.uic.edu, SmartList@Informatik.RWTH-Aachen.DE
Subject: smartlist and qmail
Date: Mon, 29 Sep 1997 14:10:42 -0700 (PDT)

I have noticed that using choplist to feed qmail's sendmail clone (because choplist expects sendmail) to distribute mail to my large mailing list was incurring massive amounts of overhead and really slowing things down. If I could just get smartlist to call qmail-inject directly, it would greatly speed things up. To this end, I modified my rc.init file:

alt_sendmail="smart-qmail dist $listreq"

And put this perl script in ~list/.bin/smart-qmail

#!/usr/bin/perl
$from = $ARGV[1];
$addyfile = $ARGV[0];
while() {
  $message .= $_;
  }

open(BLAH,"<$addyfile") || die "Doh!  No address file!\n";
$x = 0;
while () {
  if(/Only addresses below this line can be automatically removed/) {
    next;
    }
  chop;
  $addy .= " ". $_;
  $x++;

  # 30 is kinda arbitrary, I just don't want to run into any ugly command
  # line length limits.

  if ($x == 30) {
    open(INJECT,"|/var/qmail/bin/qmail-inject -f$from $addy");
    print INJECT $message;
    close INJECT;
    $x = 0;
    $addy = "";
    }
  }
open(INJECT,"|/var/qmail/bin/qmail-inject -f$from $addy");
print INJECT $message;
close INJECT;

Another note -- Paul Thomas points out that

"Qmail bounces email differently than sendmail. It does a 'local' bounce and a 'remote' bounce. SmartList will process to the best of it's ability a 'remote' bounce, but 'local' bounces are written to a qmail "Mailbox' file and overlooked by SmartList. In short, qmail will work with SmartList but to make everything work right one is looking at a major hack of SmartList."

6.3: Sendmail can't run flist. Why? (smrsh)

If you log an error message something like

554 "|exec /path/to/flist listname"... Service unavailable

the reason is most probably that sendmail is using the smrsh "Sendmail Restricted SHell" environment for shell calls.

The way a message initially gets to the SmartList system is through a sendmail alias that pipes the email to the program. The alias probably looks something like:

listname: "|exec /path/to/flist listname"

However, some configurations of sendmail attempt to increase security by restricting allowable programs to those in a certain directory. In this case, you need to create a symlink to the flist binary in the smrsh directory.

Try these steps:

1. Find the correct location of your smrsh directory. You may have to examine your smrsh source, or use the strings command to examine your smrsh binary.

2. Create a symlink to your flist binary in the smrsh directory:

   ln -s /path/to/flist /location/of/smrsh/flist

3. Change the alias for the list to simply be

   listname: "|flist listname"

   You don't need the path to flist now, since sendmail is only going to look in one place (your smrsh directory). You don't need the exec either.

Don't forget to run newaliases after you modify your aliases file to effect your changes.

6.4: How do I get SmartList to work with different virtual accounts?

I installed SmartList on the different virtual accounts and have a link in "/etc/smrsh" to the "flist" program in the ".bin" directory of each account... It works but only the one linked to "flist"... In order to be able to have links to all the "flist" programs of all the accounts in "/etc/smrsh", I used different links with different names but they just DON'T work... it seems to me like Procmail wants the link in "/etc/smrsh" to be named "flist" ONLY, in order to work...

All the names need to begin with "flist". You could use names like

flist.domain1
flist.domain2
... (Thanks to Philip Guenther for this one.)

7: Addons and enhancements for SmartList

7.1: Is it possible to have more than one list maintainer?

Yes apply the following patch (from Alan Stebbens) to your rc.request file (don't forget to remove the hard link before). After applying the patch you can use several maintainer addresses in rc.custom separated by a comma (don't include blanks between the addresses).

--- installed/rc.request        Thu Oct 31 00:02:23 1996
+++ rc.request  Fri Oct 18 09:11:58 1996
@@ -291,20 +264,20 @@
#

# is there more than one maintainer?
-maintainer_re=$maintainer
-maintainers=$maintainer
+maintainer_re="$maintainer"
+maintainers="$maintainer"
Maintainer=Maintainer

:0
* maintainer ?? ,
-{ maintainer_re=`echo "$maintainer" | sed -e 's/,/|/g' -e 's/\./\\\./g'`
-  maintainers=`echo "$maintainer" | sed -e 's/,/ /g'`
+{ maintainer_re="`echo $maintainer | sed -e 's/,/|/g' -e 's/\./\\\./g'`"
+  maintainers="`echo $maintainer | sed -e 's/,/ /g'`"
Maintainer=Maintainers
}

:0 wf:dist.lock
-* $^$X_COMMAND:.*$maintainer_re[        ]+$X_COMMAND_PASSWORD

If you have access to your aliases file, another approach is to set the maintainer in rc.request to a "role address" defined in the aliases file to expand to all maintainers, for example "mylist-owner". Maintainers would then use the "mylist-owner" address to issue list commands, and any email generated for the maintainer will be delivered to all maintainers defined in the aliases file.

7.2: Can I remotely update files used by SmartList like help.txt?

7.3: How can a subscriber temporarily suspend subscription?

7.4: Where can I find more SmartList information and utilities?

SmartList Utilities and Patches - send email to alan.stebbens@software.com with the subject

"send smartlist library".

7.5: Can SmartList send individualized messages to each list recipient?

No. SmartList is designed to take advantage of the bulk processing capabilities of the MTA. It is not designed for personalized mailings.

It is certainly possible to use the dist list to generate personalized mailings using another program. This can be very useful to track certain types of bounces.

8: Miscellaneous

8.1: How can I make my list moderated?

8.2: How can I change the messages that SmartList sends to people?

8.3: How can I add "[listname]" to all of the mailing list messages for easy filtering?

8.4: How can I add a custom header to all of the mailing list messages?

Uncomment the line "RC_LOCAL_SUBMIT_20 = rc.local.s20" from your rc.custom file, and add the following to your rc.local.s20 file:

#
# Adding some custom headers (although it will work, this is not
# needed for Reply-To related headers, see the reply_to variable in
# rc.custom):
#

:0 fhw
| formail -i "X-Subliminal-Message: SmartList is great" \
-I "X-Mailer: procmail, which is great too :-)"

8.5: How can I remove some headers from all of the mailing list messages?

Uncomment the line "RC_LOCAL_SUBMIT_20 = rc.local.s20" from your rc.custom file, and add the following to your rc.local.s20 file if you want :

#
# To get rid of some headers:
#

:0 fhw
| formail -I X-Mailing-List: -I X-Mailer:


#
# To get rid of all X- fields:
#

:0 fhw
| formail -I X-

8.6: Is there an easy way to remove duplicates from the dist file?

This script was contributed to the SmartList mailing list by Mark David McCreary, you can run this from your list directory (where the dist file is located), and it will remove the duplicates and sort the entries that appear below the "(Only addresses below this line can be automatically removed)" line.

#! /bin/sh
:
#
#   rc.dedup.list
#
#   mdm 11/5/97   borrow code from  David W. Tamkin, with additional
#                 suggestions from Martin Konold and Hal Wine
#
#
#  This script will sort and remove duplicates from a Smartlist
#  distribution file.  Smartlist dist files contain a comment line
#  that looks like this
#
#      (Only addresses below this line can be automatically removed)
#
#  Addresses above and including this line will not be sorted.
#

lockfile=lockfile   # /usr/bin/lockfile
cat=cat             # /bin/cat
rm=rm               # /bin/rm
sed=sed             # /bin/sed

#  create lock file to discourage SmartList running a job

$lockfile -10 -l3600 -r11 -s30 rc.lock

$sed -e "1,/(Only addresses below this line can be automatically removed)/{
;w slabove.$$
;d;
}
" dist | sort -fu -o slbelow.$$

$cat sl?????.$$ > dist
$rm -f sl?????.$$

$rm -rf rc.lock

8.7: How can I keep people from sending HTML/attachments/other junk to the list?

8.8: How do I make replies go to the list instead of to the sender?

The "Reply-To:" header element is designed to allow you to do this, and the reply_to variable within your rc.custom file gives you the ability to control this header element in list processed email.

There are several approaches. Arguably the simplest is, in the rc.custom file, uncomment the line:

reply_to = $listaddr

and set it to something like this:

reply_to = "Reply-To: $listaddr"

Paul Thomas notes that:

"The 'Reply-To: ' rule in rc.custom is overwritten if a post to the list already contains a 'Reply-To: ' with a different address. Putting something like:

        :0 fhw
        | formail -I "Reply-To: test@somedomain.com"

in rc.local.s20 might be better."

8.9: How can I make replies go to the original sender?

If you run "announcement" style lists, where you want to discourage list discussion by having replies go to the original author, then in the rc.custom file, uncomment the line:

reply_to = $listaddr

and set it to something like this:

reply_to = "Reply-To: `formail -xFrom:`"

Note that the formail -xFrom: command is enclosed in backticks (`), which cause procmail to run the formail command in a subshell and return that command's results.

8.10: Why doesn't putting "Reply-To: $listaddr" in my rc.custom file work for all subscribers?

8.11: How can I include the number of subscribers in the footer I'm attaching to each list mail?

8.12: How to send an auto-reply back when someone posts?

Courtesy of Ravi Pina:

Placing this in rc.local.s20 and uncommenting the appropriate line in the rc.custom file will provide this functionality.

# recipe to send an autoreply
 
REPLY_TEXT=/path/to/autoreply.txt
REPLY_SUBJECT="Message Received"

:0 whc
| formail -rtzc -xTo: >tmp.from

:0 ch :autoreply.lock
| (formail -rtzc -I "Subject: $REPLY_SUBJECT" \
-A"Precedence: junk" ; cat $REPLY_TEXT) | \
$SENDMAIL -t `cat tmp.from`

Ravi couldn't stop thinking about this one, so he then sent this:

"I've made the auto-reply a bit more robust and bloated :)

Place the following in rc.local.s20 and uncomment the corresponding line in your unlinked rc.custom. REPLY_TEMP is a text file that gets mailed back to the original sender. It will be sent as MAIL_FROM. If you want to put a user name in the header From: line, do so in HDR_FROM. The subject will be set to REPLY_SUBJECT.

If you want to use the original subject in your reply, place `$SUBJECT' where you want it to appear in the REPLY_TEMP file and set MUNGE_BODY appropriately."

#MUNGE_BODY=no
REPLY_TEMP=/path/to/autoreply.txt
MAIL_FROM="moo@cow.org"
HDR_FROM="moo@cow.org (moo!)"
REPLY_SUBJECT="Message Received"
ORIG_SUB=`formail -zx Subject:`

:0 whc
| formail -rtzc -xTo: >tmp.from ; \
cp $REPLY_TEMP tmp.autoreply

:0 whc
* MUNGE_BODY ?? y
| sed 's/\$SUBJECT/'"$ORIG_SUB"/g $REPLY_TEMP > tmp.autoreply

:0 ch :autoreply.lock
| (formail -rtzc -I "Subject: $REPLY_SUBJECT" -I "From: $HDR_FROM" \ 
-A"Precedence: junk" ; cat tmp.autoreply) | \
$SENDMAIL -t -f $MAIL_FROM `cat tmp.from`

8.13: Why are MIME and HTML emails a problem for SmartList?