PC World Interactive 1

home *** CD-ROM | disk | FTP | other *** search

/ PC World Interactive 1 / PC World Interactive 1 - Nisan 1997.iso / nostalji / bbs / faq / sendmail.txt < prev next >

Wrap

Internet Message Format | 1995-06-26 | 31.8 KB

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!gatech!newsxfer.itd.umich.edu!news.cic.net!locust.cic.net!pauls From: pauls@CIC.Net Newsgroups: comp.mail.sendmail,comp.mail.misc,comp.answers,news.answers Subject: comp.mail.sendmail Frequently Asked Questions (FAQ) Followup-To: comp.mail.sendmail Date: 27 Jun 1995 04:59:51 GMT Organization: CICNet, Inc. Lines: 709 Approved: news-answers-request@MIT.Edu Distribution: world Expires: 08/01/95 01:00:01 Message-ID: <3so387$mjn@spruce.cic.net> Reply-To: sendmail-faq@birch.ims.disa.mil (Sendmail FAQ Maintainers) NNTP-Posting-Host: locust.cic.net Summary: This posting contains a list of Frequently Asked Questions (and their answers) about the program "sendmail", distributed with many versions of Unix (and available for some other operating systems). This FAQ is shared between comp.mail.sendmail and the Sendmail V8 distribution. It should be read by anyone who wishes to post to comp.mail.sendmail, or anyone having questions about the newsgroup itself. Keywords: sendmail mail SMTP FAQ X-Posting-Frequency: posted on the 27th of each month Originator: pauls@locust.cic.net Xref: senator-bedfellow.mit.edu comp.mail.sendmail:21672 comp.mail.misc:24425 comp.answers:12729 news.answers:47113 Posted-By: auto-faq 3.1.1.2 Archive-name: mail/sendmail-faq [The most recent copy of this document can be obtained via anonymous FTP from rtfm.mit.edu in /pub/usenet/news.answers/mail/sendmail-faq. If you do not have access to anonymous FTP, you can retrieve it by sending email to mail-server@rtfm.mit.edu with the command "send usenet/news.answers/mail/sendmail-faq" in the message.] comp.mail.sendmail Frequently Asked Questions Last updated 2 Jun 1995 This FAQ is centered around sendmail V8 (8.6.12 being the most recent released version AFAIK, with 8.7 in early beta). As of yet, it makes no attempt to cover other versions of sendmail in any depth, although certain other versions do get mentioned in passing. Comments should be sent to <sendmail-faq@birch.ims.disa.mil> Note that much of this document is copied verbatim from the FAQ developed by Eric Allman for sendmail V8, although these two documents are continuing to diverge. I've tried to be very careful to emulate his style and tone, so that this document has a consistent "feel" to it. Unfortunately, I may not have completely succeeded and where he may have been succint, I may have come across as terse (or worse). I apologize in advance for anyone who is offended, but this document is currently targeted towards the experienced Unix System Administrator/Domain Administrator/Postmaster, and therefore much has been omitted in the interest of brevity (perhaps too much, at least on my part). With several major overhauls scheduled (including at least one complete re-write), this situation will hopefully improve dramatically, but you have to bear with me for the nonce. -Brad Knowles comp.mail.sendmail FAQ Coordinator ====================================================================== BEFORE YOU GO ANY FURTHER ====================================================================== * What do you wish everyone would do before sending you mail or posting to comp.mail.sendmail? Read this FAQ completely. If they're posting a question about Sendmail V8, read src/READ_ME and cf/README completely. Read the books written to help with common problems such as compilation and installation, configuration, security issues, etc.... Ask themselves if their question hasn't already been answered. ---------------------------------------------------------------------- * How can I be sure if this is the right place to look for answers to my questions? 1. Do you know, for a fact, that the question is related to the Unix program "sendmail"? 2. Is the question about a sendmail-like program (e.g., Smail, Zmailer, MMDF, etc...)? 3. Is the question about an SMTP Gateway product for a LAN mail package (e.g., cc:Mail, MS-Mail, WordPerfect Office/GroupWise, etc...) or a POP/IMAP client program (e.g., Eudora, Pegasus, Z-Mail, etc...)? If you answered "yes" to the question #1, then this is the right place. If you're not using the most recent version of sendmail V8, be prepared for a lot of answers that amount to "Get V8". V8 doesn't solve every single sendmail problem that exists (properly configured or not), but it is the area of heaviest current development and solves a long laundry list of problems that previous versions of sendmail have. If you answered "yes" to question #2 and are not going to upgrade to sendmail (presumably V8), then this is probably not the right place to look. I recommend looking elsewhere in the "comp.mail.*" hierarchy and seeing if there is a newsgroup that might be more appropriate (comp.mail.smail, comp.mail.misc, etc...). If you answered "yes" to question #3, then this is certainly not the right place to look. Look around elsewhere in the "comp.mail.*" or "comp.*" hierarchy for a more appropriate newsgroup. You may also find some useful information in ftp://rtfm.mit.edu:/pub/usenet/news.answers/mail/mailclients-faq (put together by Paul Southworth from various sources on comp.mail.misc). Note that Z-Mail now has it's own newsgroup, comp.mail.zmail. If you couldn't answer "yes" to any of the above questions, then you're DEFINITELY in the wrong place. For the sake of your sanity and ego, not to mention avoiding the waste of your time and ours, try asking your System or E-Mail Administrator(s) before you post any questions publicly. ---------------------------------------------------------------------- * Where can I find the latest version of this FAQ? The most recent version is available via anonymous ftp to rtfm.mit.edu in /pub/usenet/news.answers/mail/sendmail-faq. If you do not have access to anonymous FTP, you can retrieve it by sending email to mail-server@rtfm.mit.edu with the command "send usenet/news.answers/mail/sendmail-faq" in the message. ---------------------------------------------------------------------- * I don't have access to Usenet news. Can I still get access to comp.mail.sendmail? Yes. Send email to mxt@dl.ac.uk with the command "sub comp-news.comp.mail.sendmail <full-US-ordered-email-address>" in the message. E-mail you want posted on comp.mail.sendmail should be sent to comp-mail-sendmail@dl.ac.uk ---------------------------------------------------------------------- * I have sendmail-related DNS questions. Where should I ask them? Depending on how deeply they get into the DNS, they can be asked here. However, you'll probably be told that you should send them to the Info-BIND mailing list (if the question is specific to that program) or to the Usenet newsgroup comp.protocols.tcp-ip.domains (DNS in general). ---------------------------------------------------------------------- * How do I subscribe to either of these? For comp.protocols.tcp-ip.domains, you have to be on Usenet. So far as we know, they don't have a news-to-mail gateway yet. They do have a FAQ, and it can be found at <URL:ftp://ftp.njit.edu/pub/dns/Comp.protocols.tcp-ip.domains.FAQ> For the Info-BIND mailing list, send email to bind-request@uunet.uu.net with the command "subscribe" in the message. Submissions should be sent to bind@uunet.uu.net ====================================================================== TO DO (in no particular order) ====================================================================== Table of Contents Restructure content (outline format) Index Additional net resources (web pages, anonymous ftp sites, etc...) Annotated bibliography (including RFCs and comments/corrections for books specific to sendmail) Reorganize by platform/version of sendmail (All Sun questions in one section, all AIX questions in another, etc...) ====================================================================== GENERAL QUESTIONS ====================================================================== * Where can I get Version 8? Via anonymous FTP from FTP.CS.Berkeley.EDU in /ucb/sendmail. ---------------------------------------------------------------------- * What are the differences between Version 8 and other versions? See doc/changes/changes.me in the sendmail V8 distribution. ---------------------------------------------------------------------- * What books are available describing sendmail? There are two books available devoted to sendmail: Costales, Allman, and Rickert, _Sendmail_. O'Reilly & Associates. Avolio & Vixie, _Sendmail: Theory and Practice_. Digital Press. Several books have sendmail chapters, for example: Nemeth, Snyder, and Seebass, _Unix System Administration Handbook_. Prentice-Hall. Carl-Mitchell and Quarterman, _Practical Internetworking with TCP/IP and UNIX_. Addison-Wesley. Hunt, _TCP/IP Network Administration_. O'Reilly & Associates. For details on sendmail-related DNS issues, consult: Liu and Albitz, _DNS and BIND_. O'Reilly & Associates. For details on UUCP, see: O'Reilly and Todino, _Managing UUCP and Usenet_. O'Reilly & Associates. ====================================================================== CONFIGURATION QUESTIONS (V8 unless otherwise indicated) ====================================================================== * How do I make all my addresses appear to be from a single host? Using the m4 macros, use: MASQUERADE_AS(my.dom.ain) This will cause all addresses to be sent out as being from the indicated domain. On your mailhub/mailhost/Domain Mail eXchanger, you may need to add "my.dom.ain" to the sendmail.cw file or the "Cwhost.my.dom.ain" line in the sendmail.cf file. ---------------------------------------------------------------------- * How do I rewrite my From: lines to read ``First_Last@My.Domain''? There are a couple of ways of doing this. This describes using the "user database" code. This is still experimental, and was intended for a different purpose -- however, it does work with a bit of care. It does require that you have the Berkeley "db" package installed (it won't work with DBM). First, create your input file. This should have lines like: loginname:mailname First_Last First_Last:maildrop loginname Install it in (say) /etc/userdb. Create the database: makemap btree /etc/userdb.db < /etc/userdb You can then create a config file that uses this. You will have to include the following in your .mc file: define(confUSERDB_SPEC, /etc/userdb.db) FEATURE(notsticky) ---------------------------------------------------------------------- * So what was the user database feature intended for? The intent was to have all information for a given user (where the user is the unique login name, not an inherently non-unique full name) in one place. This would include phone numbers, addresses, and so forth. The "maildrop" feature is because Berkeley does not use a centralized mail server (there are a number of reasons for this that are mostly historic), and so we need to know where each user gets his or her mail delivered -- i.e., the mail drop. We are in the process of setting up our environment so that mail sent to an unqualified "name" goes to that person's preferred maildrop; mail sent to "name@host" goes to that host. The purpose of "FEATURE(notsticky)" is to cause "name@host" to be looked up in the user database for delivery to the maildrop. ---------------------------------------------------------------------- * Why are you so hostile to using full names for e-mail addresses? Because full names are not unique. For example, the computer community has two Andy Tannenbaums and two Peter Deutsches. At one time, Bell Labs had two Stephen R. Bournes with offices a few doors apart. You can create alternative addresses (e.g., Stephen_R_Bourne_2), but that's even worse -- which one of them has to have their name desecrated in this way? And you can bet that one of them will get most of the other person's e-mail. So called "full names" are just an attempt to create longer versions of unique names. Rather that lulling people into a sense of security, I'd rather that it be clear that these handles are arbitrary. People should use good user agents that have alias mappings so that they can attach arbitrary names for their personal use to those with whom they correspond (such as the MH alias file). Even worse is fuzzy matching in e-mail -- this can make good addresses turn bad. For example, Eric Allman is currently (to the best of our knowledge) the only ``Allman'' at Berkeley, so mail sent to "Allman@Berkeley.EDU" should get to him. But if another Allman ever appears, this address could suddenly become ambiguous. He's been the only Allman at Berkeley for over fifteen years -- to suddenly have this "good address" bounce mail because it is ambiguous would be a heinous wrong. Finger services should be as fuzzy as possible (within reason, of course). Mail services should be unique. ---------------------------------------------------------------------- * Should I use a wildcard MX for my domain? If at all possible, no. Wildcard MX records have lots of semantic "gotcha"s. For example, they will match a host "unknown.your.domain" -- if you don't explicitly test for unknown hosts in your domain, you will get "config error: mail loops back to myself" errors. See RFCs 1535-1537 for more detail and other related (or common) problems. ---------------------------------------------------------------------- * How can I get sendmail to process messages sent to an account and send the results back to the originator? This is a local mailer issue, not a sendmail issue. Depending on what you're doing, look at procmail (mentioned again below), ftpmail, or Majordomo. Check your local archie server to see what machine(s) nearest you have the most recent versions of these programs. ---------------------------------------------------------------------- * How can I get sendmail to deliver local mail to $HOME/.mail instead of into /usr/spool/mail (or /usr/mail)? Again, this is a local mailer issue, not a sendmail issue. Either modify your local mailer (source code will be required) or change the program called in the "local" mailer configuration description to be a new program that does this local delivery. One program that is capable of doing this is "procmail", although there are probably many others as well. You might be interested in reading the paper ``HLFSD: Delivering Email to your $HOME'' available in the Proceedings of the USENIX System Administration (LISA VII) Conference (November 1993). This is also available via public FTP from ftp.cs.columbia.edu in /pub/hlfsd/{README.hlfsd,hlfsd.ps}. ---------------------------------------------------------------------- * I'm trying to to get my mail to go into queue only mode, and it delivers the mail interactively anyway. (Or, I'm trying to use the "don't deliver to expensive mailer" flag, and it delivers the mail interactively anyway.) I can see it does it: here's the output of "sendmail -v foo@somehost" (or Mail -v or equivalent). The -v flag to sendmail (which is implied by the -v flag to Mail and other programs in that family) tells sendmail to watch the transaction. Since you have explicitly asked to see what's going on, it assumes that you do not want to to auto-queue, and turns that feature off. Remove the -v flag and use a "tail -f" of the log instead to see what's going on. If you are trying to use the "don't deliver to expensive mailer" flag (mailer flag "e"), be sure you also turn on global option "c" -- otherwise it ignores the mailer flag. ---------------------------------------------------------------------- * There are four UUCP mailers listed in the configuration files. Which one should I use? The choice is partly a matter of local preferences and what is running at the other end of your UUCP connection. Unlike good protocols that define what will go over the wire, UUCP uses the policy that you should do what is right for the other end; if they change, you have to change. This makes it hard to do the right thing, and discourages people from updating their software. In general, if you can avoid UUCP, please do. If you can't avoid it, you'll have to find the version that is closest to what the other end accepts. Following is a summary of the UUCP mailers available. uucp-old (obsolete name: "uucp") This is the oldest, the worst (but the closest to UUCP) way of sending messages across UUCP connections. It does bangify everything and prepends $U (your UUCP name) to the sender's address (which can already be a bang path itself). It can only send to one address at a time, so it spends a lot of time copying duplicates of messages. Avoid this if at all possible. uucp-new (obsolete name: "suucp") The same as above, except that it assumes that in one rmail command you can specify several recipients. It still has a lot of other problems. uucp-dom This UUCP mailer keeps everything as domain addresses. Basically, it uses the SMTP mailer rewriting rules. Unfortunately, a lot of UUCP mailer transport agents require bangified addresses in the envelope, although you can use domain-based addresses in the message header. (The envelope shows up as the From_ line on UNIX mail.) So.... uucp-uudom This is a cross between uucp-new (for the envelope addresses) and uucp-dom (for the header addresses). It bangifies the envelope sender (From_ line in messages) without adding the local hostname, unless there is no host name on the address at all (e.g., "wolf") or the host component is a UUCP host name instead of a domain name ("somehost!wolf" instead of "some.dom.ain!wolf"). Examples: We are on host grasp.insa-lyon.fr (UUCP host name "grasp"). The following summarizes the sender rewriting for various mailers. Mailer sender rewriting in the envelope ------ ------ ------------------------- uucp-{old,new} wolf grasp!wolf uucp-dom wolf wolf@grasp.insa-lyon.fr uucp-uudom wolf grasp.insa-lyon.fr!wolf uucp-{old,new} wolf@fr.net grasp!fr.net!wolf uucp-dom wolf@fr.net wolf@fr.net uucp-uudom wolf@fr.net fr.net!wolf uucp-{old,new} somehost!wolf grasp!somehost!wolf uucp-dom somehost!wolf somehost!wolf@grasp.insa-lyon.fr uucp-uudom somehost!wolf grasp.insa-lyon.fr!somehost!wolf ====================================================================== RESOLVING PROBLEMS (V8 unless otherwise specified) ====================================================================== * When I compile, I get "undefined symbol inet_aton" and "undefined symbol _strerror" messages. You've probably replaced your resolver with the version from BIND 4.9.3. You need to compile with -l44bsd in order to get the additional routines. ---------------------------------------------------------------------- * I'm getting "Local configuration error" messages, such as: 553 relay.domain.net config error: mail loops back to myself 554 <user@domain.net>... Local configuration error How can I solve this problem? You have asked mail to the domain (e.g., domain.net) to be forwarded to a specific host (in this case, relay.domain.net) by using an MX record, but the relay machine doesn't recognize itself as domain.net. Add domain.net to /etc/sendmail.cw (if you are using FEATURE(use_cw_file)) or add "Cw domain.net" to your configuration file. IMPORTANT: Be sure you kill and restart the sendmail daemon after you change the configuration file (for ANY change in the configuration, not just this one): kill `head -1 /etc/sendmail.pid` sh -c "`tail -1 /etc/sendmail.pid`" NOTA BENE: kill -1 does not work! ---------------------------------------------------------------------- * When I use sendmail V8 with a Sun config file I get lines like: /etc/sendmail.cf: line 273: replacement $3 out of bounds the line in question reads: R$*<@$%y>$* $1<@$2.LOCAL>$3 user@ether what does this mean? How do I fix it? V8 doesn't recognize the Sun "$%y" syntax, so as far as it is concerned, there is only a $1 and a $2 (but no $3) in this line. Read Rick McCarty's paper on "Converting Standard Sun Config Files to Sendmail Version 8", in the contrib directory (file "converting.sun.configs") in the latest sendmail V8 distribution for a full discussion of how to do this. ---------------------------------------------------------------------- * When I use sendmail V8 on a Sun, I sometimes get lines like: /etc/sendmail.cf: line 445: bad ruleset 96 (50 max) what does this mean? How do I fix it? You're somehow trying to start up the old Sun sendmail (or sendmail.mx) with a sendmail V8 config file, which Sun's sendmail doesn't like. Check your /etc/rc.local, any procedures that have been created to stop and re-start the sendmail processes, etc.... Make sure that you've switched everything over to using the new sendmail. To keep this problem from ever happening again, try the following: mv /usr/lib/sendmail /usr/lib/sendmail.old ln -s /usr/local/lib/sendmail.v8 /usr/lib/sendmail mv /usr/lib/sendmail.mx /usr/lib/sendmail.mx.old ln -s /usr/local/lib/sendmail.v8 /usr/lib/sendmail.mx chmod 0000 /usr/lib/sendmail.old chmod 0000 /usr/lib/sendmail.mx.old Assuming you have installed sendmail V8 in /usr/local/lib. ---------------------------------------------------------------------- * When I use sendmail V8 on an IBM RS/6000 running AIX, the system resource controller always reports sendmail as "inoperative" even though it is running. What's wrong? When running as a daemon, sendmail detaches from its parent process, fooling the SRC into thinking that sendmail has exited. To fix this, issue the commands: kill `head -1 /etc/sendmail.pid` chssys -s sendmail -f 9 -n 15 -S -a "-d0.1" startsrc -s sendmail -a "-bd -q30m" # your sendmail args may vary Now the SRC should report the correct status of sendmail. A side-effect of the "-d0.1" option is that a few lines of debug output will be printed on the system console every time sendmail starts up. For more information, read up on the System Resource Controller, the lssrc command and the chssys command in the online documentation. ---------------------------------------------------------------------- * When I use sendmail V8 on an Intel x86 machine running Linux, I have some problems. Specifically.... The current versions of Linux are generally considered to be great for hobbyists and anyone else who wants to learn Unix inside and out, or wants to always have something to do, or wants a machine for light-duty mostly personal use and not high-volume multi-user purposes. However, for those who want a system that will just sit in the background and work without a fuss handling thousands of mail messages a day for lots of different users, it's not (yet) stable enough to fit the bill. Unfortunately, there are no known shareware/freeware implementations of any operating system that provides the level of stability necessary to handle that kind of load (i.e., there are no free lunches). If you're wedded to the Intel x86 platform and want to run sendmail, we suggest you look at commercial implementations of Unix such as Interactive, UnixWare, Solaris, or BSD/386 (just a sample of the dozens of different versions of Unix for Intel x86). Of all known vendor supported versions of Unix for Intel x86, BSDI's BSD/386 is least expensive and the only one known to currently ship with sendmail V8 pre-installed. Since sendmail V8 is continuing to be developed at UC Berkeley, and BSD/386 is a full BSD 4.4 implementation, this is obviously be the most "native" sendmail V8 environment. ---------------------------------------------------------------------- * When I use sendmail on an Intel x86 machine running OS/2, I have some problems. Specifically, I have.... The OS/2 port of sendmail is known to have left out huge chunks of the code and functionality of even much older versions of sendmail, in large part because the underlying OS just doesn't have the necessary hooks to make it happen. This port is so broken that we make no attempt to provide any kind of support for it. Try BSDI's BSD/386 instead. ---------------------------------------------------------------------- * I'm connected to the network via a SLIP/PPP link. Sometimes my sendmail process hangs (although it looks like part of the message has been transfered). Everything else works. What's wrong? Most likely, the problem isn't sendmail at all, but the low level network connection. It's important that the MTU (Maximum Transfer Unit) for the SLIP connection be set properly at both ends. If they disagree, large packets will be trashed and the connection will hang. ---------------------------------------------------------------------- * I just upgraded to 8.x and suddenly I'm getting messages in my syslog of the form "collect: I/O error on connection". What is going wrong? Nothing. This is just a diagnosis of a condition that had not been diagnosed before. If you are getting a lot of these from a single host, there is probably some incompatibility between 8.x and that host. If you get a lot of them in general, you may have network problems that are causing connections to get reset. ---------------------------------------------------------------------- * I just upgraded to 8.x and now when my users try to forward their mail to a program they get an "illegal shell" message and their mail is not delivered. What's wrong? In order for people to be able to run a program from their .forward file, 8.x insists that their shell (that is, the shell listed for that user in the passwd entry) be a "valid" shell, meaning a shell listed in /etc/shells. If /etc/shells does not exist, a default list is used, typically consisting of /bin/sh and /bin/csh. This is to support environments that may have NFS-shared directories mounted on machines on which users do not have login permission. For example, many people make their file server inaccessible for performance or security reasons; although users have directories, their shell on the server is /usr/local/etc/nologin or some such. If you allowed them to run programs anyway you might as well let them log in. If you are willing to let users run programs from their .forward file even though they cannot telnet or rsh in (as might be reasonable if you run smrsh to control the list of programs they can run) then add the line /SENDMAIL/ANY/SHELL/ to /etc/shells. This must be typed exactly as indicated, in caps, with the trailing slash. NOTA BENE: DO NOT list /usr/local/etc/nologin in /etc/shells -- this will open up other security problems. ---------------------------------------------------------------------- * I just upgraded to 8.x and suddenly connections to the SMTP port take a long time. What is going wrong? It's probably something weird in your TCP implementation that makes the IDENT code act oddly. On most systems V8 tries to do a ``callback'' to the connecting host to get a validated user name (see RFC 1413 for detail). If the connecting host does not support such a service it will normally fail quickly with "Connection refused", but certain kinds of packet filters and certain TCP implementations just time out. To test this, set the IDENT timeout to zero using: define(`confREAD_TIMEOUT',`Ident=0')dnl in the .mc file used by m4 to generate your sendmail.cf file. Alternatively, if you don't use m4, you can put ``OrIdent=0'' in the configuration file (we recommend the m4 solution, since that makes maintenance much easier for people who don't understand sendmail re-write rules, or after you've been away from it for a while). Either way, this will completely disable all use of the IDENT protocol. Another possible problem is that you have your name server and/or resolver configured improperly. Make sure that all "nameserver" entries in /etc/resolv.conf point to functional servers. If you are running your own server make certain that all the servers listed in your root cache (usually called something like "/var/namedb/root.cache"; see your /etc/named.boot file to get your value) are up to date. Either of these can cause long delays. ---------------------------------------------------------------------- * I just upgraded to 8.x and suddenly I get errors such as ``unknown mailer error 5 -- mail: options MUST PRECEDE recipients.'' What is going wrong? You need OSTYPE(systype) in your .mc file -- otherwise the configurations use a default that probably disagrees with your local mail system. See cf/README for details. ---------------------------------------------------------------------- * Under V8, the "From " header gets mysteriously munged when I send to an alias. ``It's not a bug, it's a feature.'' This happens when you have a "owner-list" alias and you send to "list". V8 propagates the owner information into the envelope sender field (which appears as the "From " header on UNIX mail or as the Return-Path: header) so that downstream errors are properly returned to the mailing list owner instead of to the sender. In order to make this appear as sensible as possible to end users, I recommend making the owner point to a "request" address -- for example: list: :include:/path/name/list.list owner-list: list-request list-request: eric This will make message sent to "list" come out as being "From list-request" instead of "From eric". ---------------------------------------------------------------------- * I am trying to use MASQUERADE_AS (or the user database) to rewrite from addresses, and although it works in the From: header line, it doesn't work in the envelope (e.g., the "From " line). Believe it or not, this is intentional. The interpretation of the standards by the V8 development group was that this was an inappropriate rewriting, and that if the rewriting were incorrect at least the envelope would contain a valid return address. Other people have since described scenarios where the envelope cannot be correct without this rewriting, so 8.7 will have an option to rewrite both header and envelope. ---------------------------------------------------------------------- * I want to run Sendmail version 8 on my DEC system, but you don't have MAIL11V3 support in sendmail. How do I handle this? Get the reimplementation of the mail11 protocol by Keith Moore from gatekeeper.dec.com in /pub/DEC/gwtools (with contributions from Paul Vixie). Rumour has it that Paul will be fully integrating into sendmail V8 what little is left of IDA sendmail that is not handled (or handled as well) by V8. No additional information on this project is currently available. ---------------------------------------------------------------------- * Messages seem to disappear from my queue unsent. When I look in the queue directory I see that they have been renamed from qf* to Qf*, and sendmail doesn't see these. If you look closely you should find that the Qf files are owned by users other than root. Since sendmail runs as root it refuses to believe information in non-root-owned qf files, and it renames them to Qf to get them out of the way and make it easy for you to find. The usual cause of this is twofold: first, you have the queue directory world writable (which is probably a mistake -- this opens up other security problems) and someone is calling sendmail with an "unsafe" flag, usually a -o flag that sets an option that could compromise security. When sendmail sees this it gives up setuid root permissions. The usual solution is to not use the problematic flags. If you must use them, you have to write a special queue directory and have them processed by the same uid that submitted the job in the first place. ----------------------------------------------------------------------