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
Description: Digital signature
_______________________________________________ Zope3-dev mailing list Zope3email@example.com Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com