Bug#652731: Fwd: Bug#652731: ITP: extsmail -- enables the robust sending of e-mail to external commands.

[Laurence Tratt]

> What makes it robust? What happens if the external command fails?

The command is retried (with a delay) until it succeeds. For example the
second scenario on 
shows how this can be utilised to achieve fallover between servers.

> How is failure detected?

The exit code of the command run. e.g. if using ssh, exit code != 0 indicates
failure (and a presumption that mail delivery was unsuccessful). extsmail
goes out of its way to detect a number of other unlikely failures (resources
temporarily unavailable etc.). It should never lose mail. The only condition
it can't recover from is a lack of memory (and given that even on a 64 bit
machine it takes well under a Mb of memory, this is not hugely likely to
happen) whereupon it will simply exit (unsent mail will remain unsent until
extsmail is restarted).

I welcome code audits, particularly of the "core" of extsmail which is the
mail sending daemon:

  https://github.com/ltratt/extsmail/blob/master/extsmaild.c


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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111220185642.ga7...@overdrive.tratt.net

Bug#652731: Fwd: Bug#652731: ITP: extsmail -- enables the robust sending of e-mail to external commands.

[Laurence Tratt]

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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111220221614.ga28...@overdrive.tratt.net