This page discusses sendmail-8.12 installation

Actual version you can find at
The original, old and NOT recommended version is here
Last update: 21. 9. 2001
Similar page you can find at
However, there are PERFECT (although unofficial) pages at


General information
General considerations
Installation of tcp-wrappers, libdb, procmail, sendmail
Changing default mailer flags
MIME and sendmail
Sendmail and DNS records, in respect to antiSPAM - campus wide solution
Note on Berkeley DB makemap usage
Saving the informatin from envelope

General information:

At least on machines from Digital/SGI/Sun to which I have access to there were pretty old versions of sendmail. Although COMPAQ/Digital offers sendmail-8.8.8 in it's Digital Unix 4.0E, you get precompiled binary most probably without tcp-wrapper support. Because I think one can't live without tcp-wrappers on UNIX system, I'd recommend you to compile sendmail yourself.

A lot of very usefull information you can get directly from

Advanced users can visit, but it's not necessary.

Before compiling sendmail, install db-2.7.X from into /usr/local/ directory (that's ./configure --prefix=/usr/local ). However, it seems to install into /usr/local/BerkeleyDB/, so move files to /usr/local from that dir or whatever.

Compile sendmail with -DTCPWRAPPERS compileflag, and with LIBS = /usr/local/lib/libdb.a /usr/local/lib/libwrap.a. This will link both libraries statically into the resulting binary. After creating sendmail's binary you have to generate the file, which is the most difficult task.

I'm using procmail as a local delivery agent because it's very flexible, it gives you ability to filter-out e-mails, sort them, even tweak broken MIME headers, remove some viruses, automagically remove those ugly attachments like WINMAIL.DAT, MS-TNETF and lots of others.

Some URL's related to procmail:

Perfect resources about whole InterNet informations are at

General considerations:

It's a good idea whatever you ever compile yourself to place into /usr/local. To /usr write system installation tools and sometimes they overwrite you binaries, libraries, headers, or you overwrite them. For example: current versions of bind-8.x install themselves into /usr and I twice eneded up with overwrittes header files in /usr/include. This is a well know case that people on Digital Unix ended up with prot.h in /usr/include , which totally breaks some configure scripts of freeware software.
Whenever I installed sendmail into /usr/sbin and went to install vendor patches to Digital Unix server, it complained that binaries are different then original from Digital and it refuses to install affected patch. If I just ignored this and went over, I overwrote my binaries of sendmail and could recompile/reinstall them again. So, SAVE YOUR TIME, place everything into /usr/local and just modify /etc/rc* scripts to start programs from new locations. When you will upgrade your OS, you will appreciate that all new stuff is in /usr/local.

You can find some more info in one SUMMARY message.


-install tcp-wrappers, get them from
- be sure to install NOT only binaries, but also the library and header file! Install binaries into /usr/etc/ or /usr/sbin/ directories

tcp-wrappers$ cp ./tcpd ./tcpdmatch ./tcpdchk ./try-from ./safe-finger /usr/sbin
tcp-wrappers$ cp tcpd.h /usr/local/include
tcp-wrappers$ cp libwrap.a /usr/local/lib

-procmail, get it from

gzip -dc procmail-3.14.1.tar.gz |tar xvf -
cd procmail-3.14.1
make install-suid

-new Berkeley DB (1.85 or better never releases from 2.x series or 3.x series), get it from

gzip -dc db-2.7.7.tar.gz |tar xvf -
cd db-2.7.7/build_unix
../dist/configure --prefix=/usr/local
make install

-sendmail, get it from or my precompiled distribution:

--install GNU m4 utility, you will need it for creating the config file


Our configuration files are here. I saved the directory structure, so place them to corresponding directories after untarring sendmail-8.10.0 distribution, and follow the shell script below.

#! /bin/sh
echo "This will read general settings for all UNIXes in our domain from devtools \
./Build -Q
echo "I install binaries by hand, otherwise ./Build install works but doesn't use \*/ , but compiles sendmail again!"
echo "Check that your sednmail binary has statically compiled in libdb-3.3.11"
echo "The same should be for utilities directories: makemap mailstats smrsh editmap praliases vacation"
cd obj*/sendmail; make install
cd ../makemap; make install
cd ../mailstats; make install
cd ../smrsh; make install
cd ../editmap; make install
cd ../praliases; make install
cd ../vacation/; make install
echo " you can create this way"
echo "cd cf/cf; make install-cf"
echo "don't forget to:"
echo "mv /etc/ /etc/mail/local-host-names"
echo "makemap hash /etc/mail/access < /etc/mail/access"
echo "sendmail -bi -v"
echo "mkdir /var/spool/mqueue/.hoststat"
echo "cp*/sendmail/helpfile /etc/mail/helpfile"

libdb is needed for sendmail, editmap, praliases (I had to use -lpthread because libdb.a needs it) I did not need lbind lresolv lwarap for any utilities

MAILER flags
I was looking for ways to "enhance" the default setup of sendmail, but I more or less failed to improve it. ;) I wanted to customize the flags used for Local Delivery Agent (LDA is the P= operand of the 'Mlocal' definition). This the line in beginning with Mlocal, which is being generated by the MAILER definition while generating config file by m4 utility. So the M really means MAILER, thus you have Mrelay, Msmtp, Msmtp8, Mesmtp etc. Sendmail is using these mailers for passing messages to some agents, either when relaying or just sendmail messages off the server, or if your server is the final destination, it's using the Mlocal to read what's the LDA which is allowed do write down the message to you mailbox. The following flags can be found in excellent documentation file sendmail-8.10.0/doc/op/ . I thought also about the m flag, which tell sendmail that the MAILER, so so any (i.e. smtp, smtp8, esmtp, relay, local) is capable of properly sending one message at once to multiple recipients. You can imagine you send an e-mail to 10 people at, so if sendmail at your SMTP server has the m flag on relay or smtp, smtp8, esmtp mailers (deepends what is the case), it will contact and send one message via the network, and tell to hotmail server to send it to 10 recipients locally. This is perfectly correct and the m flag should be set for these mailers already by default.

