+------------------------------------------------------------------------------+ | POSTFIX/ENGARDE HOWTO 05/18/01| | Peter O'Hara | +------------------------------------------------------------------------------+ ----------------- I. INTRODUCTION ----------------- This document outlines running Postfix on EnGarde. ------------------------- II. GENERAL INFORMATION ------------------------- Postfix configuration is done with the files in /etc/postfix, /usr/lib /libexec/postfix contains the postfix daemons, and /var/spool/postfix contains the mail queues and various mail staging directories and the default chroot directory "etc" (if chrooting is configured). /etc/postfix will be the most important directory as it controls postfix's behaviour. This directory holds the two configuration files and the aliases, virtual, transport, access, and other databases in maps. Maps: ----- There are many maps that can be used with postfix but I will only discuss the main three here as they are the basis of most typical Postfix configurations. The others are for more specialized purposes and are beyond the scope of this document. There are also several different "maptypes" or formats that can be used such as "hash", "dbm", "nis", and ascii "regexp" files. All of the maptype files have an ascii form and then are converted to a "maptype" database file with the "postmap" utility (except for "regexp" files which just have the ascii form). The "maptype" used by default with EnGarde is "hash". Aliases Map: ------------ The format of the "aliases" file is identical to sendmail's is function and format where the entries are of the form: local-user: alias where aliase can be another local user name, or user@[some-machine, some-machine@somedomain] A typical example: root: pete@guardiandigital.com Converting "aliases" file to a database file: postalias hash:/etc/postfix/aliases ********************************************************************** * NOTE - ALL OTHER DATABASES ARE CREATED WITH THE "postmap" COMMAND - * THE ALIASES MAP IS SPECIAL AND HAS IT'S OWN MAP CREATING COMMAND * "postalias". ********************************************************************** [root@juggernaut-t postfix]# postalias hash:/etc/postfix/aliases [root@juggernaut-t postfix]# ls -ltr /etc/postfix/aliases* -rw-r----- 1 root root 3768 May 21 14:03 /etc/postfix/aliases -rw-r--r-- 1 root root 20480 May 21 14:03 /etc/postfix/aliases.db [root@juggernaut-t postfix]# Here you can see that the aliases.db database file was created from the "postalias" command. Virtual Map: ----------- The "virtual" map defines virtual domains and their users. This allows the mail server to redirect incoming mail addressed to "user1@DOMAINNAME" to different destinations such as a another user of the same domain or a user in a different domain or even a combination of many users at many destinations. The "typical" format of this file is made up of one or many sections of the format: DOMAINNAME1 XXXXXXX user1@DOMAINNAME local-user user2@DOMAINNAME user@someotherdomain user3@DOMAINNAME user@someotherdomain, user@anotherdomain, ... . . @DOMAINNAME local-user or user@somedomain (OPTIONAL) where DOMAINNAME is the virtual domain name that you are defining followed by a top level domain suffix such as .com, .net, .org, etc.. and where XXXXXX can be any text (this is just a place holder) and is mandatory. The second field of the user definition can be one or more local users and or one or more users at some other domain. OPTIONAL: the "@DOMAINNAME user" defines that "user" will get all mail that is NOT defined for this domain. This means that "user" will get ALL mail sent to non-existent users of that domain. When NOT including such an entry, all mail sent to non-existent users will be bounced back to the sender with an error message. This would be a lower maintenance option that also has the benefit of letting a sender know that the addressee doesn' exist. A typical example: linuxseclabs.net VIRTUALDOMAIN bill@linuxseclabs.net bill joe@linuxseclabs.net joe@guardiandigital.com @linuxseclabs.net pete@guardiandigital.com Converting to the text file "virtual" to a map: postmap hash:/etc/postfix/virtual ************************************************************************** * AFTER MAKING ANY CONFIGURATION CHANGES, WHETHER THEY ARE TO A MAP OR A * CONFIGURATION FILE (main.cf, master.cf) YOU MUST EITHER RESTART POSTFIX * (/etc/init.d/postfix restart) OR RELOAD THE NEW CONFIGURATION TO THE * CURRENTLY RUNNING POSTFIX PROCESS (postfix reload). The quickest and less * intrusive form is to run "postfix reload" as this does not stop and start * the current process but just reloads the configuration. A total restart * can take time on a very active server. ************************************************************************** Transport Map: -------------- The "transport" map defines what server mail for a given domain will be forwarded to and by what transport. The format is a one line entry with the DOMAINNAME followed by the TRANSPORT:SERVERNAME. Transports are listed in the /etc/postfix/master.cf file. The most typical will be "smtp". Using any other transports is beyond the scope of this introductory document. A typical example: demo.guardiandigital.com smtp:smtp.demo.guardiandigital.com To convert the text file "tranpsort" to a map: postmap hash:/etc/postfix/transport Processing Order: ----------------- Postfix processes the virtual map against addresses BEFORE the transport map. This is important to know especially when trouble shooting. Other Maps: ----------- Here are a couple of several more maps worth briefly mentioning: relocated - The optional relocated table provides the information that is used in "user has moved to new_location" bounce messages. access - The optional access table directs the Postfix SMTP server to selectively reject or accept mail from or to specific hosts, domains, networks, host addresses or mail addresses. There is also the option of subdividing the "access" map into "recipient_access" and "sender_access" maps for a finer tuned access contol. canonical - The optional canonical table specifies an address mapping for local and non-local addresses. The mapping is used by the cleanup(8) daemon. --------------------- III. CONFIGURATION: --------------------- Main.cf: -------- The big Kahuna. This is where most of the configuration gets defined. This file is located at /etc/postfix/main.cf. Previously defined maps as well as up to 206 configuration parameters (as of snapshot-20010502) are combined in main.cf to formulate the Postfix configuration. But fortunately you don't need to know about most of the configuration parameters and Postfix was designed to accomodate many typical mail server scenarios out of the box. The main.cf file provides a decent amount of documentation and many times one only needs to read the description to get an understanding of the configuration parameter. But if more information is needed there is a full set of HTML docs in /usr/share/doc/postfix-XXXXXXXX/html that are very informative. Here is a listing with a description of the default /etc/postfix/main.cf file found in EnGarde-1.0: The queue_directory specifies the location of the Postfix queue. This is also the root directory of Postfix daemons that run chrooted. See the files in examples/chroot-setup for setting up Postfix chroot environments on different UNIX systems. queue_directory = /var/spool/postfix The command_directory parameter specifies the location of all postXXX commands. The default value is $program_directory. command_directory = /usr/sbin The daemon_directory parameter specifies the location of all Postfix daemon programs (i.e. programs listed in the master.cf file). The default value is $program_directory. This directory must be owned by root. daemon_directory = /usr/libexec/postfix The mail_owner parameter specifies the owner of the Postfix queue and of most Postfix daemon processes. Specify the name of a user account THAT DOES NOT SHARE A GROUP WITH OTHER ACCOUNTS AND THAT OWNS NO OTHER FILES OR PROCESSES ON THE SYSTEM. In particular, don't specify nobody or daemon. PLEASE USE A DEDICATED USER. mail_owner = postfix The myorigin parameter specifies the domain that locally-posted mail appears to come from. The default is to append $myhostname, which is fine for small sites. If you run a domain with multiple machines, you should (1) change this to $mydomain and (2) set up a domain-wide alias database that aliases each user to user@that.users.mailhost. myorigin = $myhostname The mydestination parameter specifies the list of domains that this machine considers itself the final destination for. That does not include virtual domains that are hosted on this machine. Those domains are specified elsewhere (see virtual and transport maps). mydestination = $myhostname, localhost.$mydomain $mydomain The smtpd_recipient_restrictions parameter specifies restrictions on recipient addresses that SMTP clients can send in RCPT TO commands. reject_unknown_client: reject the request if the client hostname is unknown (ie. not DNS resolveable). smtpd_client_restrictions = reject_unknown_client See "Aliases Map" above. alias_maps = hash:/etc/postfix/aliases *********************************************************************** * * CAUTION: THERE IS ALSO AN "aliases_database" MAP WHICH HAS A SLIGHTLY * DIFFERENT DEFINITION - TO AVOID CONFUSION "EnGarde" ONLY USES * "alias_maps" !!! * ************************************************************************ See "Virtual Maps" above. virtual_maps = hash:/etc/postfix/virtual See "Transport Maps" above. transport_maps = hash:/etc/postfix/transport The "relay_domains" parameter restricts what clients this mail system will relay mail from, or what destinations this system will relay mail to. Any domains listed in the "virtual" and "transport" maps MUST BE LISTED HERE! The "out of the box" default is to list "$mydestination" which by default refers to the local server. Here is a typical definition where the server will relay mail for itself and a couple of additional domains. relay_domains = $mydestination, linuxseclabs.com, linuxseclabs.net The "mynetworks" parameter specifies the list of networks that are local to this machine. The list is used by the anti-UCE software to distinguish local clients from strangers. By default, for security reasons, lists only hosts on the loopback network as trusted. mynetworks = 127.0.0.0/8 This is an EnGarde security default setting that disable the use of the SMTP VRFY address verification command that can be executed by mail clients. disable_vrfy_command = yes ********************* * NOT SET BY DEFAULT: ********************* relayhost - Unless your mail server is a top level server with access to the Internet you will want to set this paramater to point to an appropriate mail relay (typically the next one up the chain towards getting out to the Internet). Either an IP addresss or a resolveable hostname will work but using an IP address is safer in the case of a DNS outage. A typical format would look like this: relayhost = 222.333.444.555 (IP quad) Master.cf: ---------- This file is generally very static. It describes how each Postfix mailer component should be run. In most cases you shouldn't have to touch this file. In EnGarde we have modified this file to run all of the postfix daemons in the default chroot environment of /var/spool/postfix. The exceptions to this are the "local" and "pipe" programs which are restricted by Postfix to not run chrooted. Chroot Environment: ------------------- This environment is intended to limit system access to any malicious user who gains entry via an exploit of the mail system and contains only the very limited set of files necessary for the chrooted Postfix daemoms to run. The files that EnGarde includes in the chrooted environment are found in /var/spool/postfix/etc: [root@demo postfix]# ls -l /var/spool/postfix/etc total 24 -rw-r----- 1 root root 604 Mar 5 13:43 hosts -rw-r--r-- 1 postfix postfix 1250 Feb 7 08:30 localtime -rw-r--r-- 1 postfix postfix 153 Mar 6 11:45 resolv.conf -rw-r--r-- 1 postfix postfix 11332 Feb 7 08:30 services [root@demo postfix]# [root@demo postfix]# ls -l /var/spool/postfix/lib/ total 72 -rwxr-xr-x 1 postfix postfix 67600 Feb 7 08:30 libnss_dns.so.2 [root@demo postfix]# The /var/spool/postfix/etc files are copies of the ones found in /etc as is the /var/spool/postfix/lib/libnss_dns.so.2 a copy of the libnss_dns library found in /lib. --------- IV. RBL --------- The RBL system is used to restrict who can send mail to your site. The topic is one of pros and cons and the choice is left up to the administrator as to whether they should be deployed or not, therefore by default EnGarde does not have them turned on. RBL support is provided by several postfix parameters. The "maps_rbl_domains" parameter can be set to include several rbl domains. The default is "blackholes.mail- abuse.org". A multiple domain setting would look something like: maps_rbl_domains = blackholes.mail-abuse.org, dialups.mail-abuse.org, relays.mail-abuse.org, relays.orbs.org NOTE: As of snapshot-20010329 parameter definitions need to be on one line of text. When I tried using the "\" followed by a carriage return to extend the line onto the following line of text the parameter definition would break. That is why lengthy parameter definitions are shown as one line of text. Once the "maps_rbl_domains" parameter is set it can now be referenced by several other mail restriction type parameters. Here are some examples (you typically want to add RBL checks at the end of the list as a DNS lookup is performed when doing an RBL check - by putting them at the end of a list you avoid performing the check as much as possible as the smtp connection in question may be caught by a more leftmost restriction. The lists are processed from left to right): This one restricts the "MAIL FROM:" field in an incoming connection. smtpd_sender_restrictions = hash:/etc/postfix/access, reject_unknown_sender_domain, reject_maps_rbl This one restricts from where an incoming connection can be initiated from. smtpd_client_restrictions = reject_unknown_client, reject_maps_rbl -------------------------------------------------- V. SAMPLE POSTFIX WITH ENGARDE SECURE LINUX SETUP VIA THE WEBTOOL -------------------------------------------------- Here is simple example of setting up a top level mail server to receive mail for two domains, acme.com and wiley-coyote.org. The server is smtp.acme.com and therefore it is in the acme.com domain. As a courtesy to one of Acme's biggest customers, smtp.acme.com will receive and forward mail for the wiley-coyote.org domain to mail.wiley-coyote.orig as well as store Acme's mail locally in the standard /var/spool/mail directory using the WebTool. 1) This assumes that you have the WebTool running on your new mail server and you are connected and logged into the WebTool as "admin". From the main page follow the links "System Management" -> "Mail Serer Management" -> "Mail Server Configuration". If this is server is going to have a connection to the Internet (most likely through some sort of protection like a firewall) you would leave the "Deliver directly" button set. This is the setting we are going to use as our example is to configure a top level mail server. (If this were some internal server you would set up a connection to a relay server instead by clicking on the button to the left of the text field and filling in the field with the FQDN of the the mail relay. You may need to check with your network administrator/architect for the appropriate server name). Finish by clicking on "Save Options". 2) Back out of this page and go into "Domain Management". Here you would enter the domain into the "Domain" text field that you would like to receive mail for and store locally. In this case it would be "acme.com". You would also enter an email address for the person who would be postmaster of this domain into the "Postmaster" text field. Finish by clicking on "Add New Domain". You should now see the name "acme.com" listed in blue lettering below the "Domain Management" title bar at the top of the page verifying that the new domain has been created. 3) To add users to this domain click on the blue "acme.com" text and you will enter a page where you can add users. Here you define username- recipient pairs. For example to create the local user "joe@acme.com" enter "joe" in the E-Mail Username text field and "joe" in the "Recipient" text field. Click on "Add New" and you will see "joe@acme.com" appear in the "E-Mail Address" field in the lower portion of the page with a cooresponding "joe" in the "Recipient" field. NOTE: Local users such as "joe" above must be actual local users on this server. If they don't currently exist they can be created via "Main Page -> "System Management" under the "Local User Management" section. Refer to the Guardian Digital EnGarde Linux User Manual on how to create new users. We can also create users with remote destinations by entering their remote address in the recipient field. To create "bob@acme.com" and have his mail sent to "bob@guardiandigital.com" enter "bob" in the "E-Mail Username" field and "bob@guardiandigital.com" in the "Recipient" field. 4) Now to set up mail routing for the domain "wiley-coyote.org" back out 2 levels of pages and enter the "Mail Routing" link. Enter "wiley-coyote.org" in the "Domain" field and an the mail server "mail.wiley-coyote.org" in the "Relay mail to" field. Follow this by clicking on "Add New" and "wiley-coyote.org" will appear as an "Existing Mail Route" verifying that the new mail relay was created. 5) The mail server configuration for our example is now complete. Our server "smtp.acme.com" will now receive mail for "joe" and store in /var/spool/ mail/joe. It will also receive mail for "bob@acme.com" and forward it to "bob@guardiandigital.com" and it will forward all mail for "wiley-coyote.org" to mail.wiley-coyote.org. NOTE: Obviously to forward mail to "wiley-coyote.org" it would have to receive mail for "wiley-coyote.org". This means that smtp.acme.com would have3 to defined somewhere as a mail server for "wiley-coyote.org". This would most commonly be done through smtp.acme.com being defined via an MX for the "wiley-coyote.org" domain in DNS. ------------------------------------------------------------- VI. UNDER THE HOOD OF THE WEBTOOL MAIL SERVER CONFIGURATION ------------------------------------------------------------- Here is a more behind the scenes look at the Postfix configuration. 1) Aliase Database: ------------------- Almost everything will be done in the /etc/postfix directory. Let's start setting up the "aliases" file. The default aliases file has most of your typical administrative users: postmaster: root bin: root daemon: root games: root ingres: root nobody: root system: root toor: root foo: root falken: root admin: root manager: root dumper: root operator: root . . . root: postfix The above line "postfix" should be changed to a real person to receive root's mail - a most likely candidate would be an administrator type of person. The new line should look like this: root: joe@acme.com In many situations this could be the only change that needs to be made to this file. Once you have finished editing aliases you need to create the aliases.db file by running postalias hash:/etc/postfix/aliases 2) Virtual Domain Database: --------------------------- The next step would be to define the two virtual domains. This is done in the "virtual" map so we will edit /etc/postfix/virtual following the format described above: acme.com ACME.COM VIRTUAL DOMAIN joe@acme.com joe bill@acme.com bill jack@acme.com jack@slacker.com admins@acme.com joe, jack@slacker.com wiley-coyote.org WILEY-COYOTE.ORG VIRTUAL DOMAIN wiley@wiley-coyote.org wiley roadrunner@wiley-coyote.org roadrunner Remember that on the first line of each domain section there needs to be some sort of text field following the domain name, here I used "ACME.COM VIRTUAL DOMAIN". We have just defined the users for acme.com. The local users (the ones where this a just a user name WITHOUT the @domainname suffix) must be local users on this server such as "joe". Any mail sent to "joe" will typically end up in /var/spool/mail/joe. Any mail received by this mail server for user "jack@acme.com" will get forwarded to "jack@slacker.com". Once again, once editing the text file "virtual" has been completed, the database file "virtual.db" must be created with postmap hash:/etc/postfix/virtual 3) Transport Database: ---------------------- You may have noticed that we did not define the virtual domain "wiley-coyote.org". This is because, as stated above, all of the mail received for this domain will be forwarded on to a mail server at wiley-coyote.org. This is defined in the "transport" map and the /etc/postfix/transport text file should look something like this: wiley-coyote.org smtp:mail.wiley-coyote.org .wiley-coyote.org smtp:mail.wiley-coyote.org The first line says that all mail received for "wiley-coyote.org" will be sent to the mail server "mail.wiley-coyote.org" via the "smtp" transport. The "smtp" specifies the postfix "smtp" daemon found in /usr/libexec/postfix directory which utilizes the standard SMTP protocol. This will be the most commonly used transport for most situations. The second line with the "." prepended to it says to send mail addressed to any subdomains of wiley-coyote.org to mail.wiley-coyote.org as well. Since this example is describing a typical real life scenario it is included as more often than not you would want subdomain mail to go to the same top level mail server as the parent domain. If we had multiple domains to forward to we would just simply add an extra two lines to the transport file for each domain: wiley-coyote.org smtp:mail.wiley-coyote.org .wiley-coyote.org smtp:mail.wiley-coyote.org jack-jill.com smtp:smtp.jack-jill.com .jack-jill.com smtp:smtp.jack-jill.com bugsbunny.net smtp:mail.bugsbunny.net .bugsbunny.net smtp:mail.bugsbunny.net Now create the "transport.db" database file with postmap hash:/etc/postfix/transport 4) Main.cf Configuration File: ------------------------------ The last thing to do is to edit /etc/postfix/main.cf file. This is where we tell Postfix about the newly created databases along with other configuration settings. As previously mentioned, there are around 200 parameters that can be set in this file to alter the behaviour of Postfix operation. I will leave most of those to you to explore. The default main.cf that comes with the EnGarde distribution will function just as it is as a workstation mail server. This means that it will handle mail for itself only. This mainly determined by several parameters with their default values being: "myhostname = FQDN of machine as returned by gethostname()" (not explicitly set in main.cf but is implicitly set by its absence) "mydomain = myhostname minus the host portion of the FQDN" (also implicity set by its absence) "mydestination = $myhostname, localhost.$mydomain" If Postfix is serving as just a workstation mail service "mydestin- ation" will be defined as "$myhostname, localhost.$mydomain". "mydestination" defines what addresses will be received locally. Here only mail addressed to the hosts' FQDN (as stated by $myhostname) or "localhost.this-machines-domainname" (as stated by $mydomain) will be received. To change the server from a workstation server to a domain server you would alter "mydestination" to include an additional definition of "$mydomain" to state that it recieves mail for any machine or subdomain of $mydomain and would look like this: "mydestination = $myhostname, localhost.$mydomain, $mydomain" NOTE: Many times a domain server will also have "relay_domains" to include more than just its own domain, which is discussed shortly. The "myorigin = $myhostname" parameter specifies the address that locally posted mail appears to come from. The main.cf also refers to the maps that we have just created with the following lines: alias_maps = hash:/etc/postfix/aliases virtual_maps = hash:/etc/postfix/virtual transport_maps = hash:/etc/postfix/transport The default client restrictions (rules that reject certain client connections) are set to reject any machine that tries to connect via SMTP that doesn't resolve through DNS. smtpd_client_restrictions = reject_unknown_client The SMTP command VRFY is disabled for security reasons: disable_vrfy_command = yes *************************************************** THE FOLLOWING IS A CHANGE THAT MUST BE MADE BY HAND *************************************************** The "relay_domains" parameter states what domains this server will relay mail for. By default this is set to "$mydestination" which represents the local machine's hostname "smtp.acme.com" and "localhost.acme.com". YOU WILL NEED TO ADD ANY DOMAINS DEFINED IN THE VIRTUAL AND TRANSPORT MAPS TO THIS PARAMETER OR MAIL WILL NOT BE RELAYED TO THEM! So for our example the relay_domains parameter in main.cf will look like this: relay_domains = $mydestination, acme.com, wiley-coyote.org Our example is of a top level mail server, meaning that it is the mail gateway that is connected to the Internet by which all mail coming in to and going out of the organization will pass. Therefore no "relayhost" needs to be defined as it delivers mail directly to/from the Internet. If this were an internal mail server it would need to define a "relayhost" to send outgoing mail to. The "relayhost" parameter needs to be set to do this. Although it does not fit this example server many mail servers are not top level servers and this parameter will have to be set to be able to deliver mail properly. Check with your network/mail administrator to determine what would be a suitable server to define for this role. The "relayhost" parameter can either be set to a hostname or an IP address: relayhost = RELAYSERVERNAME OR relayhost = 111.222.333.444 5) Start Postfix: ----------------- Postfix is now ready to go and can be started by running the initscript: /etc/init.d/postfix start It would be a good idea at this point to monitor /var/log/mail.log and verify that Postfix has started without error. You may want to send a couple of test e-mails now and watch the entries as the mail gets delivered. ------------------ VII. MAINTENANCE ------------------ Configuration Maintenance - --------------------------- postconf - lists all of the current parameter settings postconf -d - lists the default postfix configuration as determined by the creator of Postfix - THIS DOES NOT NECESSARLY REFLECT CURRENT SETTINGS! postconf -n - lists the current settings that differ from default settings Daemon Maintenance - -------------------- Starting/Stopping/Restarting the Postfix daemon - ------------------------------------------------- "/etc/init.d/postfix start" "/etc/init.d/postfix stop" "/etc/init.d/postfix restart" Loading new Postfix configurations - ------------------------------------ Loading new Postfix configurations and maps into the currently running "postfix" daemon without restarting can be done by "postfix reload" and upon completion the new configuration will be deployed. Flush the queue - ----------------- To force delivery of every message in the deferred mail queue. Normally, attempts to deliver delayed mail happen at regular intervals, the interval doubling after each failed attempt. /usr/sbin/postfix flush Map Maintenance - ----------------- Creating new maps - ------------------- 1) Edit the text version of the map. 2) For all maps BUT "aliases" create a new map by running: postmap hash:/etc/postfix/MAPNAME For the "aliases" map run: postalias hash:/etc/postfix/aliases 3) Reload the new configuration by one of two methods: 1) "postfix reload" - just reloads new configuration without halting the daemon. 2) "/etc/init.d/postfix restart" - which halts and restarts the postfix daemon with new configuration. Verify map contents: -------------------- Since the actual map database is not readily readable you may need to verify it's contents to see if it actually reflects the text file that it is "supposedly" created from. This can be useful during debug when should you suspect that the text and and the cooresponding database file may not be in sync. postmap -q key map EXAMPLE: [root@demo postfix]# postmap -q linuxseclabs.com transport smtp:orion-t.secure.linuxseclabs.com [root@demo postfix]# Remember that the "aliases" map is a special case and thus has it's own map command "postalias" [root@demo postfix]# postalias -q root aliases pete@guardiandigital.com [root@demo postfix]# Queue Maintenance - ------------------- List queue contents - --------------------- "mailq" lists the mail queue. Each entry shows the queue file ID, message size, arrival time, sender, and the recipients that still need to be delivered. If mail could not be delivered upon the last attempt, the reason for failure is shown. This mode of operation is implemented by connecting to the showq(8) daemon. EXAMPLE: [root@juggernaut postfix]# mailq -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------- BF09A11D315 1125 Mon May 21 14:30:24 vuln-newsletter-admins@linuxsecurity.com (Name service error for ec.ucdb.br: Host not found, try again) SOMEHOST@SOMEDOMAIN.COM Here the "BF09A11D315" is the mail queue identifier which can be used to access this file in the queue. A reason for such access could be to delete the file thus removing it from the queue. View queue files: ----------------- postcat queuefile - prints out in readable form a queue file First you may want to run a "find" command to locate queue files or run "mailq" and run "find" on the returned queueID's: EXAMPLE1: [root@demo ] #find /var/spool/postfix/active -type f active/B/8/B8E7611D302 [root@demo ]# postcat active/B/8/B8E7611D302 to view the contents of B8E7611D302 in the active queue [root@demo ]# mailq -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient----- BF09A11D315 1125 Mon May 21 14:30:24 vuln-newsletter-admins@linuxsecurity.com . . EXAMPLE2: [root@demo ]# find . -name A119611D303 ./deferred/A/1/A119611D303 [root@demo ]# postcat deferred/B/F/BF09A11D315 to view the contents of BF09A11D315 in the deferred queue. Delete file from mail queue - ----------------------------- Should it be desireable to delete a queue file: 1) first determine the queue identifier from "mailq" 2) find /var/spool/postfix -name "IDENTIFIER" -exec rm {} \; 3) run "mailq" to verify the removal. ******************************** *** NEW IN snapshot-20010502 *** ******************************** "postsuper -d queueID" removes queueID from mail queue. A valid reason for such removal could be a space shortage due to an excessive queue population and the queued file(s) has existed for days with an error such as the one above "(Name service error for SOMEHOST@SOMEDOMAIN>COM Host not found,try again)". Such an error over a couple of days during a queue space would warrant a removal. ----------------- VIII. DEBUGGING ----------------- 1) If things are acting strangely here is a simple and quick first step that could save you a lot of time. ************************************************************************ * TO CHECK THE CURRENT CONFIGURATION: * /usr/sbin/postfix check * validates the Postfix mail system configuration and will * warn about bad directory/file ownership or permissions, and * create missing directories. ************************************************************************* 2) In debug mode Postfix will spew out more info than you might ever want so look at /var/log/mail.log to verify that you need more information first. If more information is needed then restart the postfix daemon in "verbose" mode with the "-v" option. To do this you would stop the daemon first: /etc/init.d/postfix stop then start by hand with the "-v" option and put on the reading glasses to view /var/log/mail.log: /usr/sbin/postfix -v start 3) Another cool Postfix debug feature is accessible through 2 configuration parameters: debug_peer_level = 2 debug_peer_list = some.domain The "debug_peer_level" parameter specifies the increment in verbose logging level when an SMTP client or server host name or address matches a pattern in the "debug_peer_list" parameter. The "debug_peer_list" parameter specifies an optional list of domain or network patterns, /file/name patterns or type:name tables. When an SMTP client or server host name or address matches a pattern, increase the verbose logging level by the amount specified in the "debug_peer_level" parameter.