skyBuilders Sendmail Journal

skyBuilders Sendmail Journal

Jesse Burkhardt - begun on 2001/11/07

last modified on 2002/04/18

Introduction:

*	Important: Occasionally when our primary mail server will enter a state whereby the the mailstore service cannot restart. This is usually due to the presence of a lock file generated during a mailstore abend. You must remove this lock file, storemgr.lock, before you can successfully restart the mailstore service:
	$> rm /var/md/store/run/storemgr.lock $> /etc/rc.d/init.d/rc.m-store restart

This document is not very organized, but the purpose of it is to capture as much as I could remember about all that is is the required for the configuration setting for the primary mail server (mail.skybuilders.com) secondary mail server (hosts4.skybuilders.com), and associated setting external to them: individuals' email client programs, DNS records, etc.

*	A related document, skyBuilders Mail Server Backup Method is an extensive document on a cobbling together of linux services that enable cron'ed, NFS'ed, SMB'ed, Sendmail file backup. (This document contains sensitive internal system information and requires a password for viewing.

Primary Sendmail Server Settings:

Presently we are using a third configuration for our SAMS (Sendmail Advanced Message Server) product, called "srg.m4" - named for Steve Glines, who has been very helpful. m4 is the extension used for the sendmail macro engine, see the "MISC" section below. (The original SAMS configuration was based on default.m4. I deployed an intermediate configuration called nuconfig.m4, which was required to re-enable mail forwarding from the various mail domains that we support. The deployment of nuconfig.m4 allowed for the SAMS product to redetect the relevant ether settings that had been applied to the primary mail server. Unfortunately we must treat the forcing of this redetection as a black box for the time being, as the product did not seem be dynamically aware of this change.) I will not name out all the settings in the installation, as they can be seen through the smadmin console interface, but will mention the most important settings:

The /etc/mail/relay-domains file must have entries for 64.226.242.104 (skybuilders.com at Interland), 63.209.229.198 (the Toshiba site monitor), and 199.103.162.[*] (the entire Verio D class) This allows us all use mail server (mail.skybiolders.com) as an SMTP relay for our outbound mail. This also allows us to disable SMTP from our own office machines for security purposes - in effect, making the mail server an SMTP proxy for us inhouse.

In the Sendmail Advanced Message Server - SAMS - interface this file accessed through the skyBuilders Sendmail Admin console. Click on the "Edit Existing Configuration" link; then select the "srg.m4" configuration; hit the "Load" button and select the "Relay Access Control" link under the "Anti-Spam Control" section.

Additionally, apart from making relay-domains entries, it is necessary to make entries in the /etc/mail/access file if we want to give special SMTP access to users who have accounts in mail domains we support. When domain entries are given the "OK" setting users with accounts in approved domains can use the SMTP services of the primary skyBuilders mail server. This is a bit confusing since one would think that using the RELAY setting would accomplish this, though it, in fact, does not. I excerpt from the SAMS online documentation:

The following is a list of acceptable values for the right-hand side of the access database:

OK Accept email even if other rules in the current rule set would reject it
RELAY Allow domain to relay through your server
REJECT Reject sender/recipient with a message
DISCARD Discard the message using $#discard mailer

(In the Sendmail Advanced Message Server - SAMS - interface this file accessed through the skyBuilders Sendmail Admin console. Click on the "Edit Existing Configuration" link; then select the "srg.m4" configuration; hit the "Load" button and select the "Anti-Spam Control" link.)

Other settings such as that for promiscuous relaying must be disabled. After all, we don't want to help the spammers of the world propagate their trash through wide open relays.

SMTP Settings on skyBuilders Web Servers:

This ban on open relaying applies equally for the defaul SMTP settings on all our web servers, which use SMTP to send mail concerning bug reports originating from skyBuilders timeLines installations to those of us who support those installations. On the Windows 2000 based IIS web servers make settings by openning the MS Windows 2000 IIS Manger utility:

Click Start > Programs > Aministrative Tools > Internet Services Manager, yielding the following interface:

Then right click the Default SMTP Virtual Server entry (underlined above) yielding:

In the resulting Default SMTP Virtual Server Propoerties display select the Access tab and click the Relay button, yielding:

Select the top radio button saying, "Only the list below", and click OK. Make sure the "list below" has no entries, as is shown in the illustration, as this effectively blocks everything from relaying. Also click OK to close the Default SMTP Virtual Server Propoerties display. (Not clicking OK may result in these settings not being saved.)

This process now completes the process of relay blocking the web server's SMTP service. The web server still retains the ability to send emails from the websites inhabiting it.

Client IMAP and SMTP settings:

