Gecko [ nbspublicschool.com ]

Name	Size	Permission
examples	[ DIR ]	drwxr-xr-x
Artistic	5.97 KB	-rw-r--r--
COPYING	17.57 KB	-rw-r--r--
FAQ	13.45 KB	-rw-r--r--
FEATURES	4.1 KB	-rw-r--r--
HISTORY	30.4 KB	-rw-r--r--
KNOWN_BUGS	2.23 KB	-rw-r--r--
QuickStart	3.29 KB	-rw-r--r--
README	7.71 KB	-rw-r--r--
README.Maildir	388 B	-rw-r--r--
telsas_procmailrc	17.99 KB	-rw-rw-r--

Code Editor : FAQ

------------------------------------------------------------------------------
---------------------- Frequently Asked Questions ----------------------------
------------------------------------------------------------------------------

1. How do I go about setting up a mailinglist or a mail-archive server?

Look in the SmartList directory, start reading the INTRO file,
	it describes it in detail and should get you started.

2. I installed procmail (i.e. typed 'make install'), but how am I supposed to
   use it?  When I type procmail on the command line it simply does nothing.

***********************************************************************
	There exists an excellent newbie FAQ about mailfilters (and procmail
	in particular), it is being maintained by Nancy McGough <nancym@ii.com>
	and can be obtained via:

World Wide Web (the nicest format for online reading!):
	http://www.faqs.org/faqs/mail/filtering-faq/

Anonymous FTP:
	ftp://rtfm.mit.edu/pub/usenet/news.answers/mail/filtering-faq

E-mail:
	Send mail to mail-server@rtfm.mit.edu containing the following:
	    send usenet/news.answers/mail/filtering-faq

UUCP:
	uunet!/archive/usenet/news.answers/mail/filtering-faq

It is also posted monthly in at least the following newsgroups:
		comp.mail.misc, comp.answers, news.answers
	***********************************************************************

You're not supposed to start procmail from the command line.
	Procmail expects exactly one mail message to be presented to it
	on its stdin.  Usually the mail system feeds it into procmail.
	If you start it by hand, you have to type the mail.

Be sure to have a .forward and a .procmailrc file in your home
	directory (see the examples subdirectory or the man page).
	MMDF users should note that they need a .maildelivery file *instead*
	of a .forward file (see the man page for more detailed information).

If however, procmail has been integrated in the maildelivery system
	(i.e. if your system administrator installed it that way, ask him/her),
	then you no longer need the .forward files in your home directory,
	having a .procmailrc file will suffice.

On some systems .forward files are not checked.
	It might be possible that your system supports a command like:
		mail -F "|/usr/bin/procmail"
	to set up forwarding to a program.  (If procmail is in /usr/local/bin
	then use that path instead when trying these.)
	If that doesn't seem to work it might be worth trying to put a line
	looking like this:
		Forward to |/usr/bin/procmail
	or if that doesn't work, try:
		Pipe to /usr/bin/procmail
	as the only line in your mail spool file (e.g. /var/mail/$LOGNAME), as
	well as doing a "chmod 06660 /var/mail/$LOGNAME".  For more information
	on such systems, do a "man mail".

If all of this doesn't work, procmail can be called on a periodical
	basis, either via "cron", "at" or whenever you start reading mail (or
	log in).  For a sample script look in the NOTES section of the
	procmail(1) man page.

3. When I compile everything the compiler complains about invalid or illegal
   pointer combinations, but it produces the executables anyway.
   Should I be concerned?

Ignore these warnings, they simply indicate that either your compiler
	or your system include files are not ANSI/POSIX compliant.
	The compiler will produce correct code regardless of these warnings.

4. The compiler seems to issue warnings about "loop not entered at top",
   is that a problem?

No, no problem at all, it just means I wrote the code :-).
	That's just about the only uncommon coding technique I use (don't
	think I don't try to avoid those jumps in loops, it's just that
	sometimes they are the best way to code it).  This warning, as
	well as "statement not reached", can be ignored -- the compiler
	will still generate correct code.  Use gcc if they really bother
	you.

5. The compiler complains about unmodifiable lvalues or assignments to const
   variables.  Now what?

