A problem with small sites that use a dial on demand PPP connection to connect to the Internet is that every time sendmail performs a DNS query, it brings up the PPP connection. If a site has several users so an email message is sent every few minutes this will keep the dial on demand connection up all of the time.

A new queue mode, delay, was introduced in sendmail 8.7 to prevent this problem. In the delay queue mode, the message is put into the sendmail mqueue without any DNS lookups. The DNS lookups occur when the queue is run by the sendmail queue daemon. The benefit of this mode is that sendmail still uses DNS to resolve hostname and address information, only the initial lookups are delayed.

You change to this mode with:

	O DeliveryMode=delay

in the sendmail.cf file, or:

in a host.mc file.

Having just looked at DNS debugging (-d8.8) the above is not strictly true. Sendmail still does an initial set of queries when it starts up for the local hostname. This is because the query is done before the sendmail.cf file is read. For the sendmail daemon this is not a big deal, you get the queries when the daemon first starts up, but not for each message. For a user agent on the UNIX host that invokes sendmail this is a problem. Each time a user sends a message, the user agent invokes sendmail which will make queries of the local domain. Assuming that the host is a SMTP relay and needs to use DNS, the solution is to run a local name server (named). This could be either a caching name server or it could be primary or secondary for the local domain. With the caching name server the first query would still bring up a connection but all subsequent queries would be answered from the named cache until the time to live (TTL) expires, and then the query would be made again.

Another thing you may want to add is to set the DialDelay option. This was introduced for dial on demand connections. If the SMTP connection fails, sendmail will retry the connection. This allows the PPP connection to be established by the first connect request, and used by the second connection request.

You change to this mode with:

	O DialDelay=10s

in the sendmail.cf file, or:

in a host.mc file.

There is a gotcha with this option. This delay is used for *ALL* failed SMTP connection requests including local LAN connections, not just dial-out PPP connections. On a small net with a single POP server this will not be a problem. On a complex sendmail SMTP relay where the dial-up connection is just one of many network connections, This may introduce an unacceptable delay on timing out the connection to a host such as a low preference MX host on the other side of a firewall.

The third thing you might want to change is the sendmail queue daemon (-q15m). The queue daemon controls how often sendmail will bring up a PPP connection to deliver mail. If you want sendmail to only bring up a connection once an hour, you would use a value of -q1h.

A better way to do this is to run the queue daemon out of cron. The benefit of using cron is that you can follow the sendmail command with a program that issues a SMTP ETRN command to your ISP's SMTP server. If the ISP is using sendmail 8.8 the ETRN command will cause their server to process its queue that is waiting for you (basicly "sendmail -qRcustomer.dom"). The etrn.pl perl script which is in the contrib directory of the sendmail release will issue the ETRN command for you. Mail sent to your domain while your PPP connection is down will be delivered and queued on your ISP's server because they are a higher preference MX record holder for your domain.

In your cron file add:

	0 * * * * /usr/lib/sendmail -q >/dev/null 2>&1
	1 * * * * /usr/local/bin/etrn.pl smtprelay.isp.net >/dev/null 2>&1

Which will run the sendmail and etrn.pl command every hour.

You might also want to differs the frequency of polling based on time of day: business hours every 15 minutes, off hours once an hour.

A different way would be to do sendmail -q and etrn.pl in your PPP chat script. This would have the benifit of checking your ISP's sendmail server for mail waiting to be delivered every time you bring up your ppp connection. You would probably also still want to have the cron entrires so you will poll for incoming mail, even if everybody is out of the office. Maybe poll every three hours.

A note for ISP's with dial on demand customers using SMTP. You might want to lighten up the load on your sendmail server a bit by queuing the mail for your dial on demand customers rather than trying to send it. If things are setup correctly the only time your SMTP relay should get a message to be relayed to the customer is when the PPP connection is down. If the connection was up then the SMTP client would connect directly to the customer's SMTP server.

You could simply change your delivery mode to queue mode. A better solution would be use the "expensive" mailer flag, "e", with a custom SMTP mailer definition in the sendmail.cf file.

Using M4 to generate a sendmail.cf file you would define the mailer with:

	LOCAL_RULESETS
	# The qsmtp mailer is a standard ESMTP mailer with the "expensive"
	#       mailer flag, "e", set.  It is for dial on demand dedicated PPP
	#       SMTP clients.
	# Harker Systems, www.harker.com, info at harker dot com, 408-295-6239
	Mqsmtp,		P=[IPC], F=mDFMuXae, S=11/31, R=21, E=\r\n, L=990,
			T=DNS/RFC822/SMTP,
			A=IPC $h