People who want to connect to mail domains that we support certainly must have their own email client's inbound IMAP connection set to point at mail.skybuilders.com to read their domain specfic email. (A user may refer to his own domain, for example, mail.dtvgroup.com, provided an MX record exists in the dtvgroup.com DNS entry, and the accompanying A record in the skybuilders.com entry, in the DNS server exists.) To send email users may point their SMTP server settings to the skyBuilders SMTP server mail subdomain, using the same settings for both outbound and inbound mail server settings.

This assumes that the domain supported by skyBuilders appears as an entry the in the /etc/mail/realy-domains table of our primary mail server. Should our policy allowing certain domains to relay become more restrictive then such users may have to set their SMTP mail server settings to that of their connectivity provider. For instance:

for Mediaone use the SMTP (outbound) connection to smtp.ne.mediaone.net
for Speakeasy its is mail.speakeasy.net
for Charter it is smtp.charter.net

*	For more on this visit my detailed document for setting up Netscape Messenger client email access.

MISC:

Force the attempted delivery of mail (as root) with the command "/usr/lib/sendmail -v -q". This flushes the contents of the mail queue, at /var/spool/mqueue on the fallback mail server.
To make the sendmail.cf file using the sendmail macro engine:

m4 /etc/mail/sendmail.mc > /etc/sendmail.cf
Before doing that make sure that the relay-based-on-MX feature is turned on in the macro file (/etc/mail/sendmail.mc): remove the leading "dnl " from the line "dnl FEATURE('relay-based-on-MX')dnl" and turn off the feature "FEATURE('accept-mail-from-unresolvable-domains')dnl" by prepending a leading "dnl " to the line.
On the fallback mail server it is a good idea to edit the line in the /etc/sendmail.cf file referring to the your domain name (the 4th configurable item) by adding "Djhosts4.skybuilders.com". Note that this edit dovetails with all the secondary MX records associated with each of our mail domains in our DNS server records. In other words, the MX record for dtvgroup.com is mail.dtvgroup.com (with a priority of 10), the fallback mail server MX record is hosts4.skybuilders.com (priority 30). This setting ensures that Sendmail associates the DNS IP address bound the hostname "hosts4" regardless of actual hostname bound to the fallback mail server, which in this case uses skyVA-L2. (Believe me this setting is crucial and not knowing about it initially cost me much setup time.):
************** * * * local info * * * ************** # my official domain name # Dj$w.Foo.COM Djhosts4.skybuilders.com
Also, on the fallback mail server the IP address of our Site Monster monitor (63.209.229.198) must be entered into the /etc/mail/relay-domains file so that the mail alerts originating from it get stacked into the fallback mail queue.

Interactive Sendmail Telnet sessions:

This allows you to conduct tests for debugging your Sendmail configurations without relying on launching tests from 3rd party email providers, whose own configuration may block the behavior you want to test: For instance, in checking for the functionality of a fallback mail server, whose mail queue (/var/spool/mqueue) should catch email when your primary mail server is down, you may knock down your primary send yourself email from an ISP email account, but you may not see the message appear in the fallback mail server's queue. Although this is undoubtably because of a DNS or Sendmail config error on your side, it may take time to figure this out. The ISP's email config may try to resend the message after the first failure, in which case the message may appear on your primary after you restart its Sendmail daemon.

The desirable scenerio is to watch results immediately and this is best done with an interactive Sendmail session using telnet on port 25 (the SMTP port). The responses shown by "hosts4>" in what follows are approximate in their reply content.

*	The following interactive SMTP session illustration, using port 25 through telnet, reflects Unix/Linux based behavior. I have not been able to initiate a MS Windows SMTP server session successfully.

You> telnet hosts4.skybuilders.com 25

You> HELO hosts4.skybuilders.com <RET>

hosts4> [Response] Pleased to meet you root@skySpec-L3.skybuilders.com ...

You> MAIL from:root@skySpec-L3.skybuilders.com <RET>

hosts4> ... sender OK

You> RCPT to:jesse@skybuilders.com <RET>

hosts4> ... recipient OK

You> DATA <RET>

hosts4> Enter mail, end with "." on a line by itself

You> This is my message <RET>

You> . <RET>

hosts4> Message accepted for delivery

You> QUIT

[Session is now terminated.]

Major Caveat with MX Records:

"... most mailers only look for their loca hosts's canonical domain name in the list of MX records. They don't check for aliases (domain names on the left side of CNAME records). ... there's no guarantee that a mailer will be able find itself in the MX list, and you'll run the risk of having your mai loop." - DNS and BIND, 4th ed., p. 99

I have tried this inadvertantly and can assert that mail queue backup storage and delivery will fail when using a CNAME instead of an A record for an MX reference.

Edit

Language: fr | it | de | es | pt | ar | he | da | nl | zh | ja | ko | none

skyCalendar

This Version:
Archived at: https://www.skybuilders.com/Users/Jesse/Docs/sendmailJournal.20020327215113.html

Requests

Version: 2554 | Series: 3586