On Tue, Dec 20, 2011 at 10:39:52PM +0100, martin f krafft wrote: Dear Martin,
> The description of the package should answer my questions concisely. Equally, others might reasonably say that words are just words. One may always inspect the source to truly satisfy oneself. > Also, to run something ad infinitum until it succeeds might not be the > wisest choice as it could mean that it *never* completes. Of course. But equally well, you don't know if doing it just one more time will succeed. There is no perfect answer that will work for all cases for all users. Users can inspect the logs (or the spool dir) if they want to see if mail has not yet been sent. > What happens if someone tries to send 4Gb of mail? That depends entirely on the behaviour of the sendmail process on the remote machine. extsmail is, more or less, a "proxy" in that sense - extsmail does not, and can not, know the policies of the remote sendmail. That remote sendmail process might send an e-mail complaining to the user, for example. > So it maintains a mail queue? Yes. One message per file (and appropriate file locking of course). It's very simple. > What if the filesystem fills up? The local extsmail program (masquerading as sendmail) throws an error if it is unable to write a message to the spool directory, much as the local sendmail binary might. There is no other reasonable behaviour. > How does it prevent double-sending? As with any other mail system, it doesn't and can't. It is always possible that a message is sent but (say) a network dies at just the wrong point for it to be confirmed that the message has been sent. The most important thing is to ensure that e-mails are always sent at least once. I should note that I have not yet encountered an instance of double-sending in the 3+ years I've been using extsmail - it would take a rare combination of events. Laurie -- Personal http://tratt.net/laurie/ The Converge programming language http://convergepl.org/ https://github.com/ltratt http://twitter.com/laurencetratt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