If you use the allmasquerade feature the recipient ruleset definition would be R=21/31 (The ftp M4 template below handles this automatically)

You also need to set the HoldExpensive option in to use the expensive mailer flag. Set it to true with:

To queue mail for your dial on demand customers you would define a class, $={CustDoms}, of the domains of your dial on demand customers.

	LOCAL_CONFIG
	# Class $={CustDoms} is for customer domains which should be queue for
	#   later delivery which is triggered by customer sending
	#   us an ETRN command when they bring up their PPP connection
	# Harker Systems, www.harker.com, info at harker dot com, 408-295-6239
	C{CustDoms} cust1.dom cust2.dom
	F{CustDoms} -o /etc/mail/CustDoms

Finally you need to add some rules to ruleset S0 to deliver mail for the customer's domains via the new qsmtp mailer:

	LOCAL_RULE_0
	# Deliver mail to customer domains, $={CustDoms}, using custom qsmtp
	R$* <@ $={CustDoms}.> $*		$#qsmtp $@$2 $:$1 <@$2> $3
	R$* <@ $+.$={CustDoms}.> $*		$#qsmtp $@$2.$3 $:$1 <@$2.$3> $4

Allowing relaying for the domains of your dial on demand customers

The significant new feature of sendmail 8.9 is the predefined check_* rulesets that turn off SMTP relaying by default. Before your dial on demand customers can use you as an inbound SMTP relay, you will need to re-enable relaying for their domain. There are several ways to do this. One of the simpler ways to do this is with the sendmail 8.9 feature relay_entire_domain.

	FEATURE(relay_entire_domain)

The relay_entire_domain feature will allow relaying for all domains in class $=m as well as all hostnames ending with domains in class $=m. By default class $=m is initialized with the domain of the sendmail relay itself.

To allow relaying for your dial on demand customers you would simply add the domains in class $={CustDoms} to class $=m. This would be done by using the previous C{CustDoms} and F{CustDoms} lines and replacing {CustDoms} with m

	LOCAL_CONFIG
	# Adding dial on demand domains to class $=m to allow relaying
	#    for our dial on demand customers
	Cm cust1.dom cust2.dom
	Fm -o /etc/mail/CustDoms

(The ftp M4 template below handles this automatically)

Adding these changes to a sendmail.cf file using M4

To add these features to a sendmail.cf file using M4 you could either add these lines directly to your host.mc file or you could add it as a M4 template file.

If you add these lines directly to your host.mc file, you would simply pick and stuff the lines with you mouse. Be careful about makeing sure the two fields in the sendmail "R" rule lines in LOCAL_RULE_0 are separated by tabs.

To add it as a M4 macro file a M4 file would be created. This file would contain all of the above rules as well as a VERSIONID(filename) line to add a comment in the sendmail.cf file with the name of the file. Depending if you were going to add it as a M4 HACK or FEATURE the file would be called:

	feature/smtpdemanddial.m4
or	hack/smtpdemanddial.m4 

In your host.mc file

This template would be included in your sendmail.cf file by including:

	FEATURE(smtpdemanddial)
or	HACK(smtpdemanddial)

in your host.mc file.

A copy of an M4 template with these definitions in it can be found at ftp://ftp.harker.com/pub/sendmail/cf/smtpdemanddial.m4

This M4 template also defines the M4 macros: confDIALDEMANDDOMAIN, confDIALDEMANDDOMAINFILE and QSMTP_MAILER_ARGS.

confDIALDEMANDDOMAIN adds domains to class $={CustDoms} and class $=m using a C class line, the C{CustDoms} and Cm lines above. By default it is not defined and the C{CustDoms} and Cm lines are not added.

To add cust1.dom and cust2.dom using C lines, you would add:

to your host.mc file.

confDIALDEMANDDOMAINFILE defines the file name to be used in the F class lines, the F{CustDoms} and Fm lines above. By default it is defined as -o /etc/mail/CustDoms.

To change the file used in the F lines, you would add:

to your host.mc file.

QSMTP_MAILER_ARGS allows you to add aditional mailer flags to the qsmtp mailer and works like the standard sendmail SMTP_MAILER_ARGS M4 macro. By default is it not defined.

The qsmtp mailer also uses the standard sendmail SMTP_MAILER_FLAGS, SMTP_MAILER_MAX and SMTP_MAILER_CHARS M4 macros.