On Wed, May 31, 2000 at 04:54:24PM +0100, Simon Coles wrote:
The problem we are trying to solve is basically being to email "something@myserver.me.com" and that email ends up in the Zope ZODB processed in whatever way is appropriate.
I've been thinking about this too, reached more or less the same conclusions, and decided not to work on it because I'm already lame enought on keeping up with the hundreds of stuff I _am_ working on :-) Anyway:
Most MTAs can be setup to pass an email to the stdin of a program. Sendmail will do this, and Exim (http://www.exim.org/) will also pay attention to what that program returns and queue the message for re-try later if it fails. So using Exim, we don't have to get into any messy stuff about queuing mails if the Zope server is down.
This is probably the best solution, but don't forget virtual hosting: the method for deciding which method to call should include the whole address (not only the username) and turn up something similar to the rules used by zmailer or qmail. The problem here is that most MTAs don't pass the whole envelope address to such a "piped" program. As zmailer is mostly scripted, I figured it would probably be the best/easier solution, check it out. (Plus, it starts with Z ;-) hehehe)
Some alternatives we considered and didn't go for: - write something in Zope to listen for SMTP connections, effectively large portions of an MTA. This would be cool but painful.
Agreed on both cool and painful. Perhaps the best solution in the long run, but we need a ZODB more friendly to high-writing first, I think.
- pull mail from a POP or IMAP server. This had the downside that it introduced polling into the system (slow) and also required something to happen on a schedule, which doesn't happen in Zope yet.
I don't see advantages to this approach.
- This program takes the email message and puts it into Zope, probably by calling a DTML Method or something. This would probably be configured by objects in the Zope ZODB which say effectively "When you get email for this address, then call this Method".
You don't even have to know what kind of method it is, and in theory it doesn't have to be in the same server even. For each mail address (or domain, in case of fallbacks, if you want to implement that) you assign an URL, username and perhaps password, and submit the message via POST somehow. This tool would end up so easy to write (in principle) and generic that it wouldn't even be tied to Zope. (Yes, you could use ZPublisher.Client or XML-RPC or something more Zope-specific - but why? What would you gain by that?)
We haven't yet figured out how to make sure the above mail handling program can find all the relevant configuration documents. Is there some way of efficiently finding all instances of a particular ZClass?
There is a Design Pattern covering this. Essentially, the class registers all instances somewhere when they're built - you can do that in the constructor. But there are two different things here... either you store the configuration outside the ZODB and send to a different method depending on this configuration, _or_ you send everything to a single method and use a configuration in the ZODB to forward the message to the correct handling method. Mixing the approachs is not a good idea IMHO. []s, |alo +---- -- Hack and Roll ( http://www.hackandroll.org ) News for, uh, whatever it is that we are. http://zope.gf.com.br/lalo mailto:lalo@hackandroll.org pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG) --- http://zope.gf.com.br/BroDar