Hi, On Thu, Mar 29, 2007 at 01:31:12PM +0200, Adam Groszer wrote: > I'm trying to catch somehow the exception that's coming when the SMTP > server IP address is misconfigured or the SMTP server is not > responding. > > My problem is that the sending works using the transaction manager. > That means the exception comes after > File "U:\zope\svn_zope33\src\zope\publisher\publish.py", line 138, in > publish > publication.afterCall(request, obj) > File "U:\zope\svn_zope33\src\zope\app\publication\browser.py", line 78, in > afterCall > super(BrowserPublication, self).afterCall(request, ob) > File "U:\zope\svn_zope33\src\zope\app\publication\zopepublication.py", line > 167, in afterCall > txn.commit() > That means I don't have a big chance to catch it in my app.
That's a feature. You don't want to send emails about changes made in
transactions that were later aborted. In particular, when you encounter
ZODB ConflictErrors a couple of times, you don't want three copies of
the same email to be sent.
Unfortunately, that means the actual sending must be done in the second
phase of the two-phase commit, and it is not supposed to ever fail at
that point. That makes directDelivery unsuitable for production use.
> Using queuedDelivery might be a solution, but I still don't have too
> many chances to give feedback of the error.
>
> There is a IMailErrorEvent, and IMailSentEvent but they don't seem to
> be used.
Ouch. I do not remember why the events were never fully implemented.
> Obviously they would be fired in the middle of tpc_finish.
Sending events is the same as running arbitrary code. That's a bad
thing to do during transaction commit. There was some discussion (years
ago) that the transaction mechanism should acquire a way to register
some callback for code that should be run in a new transaction, after
the current one is committed. I do not remember how that discussion
ended.
> Any ideas, pointers?
zope.sendmail could use some loving care and attention. For example,
the queued delivery thread will loop forever trying to deliver a message
with an ill-formed recipient address once every three seconds.
In the meantime, this seems to work adequately: use queuedDelivery, and
send a test message after depoying the application. If it doesn't come
through, check the error logs.
Note also that if the nearest SMTP server accepts an email, that does
not guarantee delivery. We've hooked up incoming mail to a bounce
message processor in one of our Zope 3 apps that matches message IDs in
bounce messages with IDs of sent emails and can take appropriate action.
Marius Gedminas
--
I would suggest re-naming "rmbdd()". I _assume_ that "dd" stands for "data
dependent", but quite frankly, "rmbdd" looks like the standard IBM "we
lost every vowel ever invented" kind of assembly lanaguage to me.
-- Linus Torvalds
signature.asc
Description: Digital signature
_______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