Well, if the compiler produces the executables anyway everything
	probably is all right.	If it doesn't, you might try inserting a
	"#define const" in the autoconf.h file by hand.	 However in any case,
	your compiler is broken; I would recommend submitting this as a
	compiler bug to your vendor.  In any case, if this should occur, I'd
	appreciate a mail from you (so I can try to fix the autoconf script
	to recognise your compiler correctly as well).

6. The compiler refuses to compile regexp.c, what is the problem?

Try compiling that module with optimisation turned off.

7. Everything installed just fine, it's just that there are several stale
   _locktst processes which refuse to die.  How do I get rid of those?

In order to prevent things like this from happening to procmail,
	_locktst tries to determine which kernel locking methods are
	reliable.  Sometimes this triggers a bug in the kernel or in
	your system-supplied lockd; this is good, because _locktst detects
	this and makes sure that procmail will not make the same mistake.
	A side effect is that this sometimes leaves behind some stale
	_locktst processes that seem to be unkillable.

This usually is the result of a buggy lockdaemon.  In order to
	get rid of the stale processes, ask your system administrator
	to kill and restart the (rpc.)lockd (and perhaps the (rpc.)statd)
	on both the filesystem-client (where you compiled procmail) and the
	filesystem-server(s) (where the lockingtests took place).
	Depending on the OS it might help if you send the offending
	_locktst processes a kill signal before or after restarting the
	lockd again.

In any case, _locktst just uncovered a bug in your operating system.
	You should contact your system's vendor and ask for a bugfix for
	your lockd.

8. When I send myself a testmail, the mail bounces with the message: cannot
   execute binary file.	 What am I doing wrong?

It is very well possible that mail is processed on a different
	machine from that where you usually read your mail.  Therefore you
	have to make sure that procmail has the right binary format to
	execute on those machines on which mail could arrive.  In order to
	get this right you might need to do some .forward file tweaking,
	look at the examples/advanced file for some suggestions.

9. Where do I look for examples about:
	One home directory, several machine architectures?
	Procmail as an integrated local mail delivery agent? (generic,
	 sendmail, ZMailer, smail, SysV mailsurr)
	Changing the mail spool directory to $HOME for all users
	Security considerations (when installing procmail suid root)

Well, this probably is your lucky day :-), all these topics are covered
	in the examples/advanced file.

Other examples (e.g. for autoreplies) are most likely to be found by
	typing:		man procmailex

10. How do I use procmail as a general mail filter inside sendmail?

See EXAMPLES section of the procmail(1) man page.

11. Why do I have to insert my login name after the '#' in the .forward or
   .maildelivery file?

Some mailers `optimise' maildelivery and take out duplicates from
	Cc:, Bcc: and alias lists before delivery.  If two or more persons on
	such a list would have identical .forward files, then the mailer will
	eliminate all but one.	Adding a `#' with your login name following
	it will make the .forward files unique, and will ensure that the mailer
	doesn't optimise away some addresses.

12. How do I view the man pages?

If the man(1) program on your system understands the MANPATH
	environment variable, make sure that the installation directory listed
	in the Makefile for the manpages is included in your MANPATH.  If your
	man program does not support MANPATH, make sure that the man pages
	are installed in one of the standard man directories, like under
	/usr/man.  If you do not want to install the man pages before viewing
	them, you can view an individual man file by typing something like:
	nroff -man procmail.1 | more

13. The leading From_ line on all my arriving mail shows the wrong time.
    Before putting procmail in the .forward file everything was OK.

This is a known bug in sendmail-5.65c+IDA.  The real fix would be
	to upgrade to sendmail 6.x or later.  For a quick fix, see the
	procmailex man page.

14. When sending mail to someone with procmail in his/her .forward I sometimes
    get back an error saying: "Cannot mail directly to programs."

This is a known bug in some older sendmails that mistakenly drop
	their root privileges when they are given the -t flag.	Either
	make sure that your sendmail always forwards to a mailserver first or
	upgrade to sendmail 6.x or later.

15. When sending mail to someone with procmail in his/her .forward I sometimes
    get back an error saying:
    "User doesn't have a valid shell for mailing to programs."

This indicates that the mail arrives on a mailserver which most likely
	has a different user database (/etc/passwd) where the login shell
	specified for the recipient is not present in /etc/shells.
	Contact your administrator to put the name of that shell in
	/etc/shells.

