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
> "[EMAIL PROTECTED]" 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.
Hack and Roll ( http://www.hackandroll.org )
News for, uh, whatever it is that we are.
http://zope.gf.com.br/lalo mailto:[EMAIL PROTECTED]
pgp key: http://zope.gf.com.br/lalo/pessoal/pgp
Brazil of Darkness (RPG) --- http://zope.gf.com.br/BroDar
Zope maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -