[Zope-dev] zope.sendmail and critical transaction errors.

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Laurence Rowe wrote:
> With Zope2's MailHost now using zope.sendmail, we're seeing some
> critical errors when sending mail when the mail server domain name is
> misconfigured. http://dev.plone.org/plone/ticket/10675 (these are
> triggered by a password reset mail, the registration mail is sent
> immediately).
> 
> This is because zope.sendmail.delivery.MailDataManager sends mail in
> tpc_finish when using DirectMailDelivery. While MailDataManager makes
> sense for QueuedMailDelivery (msg.commit should never fail) for
> DirectMailDelivery it seems wrong.
> 
> To fix this, DirectMailDelivery should use a commit hook - there are
> two options:
> 
> * After Commit Hook
> 
>   Ensures mail is only sent once in event of a request being retried,
> but errors are swallowed so no feedback that there is a problem to the
> browser.
> 
> * Before Commit Hook
> 
>   Mail me be sent multiple times in event of a request being retried
> due to a conflict error, but errors propagate to the browser.
> 
> 
> I think the Before Commit Hook option is probably best here.
> DirectMailDelivery should only be used for testing anyway, or at least
> only on very small sites in production - QueuedMailDelivery will scale
> better.
> 
> For Zope 2.12 / Plone 4.0 we have the additional problem that Zope
> 2.12 is incompatible with zope.sendmail 3.7.x / trunk due to a
> zope.component 3.8 dependency. I think this issue is serious enough to
> warrant backporting this fix to the zope.sendmail 3.6.x branch.
> 
> 
> Patches attached for comment.

- -sys.maxint to changing the mail delivery to a non-transactional form.
Switching to a before commit hook is the *worst* of the optoins:  it
defeats the whole point of using zope.sendmail in the first place, which
was to avoidi multiple e-mails on retried requests:  if the application
doesn't want the mail to be transactional, then it should just send it
immediately (which is what the MailHost used to do).  At that point, the
user would get an error screen, which couold only be cleared by the
admin fixing the mail configuration.

The misconfiguration of the mail host in transactional mode *does* cause
the server to go into a "lockdown" mode (because errors are not supposed
to be raised in 'tpc_finish').  There is *no* database corruption, but
the transaction manager can't know that, and so it deliberately refuses
to commit more transactions until the admin un-futzes the problem (in
this case, by fixing the mailhost configuration) and restarts the server.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkwiJk4ACgkQ+gerLs4ltQ4VnQCeNdJCHQojfrBQymejpM/WT7YN
s+EAn1XY2ju5B1taLMax8cx4BUBHcR3A
=cgaT
-----END PGP SIGNATURE-----