16. My mailtool sometimes reports that it is confused about the state of
    the mailbox, or I get "Couldn't unlock" errors from procmail now and then,
    or sometimes it simply seems to hang just when new mail arrives.

This is a known bug in the OpenLook mailtool.  It holds on to
	the kernel lock on the mail-spoolfile most of the time as a
	signal to other mailtool processes.  With newer versions of
	mailtool, enabling the "Use network aware mail file locking"
	configuration option may solve the problem, though this option
	isn't always available.	 If that doesn't work then recompile
	procmail with both the fcntl() and lockf() locking method
	disabled (see config.h).

17. I sometimes get these `Lock failure on "/var/mail/$LOGNAME.lock"' errors
    from procmail.  What do I do about it?

The problem here is that as long as procmail has not read a
	$HOME/.procmailrc file, it can hang on to the sgid mail permission
	(which it needs in order to create a lockfile in /var/mail).
	I.e. if procmail delivers mail to a user without a $HOME/.procmailrc
	file, procmail *can* (and does) use the /var/mail/$LOGNAME.lock file.

If, however, it finds a $HOME/.procmailrc file, procmail has to let go
	of the sgid mail permission because otherwise any ordinary user could
	abuse that.

There are several solutions to this problem:
	- Some systems support the sticky bit on directories (when set only
	  allows the owner of a file in that directory to rename or remove
	  it).	This enables you to make /var/mail drwxrwxrwt.  It is
	  thus effectively world writable, but all the mailboxes in it are
	  protected because only the mailbox owner can remove or rename it.
	- If your system did not exhibit the !@#$%^&* POSIX semantics for
	  setgid(), procmail would have been able to switch back and forth
	  between group mail and the group the recipient belongs to without
	  creating security holes.
	- If your system supported setrgid() or setregid() or setresgid()
	  with BSD semantics, procmail would have been able to switch...
	  (see the previous point).
	- You could simply put the following at the end of your .procmailrc
	  file:

LOCKFILE		# removes any preexisting lockfile
		LOG=`lockfile $DEFAULT$LOCKEXT`
		TRAP="rm -f $DEFAULT$LOCKEXT"
			:0
			$DEFAULT

- You could, instead of using /var/mail/$LOGNAME, use a file below
	  your home directory as your default mailbox.
	- Or, you could still use /var/mail/$LOGNAME as the mailbox, but
	  simply instruct procmail to use a different lockfile.	 This can
	  be achieved by putting following recipe at the bottom of
	  your .procmailrc file:

:0:$HOME/.lockmail
		$DEFAULT

You have to make sure that all other programs that update your
	  system mailbox will be using the same lockfile of course.
	- You can ignore the problem if you know that both your mail reader
	  and procmail use an overlapping kernel locking method.

18. Is procmail Y2K safe/compliant?

Both procmail and formail are believed to be Y2K compliant if
	your system's libraries are Y2K compliant.  In particular, they
	use the time_t type to hold the current time when it is needed
	and print out the time using the ctime() library routine.
	However, no actual compliancy tests have been run, so you if
	you need that you'll need to run them yourself.

For those who have examined the code themselves, the casting of
	a time_t value to unsigned long in formail.c is guaranteed to
	work according to the current version of the C language
	standard.  Future revisions of that standard may change that,
	at which time formail will be updated to work with both the new
	and the old standards.

Individual recipes and rcfiles may need to be checked for
	unsafe date handling.

19. How can I make procmail deliver a message to all local users?  E-mail
    for several people all come into a single mailbox and I'm trying to
    split them back up.

If you are asking this, you are on the wrong track.  Procmail
	cannot route messages like this correctly without special help
	from the MTA (sendmail, qmail, etc).  For a more lengthy
	discussion about the issues, please refer to
	http://www.iki.fi/era/procmail/mini-faq.html#advanced

20. None of the above topics cover my problem.	Should I panic?

Let me ask you a question :-), have you examined the CAVEATS,
	WARNINGS, BUGS and NOTES sections of the manual pages *closely* ?
	Have you checked any of the FAQs referenced from the procmail
	website, http://www.procmail.org, to see if the answer it?  If
	you have, well, then panic.  Or, alternatively, you could
	submit your question to the procmail mailinglist (see the man
	page for the exact addresses, or try "procmail -v", or look in
	the patchlevel.h file).

${this.title}

Code Editor : FAQ