Hack 50 Hold Email for Later Delivery
|
Control when sendmail uses an intermittent Internet connection. The default sendmail configuration assumes that you have a constant network connection. What if you're on a dial-up system and want to be able to work on emails without causing your modem to dial up immediately? In this scenario, you want to queue your sent messages to send later, the next time you go online. 5.10.1 Configuring sendmail QueueingFortunately, sendmail has a "hold expensive" function designed for this purpose. To activate it, add the following lines to the /etc/mail/<hostname>.mc file: define(`confCON_EXPENSIVE', `True')dnl MODIFY_MAILER_FLAGS(`RELAY', `+e')dnl MODIFY_MAILER_FLAGS(`SMTP', `+e')dnl MODIFY_MAILER_FLAGS(`ESMTP', `+e')dnl MODIFY_MAILER_FLAGS(`SMTP8', `+e')dnl define(`confTO_QUEUEWARN', `12h')dnl The first line enables the feature. The next four lines add the letter e to the flags for each named mailer, to indicate that it is "expensive" and that email should first be queued rather than immediately delivered. The last line just extends the length of time the system will wait before it warns you that your message hasn't been delivered yet (the default is four hours). Now just build the configuration file, install it, and restart sendmail as usual: # cd /etc/mail # make # make install # make restart-mta The four mailers listed (RELAY, SMTP, ESMTP, and SMTP8) will handle the bulk of all transmissions over the network. The configuration of both local and remote mail systems will determine which one to use. However, if you send out all of your mail via your provider's smart host, the RELAY mailer is the best choice. So far so good. However, you still need to make some more changes to the way sendmail runs. Queued messages will sit in the mail queue (/var/spool/mqueue) until the next sendmail queue run. These occur every 30 minutes when using the default sendmail command-line flags. The following settings in /etc/rc.conf will suppress that default: sendmail_enable="NO" sendmail_submit_flags="-L sm-mta -bd -ODaemonPortOptions=Addr=localhost" Note the deletion of -q30m from the default value of sendmail_submit_flags. Those lines assume that you don't want a sendmail process listening on port 25 on your network interface for incoming emails, which can be problematic on a transient link, such as dial-up. (See [Hack #49] for an alternate approach.) 5.10.2 Configuring PPPHaving effectively prevented the system from ever flushing the mail queue, you'll now need to add a mechanism for sending all queued email when the PPP link activates. If you're running the user land ppp daemon, create /etc/ppp/ppp.linkup with these contents: papchap: !bg /usr/sbin/sendmail -q /etc/ppp/ppp.linkup should be owned by the root user and the wheel group, and be writable only by root, although it can be readable by all. Alternatively, add the line /usr/sbin/sendmail -q to an existing auth-up file. (pppd uses the shell script /etc/ppp/auth-up to run commands after the link has come up and the systems have authenticated successfully.)
5.10.3 Dealing with DNSThere is a huge gotcha in this whole discussion. sendmail makes extensive use of the DNS while it processes email. That DNS traffic will usually trigger on-demand dialing, and bringing up the PPP link triggering an immediate queue flush defeats the whole purpose of what you've done so far. There are several things you can do to ameliorate this problem:
This last option tells sendmail not to look up MX records, which are available only from DNS; instead, it will only look up IP numbers. For example, specify your ISP's SMTP server's hostname in this line of /etc/mail/<hostname>.mc: define(`SMART_HOST', `[smtp.example.com]')dnl Then, rebuild the configuration file as before. Note that these hacks will only mitigate the DNS problem. Unfortunately, it is all but impossible to eliminate inconvenient DNS lookups. 5.10.4 See Also
|
