--- /dev/null
+Date: Wed, 22 Nov 2000 17:51:42 -0500 (EST)
+From: Dave C. <djc@microwave.com>
+
+Ok.. Ive come up with something which might be worth including in the
+cookbook. Credit where it is due, the idea for this came from Nigel's
+C014..
+
+I have a setup to support ETRN for a few small (ok, two) domains.
+Currently it just leaves all the mail in the exim spool, and uses the
+default exim etrn response to flush it out.
+
+I don't like that - I agree with the opinion expressed on the list that
+mail should be delivered somewhere else, and then shoved down an SMTP
+session by some other program. Ive searched far and wide for something
+suitable to do that shoving, and finally hit upon the only program I
+trust to do that, handling errors and rejections correctly - exim
+itself.
+
+Nigel's solution for 'situation where a site I MX for has a known
+outage', combined with a bit of bash scriptery, seems to form a neat
+solution. (An intermittently connected host sort of falls under the
+'known outage' category ;)
+
+Without any further fluff, here are the details. Additional comments
+appear below..
+
+Either the real (intermittently connected) destination host needs to be
+listed as the lowest MX (with the exim server as a less preferred) , or
+the exim server needs to be the lowest MX, but have a router before the
+lookuphost router which uses route_list or something appropriate to
+normally deliver mail to the dialup host. The former is probably better
+for a host which is usually connected and is only occasionally
+disconnected (since other hosts would be able to delivery directly most
+of the time, skipping an extra relay), while the latter would probably
+work better for the converse ;) This paragraph actually applies anytime
+you are using ETRN..
+
+In either case, the routers below must precede whatever router handles
+the normal direct-to-dialup-destination..
+
+--
+
+smtp_etrn_command = /etc/exim/etrn_script $domain
+
+[- Content of /etc/exim/etrn_script: -]
+#!/bin/sh
+
+# Where exim lives
+EXIM=/usr/sbin/exim
+
+# Something appropriate to generate a temporary unique string
+UNIQ=`head -c100 /dev/urandom | md5sum | cut -f 1 -d" "`
+
+arg=$1
+domain=`echo $arg | sed 's/^\#//g'`
+
+if ( test -f /var/spool/etrn/${domain} ); then
+ exim_lock -q /var/spool/etrn/${domain} "mv /var/spool/etrn/${domain} /tmp/etrn-bsmtp-${UNIQ}"
+ ( cat /tmp/etrn-bsmtp-${UNIQ}
+ echo "QUIT" ) | $EXIM -bS -oMr etrn_requeue
+ rm -f /tmp/etrn-bsmtp-${UNIQ}
+fi
+
+$EXIM -R $domain
+
+# If you use smtp_etrn_serialize, the following ensures that the
+# serialize hint is removed for the argument exactly as specified by
+# the client (which might have an # prepended if they are issuing an
+# ETRN argument as required by exim's default ETRN support
+
+$EXIM -R $arg
+
+[- end of etrn_script -]
+
+[- exim transport -]
+
+bsmtp_for_etrn:
+ driver=appendfile
+ file=/var/spool/etrn/${domain}
+ user=exim
+ bsmtp=domain
+ check_string = "."
+ escape_string = ".."
+ prefix = ""
+ suffix = ""
+
+[- routers -]
+[- You probably would want to put the domains in a file or a dbm and
+[- adjused the 'domains' setting appropriately for both of these..
+
+# If any message has already been delivered to the bsmtp file,
+# this will detect the existence of the file and all messages will
+# go there, regardless of age..
+etrn_already:
+ driver = domainlist
+ transport = bsmtp_for_etrn
+ require_files = /var/spool/etrn/${domain}
+ domains = etrntest.somedomain.com
+ route_list = *
+
+# If a message has been on the queue for over the specified amount of
+# time, this will catch it and drop it into the bsmtp file
+etrn_delay:
+ driver = domainlist
+ transport = bsmtp_for_etrn
+ condition = "${if >{$message_age}{1800} {yes}{no}}"
+ domains = etrntest.somedomain.com
+ route_list = *
+
+[- -]
+
+Basically, this setup lets exim try to deliver to the real host for up
+to whatever time is specified in the etrn_delay router. (1800 seconds =
+30 minutes), and then delivers all waiting messages, and any further
+messages, directly to a bsmtp file.. This setup uses one big BSMTP
+file, it probably wouldnt be too complex to have it use seperate
+files..
+
+When the etrn_script runs, it locks and renames the bsmtp file, and
+reinjects the messages to exim, which (presumably) will now be able to
+deliver them. If it can't, then once they are too old they will again
+be sent off to the bsmtp file.. (If for som reason this occurs over and
+over without exim being able to deliver them, eventually the messages
+will be returned with "too many Received headers"; this is a good
+thing, since their age will never get high enough for them to be
+returned by any retry rules)
git://git.exim.org / exim-website.git / blobdiff