But in case of local mailer (LDA), you shouldn't turn the m on in case of procmail and other mailers which can't send back to sendmail error codes for recipient user. The reason is, that if one of those local deliveries failed (and even other 9 deliveries succeeded), the message delivery as a whole is aborted, and later re-tried again. So those 9 recipients receive the message twice or even more times. So, the m flags if for procmail as an LDA turned off, we deliver messages locally in 10 separate actions (doesn't necessarily mean 10 processes [see SingleThreadDelivery option]), so users don't receive duplicate messages. This is because procmail is not SMTP capable and not yet LMTP capable. On the other hand, mail.local from sendmail is OK and CAN be used with m flag as an LDA. BTW: Also, users may receive duplicate messages because of the virtual domain setup, this is a real problem which isn't solvable now perfectly [see notes by Philip Guenther around the LMTP topic and the original message thread in procmail-list archive].

Date: Thu, 06 Apr 2000 08:25:50 -0500
From: Neil W Rickert 
Subject: Re: doc/op/ 

Martin Mokrejs  wrote:
>On Wed, 5 Apr 2000, Neil W Rickert wrote:
>> Martin Mokrejs  wrote:

>> For the local mailer, it is a different question.  Omitting the
>> 'm' has some advantages if you are not using LMTP.  With the 'm'
>> flag you sometimes get duplicate mail.

>Hmm, more details/examples available, please?

The local mailer is the only commonly used non-SMTP mailer which
could fail for some recipients but succeed for others.  By
comparison, an error from a UUCP mailer would normally be for all
recipients of that message with uucp addresses in the same

But the local mailer can fail for an individual recipient.  The
recipient might have messed up mailbox permissions.  Or he/she might
be over disk quota.  The interface with non-smtp (non-lmtp) mailers
does not allow individual identification of which recipient address
caused the error.  If there is a temporary error for one recipient
(over quota, for example), sendmail treats it as a temporary error
for all local recipients from this transaction, and retries to all
addresses.  If there is a permanent error, the error message suggests
that mail to all recipients failed.  If the 'm' flag is not used,
there is only one recipient for the transaction and the problem does
not arise.  Or, if an LMTP local delivery agent is used, then
individual response codes are given and the problem does not arise.

>I call procmail in the Mlocal part ( MAILER(`procmail') I guess )and also
>Mprocmail (this is the result of FEATURE(`local_procmail') I guess.

Actually, you have that backwards.  FEATURE(`local_procmail') makes
the Mlocal line reference procmail.  MAILER(`procmail') provides a
separate procmail mailer.

>They have different flags, so under which circumstances is called each?

Whe `local_procmail' is used, the flags/options are set so that the
default will be for procmail to deliver to the user mailbox, unless the
user has provided his own recipes.

The separate `procmail' mailer is intended for special cases, such as
where virtual hosting is dumping mail for a virtual domain into
special directories.  So procmail is given options to use a global
configuration file.  The 'procmail' man pages will give more details
on the differences.

>One of them I think is supposed to help save the part of username after
>the plus/minus sign, i.e. sendmail+questions@... and pass it to LDA (is it
>the same as Mlocal?) as $1. So one can get some part of the envelope
>Mail To: address.

Some people with dialup connections want all mail for their domain
saved in a single mailbox, which they can later break up after
fetching the mailbox contents with POP3 client.

>Does sendmail-8.10 by default save the envelope information to headers?
>I hope it already does but haven't seen it yet written somewhere. ;)

No.  In limited circumstances, it places the envelope recipient in
the "Received:" header.  But this only happens when there is only
one recipient in the envelope.  Otherwise to do so would compromise
the privacy intended by "Bcc:".

>When you reply to me and send a Cc: back to sendmail+questions@, do you
>expect me to reply only personally to you or again to both addresses?

The "Cc:" to sendmail-questions, is so that others in our group can
look over my shoulders, and correct any mistakes or misdirections.
It also lets them know that the message is answered, so that they
need not respond.

When you in turn reply, we again want everybody to see the reply.
But we actually don't take chances on this.  My "personal address" of
 is actually just an alias to the same
distribution list.  So actually, it doesn't matter.  I normally add a
"Reply-To:" header to my replies, so that you will know that we want
responses coming back to the general list.  But they come back to the
list anyway, even if you think you are replying personally.

Date: Fri, 07 Apr 2000 00:43:07 -0500
From: Philip Guenther 
To: Martin Mokrejs 
Subject: Re: CC and TO: 

Martin Mokrejs  writes:
>On Thu, 6 Apr 2000, Philip Guenther wrote:
>Philip, I really thought I understand it - finally. Not yet. ;)
>> Putting the 'm' flag on the local mailer WILL NOT HELP AT ALL.  Neil
>> Rickert said as much in the email you quoted and I can guarantee it.
>> Depending on how the virtual domain is implemented, putting the 'm'
>> flag on the procmail mailer may be *a _small_ part* of a solution.
>> By itself, it will merely *BREAK* any current use of the procmail mailer.
>NR> You should turn it on where that makes sense.  Certainly, turn it on
>NR> for the SMTP mailers.
>NR> For example, suppose you send a message to
>NR> '' with a Cc: to
>NR> ''.  If you have the 'm' flag set,
>NR> then your system will send it once, with both addresses.  Then the
>NR> duplicate address suppression at will ensure that I am
>NR> only sent one copy of your message.
>So the speach here is about FEATURE(`mailer', `relay') ?

Yes.  A mailer should only have the 'm' flag if it can not only accept
multiple addresses but also return an appropriate status code for each.
That includes SMTP and LMTP mailers and mailers like UUCP ones that
return a single status applicable to all submitted addresses.

If you write the invoked procmail rcfiles *very* carefully, you can
arrange for the 'm' flag to work with the procmail mailer.  However,
doing so is difficult enough that I can't recommend it for general use.

>So I'm lost. If procmail is installed as LDA, is SMTP capable (but
>probably doesn't matter now), we speak about Mlocal
>(i.e. FEAURE(`local_procmail') and thus this part applies?:

Procmail is not SMTP capable.  I have an alpha version which does LMTP,
but procmail has never, and will never, do SMTP.

>NR> The local mailer is the only commonly used non-SMTP mailer which
>NR> could fail for some recipients but succeed for others.  By
>NR> comparison, an error from a UUCP mailer would normally be for all
>NR> recipients of that message with uucp addresses in the same
>NR> transaction.
>NR> But the local mailer can fail for an individual recipient.  The
>NR> recipient might have messed up mailbox permissions.  Or he/she might
>NR> be over disk quota.  The interface with non-smtp (non-lmtp) mailers
>But procmail is SMTP capable ...

>From this error stems your confusion.  Whoever told you that procmail
can do SMTP was confused.

Note that having an LMTP capable version of procmail doesn't solve the
original problem (duplicate messages sent for multiple users of virtual
domain).  This is a problem in the scripts and/or rcfiles that handle
the virtual domain and the 'm' flag will not magically solve it.

Philip Guenther

PS: don't ask when procmail + LMTP will be availible.  I have no idea.

here's an incomplete summary of mailer flags from sendmail-x.x.x/doc/op/, page 43:

A	Lookup the user part of address in the alias database. Normally this is
	only set for local mailers.
D +     sendmail will pass the Date: header to LDA,
	because LDA needs it
f	the mailers wants a -f fromwhom flag, but only if this is a network
	operation (i.e. the mailer will give an error if the executing user does
	not have special permissions).
F +     pass the From: in header
g	Normally, sendmail sends internally generated email (e.g. error
	generated messages) using the null return addrs. as required by RFC1123.
	However, some mailers don't accept a null return address. If necessary,
	you can set the g flag to prevent sendmail from obeying the standards;
	error messages will be sent as from the MAILER-DAEMON (actually, the
	value of $n macro).
l	this is the local mailer (final delivery will be performed)
M +     Need Message-ID: in header
h       Preserve uppercase in hostname - we should.
	 You are interpreting "hostname" too literally.  It can refer to
	 whatever comes after the $@ in the mailer selection triple.  In
	 particular, it can be a uucp nodename (which is case sensitive), or
	 for a procmail mailer it could be a local system directory (also case
	 sensitive). -- Neil W Rickert 
m	mailer accepts multiple recipients in one message and properly returns
	error codes if passing of the message to any of these recipients failed,
	so that we know which recipient delivery failed. This mailer can send to
	multiple users on the same host in one transaction. When a $u macro
	occurs in the argv part of the mailer definition, that field will
	be repeated as necessary for all qualifying users. Removing this flag
	can defeat duplicate supression on a remote site as each recipient
	is sent in a separate transaction.
n       Don't insert UNIX-style From_ line in header
o	Always run as the owner of the recipient mailbox. Normally sendmail
	runs as the sender for locally generated mail or as "daemon"
	(actually, the user specified in the u option) when delivering
	network  mail. The  normal  behavior  is  required  by  most local
	mailers,  which  will  not allow the envelope sender address to be set
	unless the mailer is running as daemon.
	This flag is ignored if the S flag is set.
p	Use the route-addr style reverse-path in the SMTP "MAIL FROM:" command
	rather than just the return address; although this is required
	in RFC821 section 3.1, many hosts do not process reverse-paths properly.
	Reverse-paths are officially discouraged by RFC 1123.
P +     This mailer needs Return-Path: in header.
q	When an address that resolves to this mailer is verified (SMTP VRFY
	command), generate 250 responses instead of 252 responses.
	This will imply that the address is local.
r	same as f, but sends a -r flag.
R	Open SMTP connections from a "secure" port. Secure ports aren't
	(secure, that is) except on UNIX machines, so it is unclear that this
	adds anything.
s	strip quote characters (" and \) off of the address before calling
	the mailer
S	Assume specified uid and gid, i.e. don't reset the userid before calling
	the mailer. This would be used in a secure environment where sendmail
	ran as root. This could be used to avoid forged addresses.
	If the U= field is also specified, this flag causes the effective user
	id to be set to that user.
u       Preserve uppercase for username, standards require preservation of case
	in the local part of addresses, except for those address for which your
	system accepts responsibility.
	 You need the 'u' flag in SMTP mailers.  In fact, you need it for any
	 mailer which is not local in some broad sense.
0	Don't look up MX records for hosts sent via SMTP.
3	Extend the list of characters converted to =XX notation when converting
	to Quoted-Printable to include those that don't map cleanly between
	ASCII and EBCDIC. Useful if you have IBM mainframes on site.
5	If no aliases are found for this address, pass the address through
	ruleset 5 for possible alternate resolution. This is intended to forward
	the mail to an alternate delivery spot.
6	Strip headers to 7 bits.
7	Strip all output to 7 bits. This is the default if the L flag is set.
	Note that clearing this option is not sufficient to get full eight bit
	data passed through sendmail. If the 7 option is set, this is
	essentially always set, since the eighth bit was stripped on input.
	Note that this option will only impact messages that didn't have 8 to 7
	bit MIME conversions perfored.
         >So servers behaving as relay convert to 7-bit by default?
	 The SMTP standards are for 7-bit.  Therefore 8-bit should only be
	 sent when you know that the destination server will handle it
8	You would normally use '8' only when you know it is safe to do so,
	i.e. usual 8bit to 7bit conversion is bypassed.
	If set, it is acceptable to send eight bit data to this mailer; the
	usual attempt to do 8 to 7 bit MIME conversions will be bypassed.
9       Convert 7-bit to 8-bit in some special cases. These conversions are
	limited to text/plain data.
		: Check addresses to see if they begin
	":include:"; if they do, convert them to the "*include*" mailer.
		| Check addresses to see if they begin with a `|';
	if they do, convert them to the "prog" mailer.
		/ Check addresses to see if they begin with a `/'; if they do,
	convert them to the "*file*" mailer.			    
         The '9' is mainly useful in mailers which do final delivery.  There
         isn't any point in converting to 8-bit for a message in transit, only
         to have the next processing program to convert back to 7-bit.
         However, on final delivery there is no "next processing program"
         other than a user mail reader.
			-- Neil W Rickert 
	 >So what the 9 option does?
         If mail has been converted from 8-bit to 7-bit in transit, then under
         limited circumstances it can be converted back to 8-bit.
			-- Neil W Rickert 
w	The user must have a valid account on this machine, i.e. getpwnam()
	must succeed. If not, the mail is bounced. This is required to to get
	".forward" capability.
z	run Local Mail Transfer Protocol (LMTP) be tween sendmail and local
	mailer. THis is a variant of SMTP defined in RFC2033 that is
	specifically designed for delivery to local mailbox.

	>> > What about the z flag, shouldn't I prefer using this flag for
	>> > procmail as LDA?
	>> >
	>> Sure. But only if the LDA understands LMTP. Most local delivery
	>> agents do not.
	> Probably not the right place to ask, but is the default local mailer
	> (/bin/mail) LDA capable? Is procmail LDA capable?
	You would have to ask your system vendor about '/bin/mail'.  No,
	'procmail' is not LMTP or SMTP capable. The 'mail.local' that comes with
	sendmail is LMTP capable. If it can be used on your system, I recommend
	it as a good delivery agent, although not as flexible as 'procmail'.

: Check addresses to see if they begin
        ":include:"; if they do, convert them to the "*include*" mailer.
| Check addresses to see if they begin with a `|';
        if they do, convert them to the "prog" mailer.
/ Check addresses to see if they begin with a `/'; if they do,
        convert them to the "*file*" mailer.
@	Look up addresses in the user database.
%	Do not attempt delivery on initial recipient of a message or on queue
	runs unless the queued message is selected using one of the -qI/-qR/-qS
	queue run modifiers or an ETRN request.

MIME conversions inside sendmail

As an addition to discussion of MIME conversion in sendmail(sendmail can convert only body of a message, it never converts headers, so the above mailer flags 7, 8, 9 only affect body of message, not headers) I've put here some info on MIME and sendmail. Further, the conclusion you've just read, if you intend to convert MIME headers to 8-bit, you need to do it yourself. The dmmh you already saw, here are more messages about MIME, there's one solution from Rik Kabel, second from Ralph Sobek (Ralph is updating his script nowadays).

MIME programs:

mpack --
MetaMail --
emil -

You also have to setup smrsh to execute some files, otherwise it will deny all requests. You have to tell smrsh that procmail and for example vacation are valid program which it may exec. All other execution will be denied.

cd /var/adm
mkdir sm.bin
cd sm.bin
ln -s /usr/local/bin/procmail .
ln -s /usr/bin/vacation .
ln -s /usr/majordomo/resend .
ln -s /usr/majordomo/tlb .
ln -s /bin/mail .
echo "The above files are now allowed to be executed by smrsh from within sendmail"

smrsh is really a nifty package and it's worthwhile to use it:

> I would like my users to individually use procmail from their .forward,
> but I would like to use smrsh as well. Is there any solution?

For security reasons you should install smrsh into
At least for performance and quality of procmail you should use procmail
as a Local Delivery Agent (Mlocal part). That's because procmail is fast,
reliable, handles many locking strategies, there's simply no reason why not
to do that - IMHO.

You may want to install sendmail's helpfile like this:

cp sendmail-8.10.0/obj*/sendmail/helpfile /etc/mail/helpfile
If you want to enable the hoststatus feature, do also:
mkdir /var/spool/mqueue/.hoststat
touch /etc/mail/statistics
chmod 644 /etc/mail/statistics

Sendmail and DNS records, in respect to antiSPAM - campus wide solution:

You would configure properly your forward DNS database to protect your network against unauthorized relaying attempts. Block on your router all incoming SMTP(tcp/25) data to other hosts than mail.domain and it's backups mail2.domain and mail3.domain. Let's suppose you have also mail4.otherdomain server which collects e-mail for you domain if your router is down.

 IN MX  10 mail.domain.
 IN MX 100 mail2.domain.
 IN MX 200 mail3.domain.
 IN MX 300 mail4.otherdomain.

Because you are blocking SMTP connections to all SMTP-capable machines you don't have root access to or don't have time to upgrade to latest sendmail with antispam config, you have to create MX records for these machine. If mailers used by clients are configured correctly, before they try to send an e-mail, they should do an MX lookup, and get MX records for destination host, and if there are any, client mailers should use them in preference to direct delivery.

Let's say you want have somehost.domain, which without an MX recor cannot recieve any e-mail outside your domain, because it's in your firewalled network. ;-) The MX priority can be of any value.

The idea is:
We have an e-mail for user@somehost.domain, does the somehost.domain have an MX record? YES, it's mail.domain and it's the only one MX record. Let's try to deliver it there. Does mail.domain have some MX record? YES, 4 records! Great. Let's try the one with lowest priority, i.e. mail.domain itself. Ooooops, it's down! Let's try mail2.domain ... and so on.

somehost.domain.  IN MX 200 mail.domain.
somehost2.domain. IN MX 200 mail.domain.
somehost3.domain. IN MX 200 mail.domain.

Further, you will most probably need enabled the following line in /etc/mail/ , otherwise you will most probably get an error like Local configuration error: MX loops back to myself ...

FAQ 4.5 describes a situation where a host (let's call it "source") is sending to another host (let's call it "target"), and source determines that the best preference MX for target is source itself.  But target is not in $=w (class w, the set of host names recognized as local). So sendmail gets confused and issue the error you reported.  You need to either make another machine besides source (host we you get this error) the better preference MX for target, or you need to add this host(where you get an error right now) to $=w as described in FAQ 4.5 (


# if we are the best MX host for a site, try it directly instead of config err
O TryNullMXList

Note on Berkeley DB makemap usage:

The following e-mail was about the problem, that I "discovered", that on SGI server is also `makemap' program, which does something different what i expected - manipulates colors. Since then I know, that you even shoudln't use makemap from even Berkeley DB to produce .db files for sendmail.

Date: Mon, 25 Jan 1999 00:21:20 +0100 (MET)
From: Per Hedeland
Subject: Re: Broken DB-2.6.4 support on Irix6.2

Martin Mokrejs wrote:
> But, I was starting
>different makemap binary - some SGI product utility called makemap, which
>manipulates with color definitions.
>So, `makemap hash /etc/aliases < /etc/aliases' did produce
>/etc/aliases.db, with zero size.

Even if you get the "right" makemap, you can't use it to build the
aliases map - use 'newaliases' (a.k.a. 'sendmail -bi') for that.

How about sendmail saving the envelope information:

The information sent in rcpt to: line is passed to the LDA as $u, typically as a command line argument. It is not passed in a header. The problem is $u is only defined if there is a single recipient, hence the suggested solution below doesn't work always (it won't because of SECURITY - i.e. violating Bcc: recipients):

HX-Envelope-From: $g
HX-Envelope-To: $u

There are some web pages related to this problem:

I have to try once this solution:

Date: Wed, 23 Feb 2000 09:03:33 +0100 (MET)
From: Gjermund Sorseth 
Subject: Re: Envelope address in procmail?

   >  No, sendmail only pass headers to the MDAs, end of story.
   >  Regards,
   >  Liviu Daia

No, sendmail passes anything you configure it to pass. In the definition
of the local mailer you tell it which program to run and what its
arguments should be. So if the delivery agent wants the envelope
information (in argv), it can have it.

I tell my sendmail to call procmail with -f sender, so in this case
procmail gets the envelope sender. What procmail uses this information
for is up to procmail. Perhaps it would be useful to be able to fetch
it in a procmailrc file?
Gjermund Sorseth