more on mail queue lossage
Raul:
> I think the simplest way of dealing with messages in flight across
> mail transport agent changes would be to define a simple queue
> structure to hold the messages across mta installations.
It's true that an MTA change is currently difficult to do correctly.
I recently did this for chiark (which handles about 20,000 deliveries
a week). I installed Exim (the new MTA) with --force-conflicts, and
fixed up the /usr/sbin/... links by hand to point to Smail. I ran
Exim for testing for a week on a different IP address, with both it
and Smail delivering to local mailboxes. Then I switched the main
SMTP reception and /usr/sbin/sendmail to Exim, leaving Smail to
deliver its queue. Smail had some messages it had wedged on, and I
got it to deliver them to `localhost' as a smarthost (and turned
Exim's verification off for messages from localhost). Then I removed
Smail, and redid dpkg --install exim for good measure.
How much effort do we want to do to make this easy and working ?
Getting it right will be _hard_, even if we don't want to allow
parallel running.
> Policy should be that a mail transport agent postrm should move any
> undelivered mail messages into this queue with this format and that
> the postinst should move messages from this queue to the new mta's
> queue. ssmtp would require special effort (either refuse to install
> using a check in preinst or a queue run job which checks the error
> code from /usr/sbin/sendmail). An mta shouldn't be considered
> installed until all messages have been succefully moved out of this
> temporary queue (technically, it's ok if unreasonable messages get
> bounced, and this should be considered a success).
This would be a reasonable way to go about things.
> Probably the simplest mechanism is a directory with one file
> per message, first line being envelope from address, subsequent
> line(s) being destination address(es), then a blank line, then
> the message (headers and all).
Please can we use batched SMTP ? Both Smail (the current recommended
MTA) and Exim (the one we'll probably be recommending eventually)
support this for input and output.
Ian.
--
E-mail the word "unsubscribe" to debian-policy-request@lists.debian.org
TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to listmaster@lists.debian.org
Reply to: