Actual version you can find at http://www.natur.cuni.cz/~mmokrejs/sendmail
The original, old and NOT recommended version is here
Last update: 21. 9. 2001
Similar page you can find at http://www.iicons.com/sendmail/configme.html
However, there are PERFECT (although unofficial) pages at http://www.sendmail.org/~ca/email/misc.html
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
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 www.sendmail.org.
Advanced users can visit http://www.sendmail.org/~ca/email/chk89-opt.html, but it's not necessary.
Before compiling sendmail, install db-2.7.X from http://www.sleepycat.com/ 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 sendmail.cf 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 ftp://cs.uta.fi/pub/ssjaaa/bookmark.html
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 ftp://ftp.porcupine.org/pub/security:
- 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 http://www.procmail.org/
gzip -dc procmail-3.14.1.tar.gz |tar xvf - cd procmail-3.14.1 make make install-suid
-new Berkeley DB (1.85 or better never releases from 2.x series or 3.x series), get it from http://www.sleepycat.com/
gzip -dc db-2.7.7.tar.gz |tar xvf - cd db-2.7.7/build_unix ../dist/configure --prefix=/usr/local make make install
-sendmail, get it from http://www.sendmail.org/ 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 \ /Site/natur.cuni.cz.config.m4" ./Build -Q natur.cuni.cz echo "I install binaries by hand, otherwise ./Build install works but doesn't use \ obj.natur.cuni.cz*/ , 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 "sendmail.cf you can create this way" echo "cd cf/cf; make install-cf CF=other-unixes.natur.cuni.cz" echo "don't forget to:" echo "mv /etc/sendmail.cw /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 obj.natur.cuni.cz*/sendmail/helpfile /etc/mail/helpfile"
Notes: 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
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 sendmail.cf 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/op.ps . 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 hotmail.com, 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 hotmail.com 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/op.ps 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 transaction. 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 Cc: email@example.com 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> >NR> For example, suppose you send a message to >NR> 'firstname.lastname@example.org' with a Cc: to >NR> 'email@example.com'. 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 sendmail.org 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> >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/op.ps, 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 forward 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 correctly. 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).
mpack -- ftp://ftp.andrew.cmu.edu/pub/mpack/ MetaMail -- http://bmrc.berkeley.edu/~trey/emacs/metamail.html emil - ftp://ftp.uu.se/pub/unix/networking/mail/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 sendmail.cf. 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 firstname.lastname@example.org, 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/sendmail.cf , 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 (http://www.sendmail.org/faq/section4.html).
# 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
To: email@example.com Cc: firstname.lastname@example.org 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
To: Liviu.Daia@imar.ro Cc: email@example.com 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