Ticket #959 (new defect)

Opened 13 years ago

Last modified 12 years ago

debathena-msmtp ought to queue

Reported by: geofft Owned by:
Priority: low Milestone: The Distant Future
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:


I got this a couple of times tonight, and I'm pretty sure I wasn't the only one:

msmtp: envelope from address geofft@mit.edu not accepted by the server
msmtp: server message: 451 4.3.2 Please try again later
msmtp: could not send mail

Completely failing to send mail isn't cool, because automated scripts can't retry on their own. The MTA should retry for a bit.

Unfortunately, this is right next to impossible since you also want to send mail with Kerberos tickets. You could settle for attempting, and queueing for without tickets if that doesn't work. Or for attempting, and remembering KRB5CCNAME, and queuing for without tickets if it's gone by the time you can send.

Change History

comment:1 Changed 13 years ago by andersk

A typical user almost certainly doesn’t want this, because they want to see any sending errors immediately rather than having their messages silently dropped four days later. If you want a queuing MTA, you should go install one—any reason not to close this as a duplicate of #799?

comment:2 Changed 12 years ago by geofft

There's some discussion on debian-devel about  dma:

In a nutshell: it's able to deliver locally and remotely, has a queue, supports TLS/SSL, does not listen on port 25 and instead of running as daemon, it if run every 5 minutes via cron to flush the queue. Maybe it could be changed to use incron and not cron on Linux. It's README.Debian contains more verbose information.

Note: See TracTickets for help on using tickets.