Re: [Zope] Proposal for mail-in to Zope
"Cary O'Brien" <[EMAIL PROTECTED]> wrote: > >> - 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. >> > >Here I'd have to disagree. I would definately include polling of a >POP box as a way to get mail into the system. I think what we'll try and do is keep the interfaces clean so that a POP collector could be implemented, but its not a priority for us at the moment. I appreciate its important for some people, but I need to solve a particular problem at the moment. >Ok, so you could set up fetchmail to poll the pop box and redeliver >locally, but that is a lot of setup. > >And isn't there a ZScheduler that will schedule operations in the >future? And there is that nice python pop client interface. Apparently ZScheduler doesn't work yet. > > So: >> - Within Exim, use the "pipe" transport to get email for a particular >>host sent to a program on the standard input. If the program called >>returns certain codes then Exim will queue the message and try again. >> > >I think you can do this with sendmail by putting "|command" in .forward. Yeah, but I don't think you can have the program return error codes and have sendmail queue the mail and retry later. We want to avoid building something that has to store the mail in case Zope is down - email systems do that perfectly well at the moment. According to the docs, Exim will queue the mail if the program returns the appropriate error. >The nice thing would be have a nice class for storing mail (either >in the ZODB or an RDBMS), and a couple of ways to feed it (.forward >with a pipe for sendmail, whatever for exim..). That way people >can work with mail no matter how it was dumped into the system. You could certainly put that on top of what we're going to produce. We're trying to keep it very generic and call some kind of (DTML) method, and the world is your oyster from there Simon -- - My opinions are my own, NIP's opinions are theirs -- Simon J. Coles Email: [EMAIL PROTECTED] New Information Paradigms Work Phone: +44 1344 753703 http://www.nipltd.com/ Work Fax: +44 1344 753742 === Life is too precious to take seriously === ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Proposal for mail-in to Zope
Simon Coles wrote: > I think this is pretty much what we're intending to do. We haven't > decided about XML-RPC Vs ZClient. The aim is to get something > (anything) working, however hard coded, and then improve it. Use XML-RPC - it's a lot more powerful (e.g. it returns lists and dictionaries and integers and floats, while ZClient can only return strings.) -- Itamar S.T. [EMAIL PROTECTED] "It don't get thingier than that!" ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Proposal for mail-in to Zope
I think this is pretty much what we're intending to do. We haven't decided about XML-RPC Vs ZClient. The aim is to get something (anything) working, however hard coded, and then improve it. Simon "Kevin Dangoor" <[EMAIL PROTECTED]> wrote: >Hmm... "takes the email message and puts it into Zope". Using ZClient or >XML-RPC? ZClient is probably the easiest way to go. You'd probably want a >simple script configured in the file system to send the message on to method >in Zope via ZClient. That method will be part of a MailHandler object (or >some such) that can have rules based on the email address that the message >is going to. These rules will likely pass the message on to another method >(probably a PythonMethod, since this is programming we're talking about). It >might be nice if the MailHandler broke the message up into usable fields >instead of a plain text stream. I think there's a python module for doing >that. > >Kevin -- - My opinions are my own, NIP's opinions are theirs -- Simon J. Coles Email: [EMAIL PROTECTED] New Information Paradigms Work Phone: +44 1344 753703 http://www.nipltd.com/ Work Fax: +44 1344 753742 === Life is too precious to take seriously === ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
RE: [Zope] Proposal for mail-in to Zope
> 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. Providing a basic SMTP server is not at all difficult to do in Python. I did a cut-down one once as part of a test system, and extending it would be straightforward (the cut-downness was not in structure, just did not bother to implement the SMTP commands I did not need - the underlying design was a state-machine [natch!] - however one problem I did come across was that it was not possible to implement the state machine completely from the RFC, which contains ambiguities). Some potential troublespots in re-visiting this work: - error handling, if done properly, might cause some problems (the state machine helps a lot here, but I cannot guarantee that I did not miss something obvious) - emails nowadays can be very large, with MIME encoded movies and stuff. Each received email has to be stored somewhere - can we (would we want to?) reliably store this kind of data in the ZODB? > - 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. Funny you should mention this. I am considering moving my domain from the current ISP to a friend's server. One of my current ISP's services that I use is webmail, so I was looking at how this could be done after the move. Sending mail through a web interface is a doddle, but what about viewing received emails? I had got as far as realizing that something could be built on Python's support for POP3 - use POP3 to collect the headers of currently available messages, create a web page displaying them, with each entry linked to a page that would download (without deleting) an individual email. I think that my current ISP's webmail system must be doing something like this. So far it looks fairly straightforward to implement. Richard (who now realizes that he has to find that old Python SMTP server code - now I wonder where I put it ...) ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Proposal for mail-in to Zope
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. []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:[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] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Proposal for mail-in to Zope
Hi ! Simon Coles wrote: > Does this sound like what people need? Any thoughts, comments, warnings? > > I don't know yet what kind of schedule we'll be able to do this on > but drop me a mail and when there's something to play with we'll let > you know. I wanted to define this as a Task for the ZDP-Tools, but I only made some research into this, so I hope this helps in any way... Greetings, Maik Röder Mailbag It would be nice to have a Mailing list tracker on the ZDP site, where all messages, which are sent to all of the Zope mailing lists are kept. The messages could then be used for searching on specific topics, and could also be directly reused when new pieces of documentation are written. Reusing pieces of documentation right now means to track the mailing lists, using your own mail reader, or going to one of the online Mailing list trackers like egroups, and then cutting and pasting the message into your documentation. Just taking over content is not nice without giving credit to the original author. It is also not very user-friendly because much of the discussion, which has been surrounding the posting in the original discussion thread is simply lost. The original thread can be very useful for ZDP visitors, who may want to have a look at it when they see it quoted. Right now, giving a pointer to the original post is hard, because you can not be sure whether the site you are pointing to always keeps the URL, or for what is worse, even disappears. We need to be sure that a quoted message along with it's thread still exists in the future. We don't have enough space on the ZDP site to keep the whole Zope mailing lists, and so we are planning to digest the incoming mails only for a certain period of time. Afterwards, the mails will be deleted if they haven't appeared in a thread that has been quoted. We don't have the ressources to update the Mailing List Tracker everytime a mail is sent to a mailing list. So, to quote a mail, we need to manually upload all mails which have been written to that list since the last update. We also need to update threads to which new mails have been posted in the meantime. We also lack a tool for uploading messages to the Zope site. We could extend the Mailbag product by Tres Seaver which uses the Python 'rfc822' and 'mailbox' modules to parse messages and mailboxes. Lately, Tres Seaver has rewritten Mailbag, refactoring the logic into Python classes. The corresponding ZClasses for the presentation layer still have to be rewritten, but can possibly be taken over from the previous Mailbag version. To get the mail into Zope, a program needs to be written that calls Mailbag via ZClient when a mail arrives. Another type of program could be useful for importing existing Mailboxes into Zope. For delivery, an MDA like procmail could spawn a program out of a .forward file and ask it to upload the mail to a Zope folder according to a predefined set of recipies. There exists a Python program called getmail which takes mail from a POP3 server and delivers it into a mailbox. The delivery part of this program uses a getmailrc which could be used instead of the procmail recipies. Once the mail is in a local installation on a ZDP members own Zope server, it is easy to export the email and upload it to the ZDP site. From there, the ZDP members can quote the message easily by directly pointing to the URL. This way, we may not get a complete mail archive, but at least we can always be sure that the quoted mails and their surrounding thread exist. -- Open Source is "about being able to work together with people you've never met, on projects that are in a constant state of flux, on a time schedule that would cause a hummingbird's head to spin." Paul Ferris, http://www.linuxplanet.com/linuxplanet/opinions/1593/1/ ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Proposal for mail-in to Zope
Along these lines, if we have an "rfc822" object, what operations would we want to perform on it ? What other objects would be useful ? A "folder" object ? A "part" object for handling "multipart" MIME objects Possible actions === * save/fetch a message object to/from "folder" for messages in ZODB * dissemble a multipart MIME message into "part" objects in memory * write a "part" to/from a file * write a "Multipart" object to a "multifile" * "send a message" into the ZODB "folder" from the outside * "send a message" from the ZODB "folder" to the outside * search for message by attributes These operations would be methods on the "rfc822" object, "part" object and ZODB "folder" object, invoked appropriately ( locally or via remote calls ). Nitin Borwankar, [EMAIL PROTECTED] Chris McDonough wrote: > > I'm interested in this, although I have a lot on my plate right now and > can't help in development. > > I see objects in Zope being able to handle a call to one of their > methods that passes off a chunk of email text and stuffs it in an > attribute for later display or catalog. > > I think you should probably start by designing the interface to these > kinds of objects and worry about exactly how you're going to call the > methods that make up the interface later... > > > -Original Message- > > From: Simon Coles [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, May 31, 2000 11:54 AM > > To: [EMAIL PROTECTED] > > Subject: [Zope] Proposal for mail-in to Zope > > > > > > Hi, > > > > We (NIP - in the form of Chris Withers, Stephen Harrison, and Simon > > Coles) have put some thought into the question of how to get emails > > into Zope, and have come up with a design which we thought we'd pass > > by the list before we start doing something. > > > > 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. > > > > We aren't worried about sending email, that's done well at the > > moment. We also wanted to keep things as simple and quick as possible > > :-) This means trying to avoid getting involved with mail systems as > > much as we can. > > > > 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. > > > > 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. > > - 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. > > > > So: > > - Within Exim, use the "pipe" transport to get email > > for a particular > > host sent to a program on the standard input. If the > > program called > > returns certain codes then Exim will queue the > > message and try again. > > > > - 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". > > > > - The DTML Method is responsible for doing the right > > things to get > > the email message into the ZODB in whatever form is > > appropriate. > > > > 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? > > > > (Chris W. still isn't sure that's how the configuration will work but > > that's the plan for the moment, so any thoughts would be appreciated) > > > > What we'll do is a first version that hard codes everything in the > > above script and prove the principle
RE: [Zope] Proposal for mail-in to Zope
I'm interested in this, although I have a lot on my plate right now and can't help in development. I see objects in Zope being able to handle a call to one of their methods that passes off a chunk of email text and stuffs it in an attribute for later display or catalog. I think you should probably start by designing the interface to these kinds of objects and worry about exactly how you're going to call the methods that make up the interface later... > -Original Message- > From: Simon Coles [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 31, 2000 11:54 AM > To: [EMAIL PROTECTED] > Subject: [Zope] Proposal for mail-in to Zope > > > Hi, > > We (NIP - in the form of Chris Withers, Stephen Harrison, and Simon > Coles) have put some thought into the question of how to get emails > into Zope, and have come up with a design which we thought we'd pass > by the list before we start doing something. > > 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. > > We aren't worried about sending email, that's done well at the > moment. We also wanted to keep things as simple and quick as possible > :-) This means trying to avoid getting involved with mail systems as > much as we can. > > 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. > > 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. > - 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. > > So: > - Within Exim, use the "pipe" transport to get email > for a particular > host sent to a program on the standard input. If the > program called > returns certain codes then Exim will queue the > message and try again. > > - 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". > > - The DTML Method is responsible for doing the right > things to get > the email message into the ZODB in whatever form is > appropriate. > > 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? > > (Chris W. still isn't sure that's how the configuration will work but > that's the plan for the moment, so any thoughts would be appreciated) > > What we'll do is a first version that hard codes everything in the > above script and prove the principle of the thing, and then move onto > the configuration. > > > Does this sound like what people need? Any thoughts, > comments, warnings? > > > I don't know yet what kind of schedule we'll be able to do this on > but drop me a mail and when there's something to play with we'll let > you know. > > > > > Simon > -- > - My opinions are my own, NIP's opinions are theirs -- > Simon J. Coles Email: [EMAIL PROTECTED] > New Information Paradigms Work Phone: +44 1344 753703 > http://www.nipltd.com/ Work Fax: +44 1344 753742 > === Life is too precious to take seriously === > > ___ > Zope maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope-dev ) > ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Proposal for mail-in to Zope
- Original Message - From: "Simon Coles" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, May 31, 2000 11:54 AM Subject: [Zope] Proposal for mail-in to Zope > So: > - Within Exim, use the "pipe" transport to get email for a particular > host sent to a program on the standard input. If the program called > returns certain codes then Exim will queue the message and try again. > > - 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". Hmm... "takes the email message and puts it into Zope". Using ZClient or XML-RPC? ZClient is probably the easiest way to go. You'd probably want a simple script configured in the file system to send the message on to method in Zope via ZClient. That method will be part of a MailHandler object (or some such) that can have rules based on the email address that the message is going to. These rules will likely pass the message on to another method (probably a PythonMethod, since this is programming we're talking about). It might be nice if the MailHandler broke the message up into usable fields instead of a plain text stream. I think there's a python module for doing that. Kevin ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Proposal for mail-in to Zope
> Hi, > > We (NIP - in the form of Chris Withers, Stephen Harrison, and Simon > Coles) have put some thought into the question of how to get emails > into Zope, and have come up with a design which we thought we'd pass Excellent idea. I was thinking about this just the other day. We have a mailing list for a project, and it would be nice to drop in an email archive into the zope site we are using internally. > by the list before we start doing something. > > 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. > > We aren't worried about sending email, that's done well at the > moment. We also wanted to keep things as simple and quick as possible > :-) This means trying to avoid getting involved with mail systems as > much as we can. > > 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. > > 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. I'd have to agree. > - 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. > Here I'd have to disagree. I would definately include polling of a POP box as a way to get mail into the system. Not everyone has a 24x7 internet connection with a fixed ip address and a dns entry, so for them polling a POP box would be a great way to handle things. Plus it is great for those people picky about security that don't let anything inward across the firewall. Ok, so you could set up fetchmail to poll the pop box and redeliver locally, but that is a lot of setup. And isn't there a ZScheduler that will schedule operations in the future? And there is that nice python pop client interface. > So: > - Within Exim, use the "pipe" transport to get email for a particular > host sent to a program on the standard input. If the program called > returns certain codes then Exim will queue the message and try again. > I think you can do this with sendmail by putting "|command" in .forward. > - 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". > > - The DTML Method is responsible for doing the right things to get > the email message into the ZODB in whatever form is appropriate. > One thing I don't understand is how many processes can access a live ZODB. How does the locking work? Otherwise you'd need to have your mail processor command do an html get or post to get the information into Zope. > 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? > > (Chris W. still isn't sure that's how the configuration will work but > that's the plan for the moment, so any thoughts would be appreciated) > > What we'll do is a first version that hard codes everything in the > above script and prove the principle of the thing, and then move onto > the configuration. > > > Does this sound like what people need? Any thoughts, comments, warnings? > > The nice thing would be have a nice class for storing mail (either in the ZODB or an RDBMS), and a couple of ways to feed it (.forward with a pipe for sendmail, whatever for exim..). That way people can work with mail no matter how it was dumped into the system. An advantage is that adding a POP client would allow you to create a POP mail reader using zope also. Just a thought. -- cary [EMAIL PROTECTED] > I don't know yet what kind of schedule we'll be able to do this on > but drop me a mail and when there's something to play with we'll let > you know. > > > > > Simon > -- > - My opinions are my own, NIP's opinions are theirs -- > Simon J. Coles Email: [EMAIL PROTECTED] > New Information Paradigms Work Phone: +44 1344 753703 > http://www.nipltd.com/ Work Fax: +44 1344 753742 > === Life is too precious to take seriously === > ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cr
[Zope] Proposal for mail-in to Zope
Hi, We (NIP - in the form of Chris Withers, Stephen Harrison, and Simon Coles) have put some thought into the question of how to get emails into Zope, and have come up with a design which we thought we'd pass by the list before we start doing something. 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. We aren't worried about sending email, that's done well at the moment. We also wanted to keep things as simple and quick as possible :-) This means trying to avoid getting involved with mail systems as much as we can. 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. 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. - 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. So: - Within Exim, use the "pipe" transport to get email for a particular host sent to a program on the standard input. If the program called returns certain codes then Exim will queue the message and try again. - 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". - The DTML Method is responsible for doing the right things to get the email message into the ZODB in whatever form is appropriate. 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? (Chris W. still isn't sure that's how the configuration will work but that's the plan for the moment, so any thoughts would be appreciated) What we'll do is a first version that hard codes everything in the above script and prove the principle of the thing, and then move onto the configuration. Does this sound like what people need? Any thoughts, comments, warnings? I don't know yet what kind of schedule we'll be able to do this on but drop me a mail and when there's something to play with we'll let you know. Simon -- - My opinions are my own, NIP's opinions are theirs -- Simon J. Coles Email: [EMAIL PROTECTED] New Information Paradigms Work Phone: +44 1344 753703 http://www.nipltd.com/ Work Fax: +44 1344 753742 === Life is too precious to take seriously === ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
