At 19:26 1/9/2003 +0100, Xavier Nodet wrote: >> 8. Does M have an API/SDK? > >I'm not sure about what you would like this API to enable you to do, but >there is a Python binding. But I'm really not familiar with it.
I am obviously not yet up-to-speed with M, however one of it's attractive features is that it seems like a very flexible framework. My thought is that an API would allow an external application to hook-into this framework and provide customized functions which are not native to M. For example, assuming that one were to want to comb through the stored email database with a separate application, and perform some analysis (or indexing task). With an API, one could use M to act as the DB interface -- locate the messages within the MH/MBOX/IMAP store, decode the messages as necessary, and provide the text to the application. >> 12. On a Linux machine, would it be possible to filter an incoming >> email through a filtering program -- such as SpamAssassin or Procmail? > >Of course, as such filtering occurs before the last SMTP server. >Mahogany is not involved at all in this. > >> And, provided some enterprising soul were to port these applications, >> would it presumably be possible in a Windows environment? > >I do filter incoming mail on my Windows machine. I use Hamster-Fr for >that, which calls SpamProbe via a Perl script to classify incoming >mails. Again, Mahogany is not involved at all, and I could use any MUA. This is obviously a very viable and useful approach. However, it seems to me that it would also be very useful to allow for a series of hooks in the course of MUA mail processing... (1) after email receipt but prior to decoding, (2) after decoding, ... (n) prior to encoding, and (n+1) just prior to transmission. In this way, a pre-processor such as SpamAssassin/Razor/etc could easily be called from the local machine. For users without access to server-side resources, this would make a great deal of sense. To address this issue with a full-fledged security-aware SMTP/POP proxy seems as though it is duplicating a great deal of effort, somehow. (I do readily agree that this approach would be universally applicable to all MUAs, however, and may, in fact, be a more general purpose solution) >> -- ie, could an incoming filter change all "To:" >> headers from "To: Bob" to "To: Alice"? > >Mahogany will not do that, but other programs could. > >Actually, filters inside Mahogany are mainly used to move/delete messages, >or flag them as important. What you ask for in the last questions is >generally handled by external programs. If I understand you correctly, the external programs would need to be invoked externally -- though an SMTP proxy, for example -- and not through M. In other words, it sounds as though one could not implement a filter within M which caused M to invoke a program "X" when an email was encountered with a "To: Bob" in it, so that the program could perform the modification? >> 18. Supposing that all outgoing emails are saved -- some of which are >> PGP encrypted. How does the "Find" function cope with these encrypted >> emails? Will it detect the encryption, and ask for decryption >> keys/passphrases? > >This has to be defined. But as messages are usually encrypted for >someone else, I guess you won't often have the private key to decode, >no? >Or do you always add yourself in the recipients? There appear to be three different strategies, which depend upon the user's threat model. (1) The outgoing messages are encrypted only to the recipient, in which the saved outgoing message will only serve to remind you that such a message was sent at a given time/date. If your computer is ever compromised, encrypted emails are inaccessible to everyone, except for the respective recipients. (2) The "encrypt-to-self" options in GPGP (:-) are used, in which case the email is not stored in plaintext, but should your computer AND private key be compromised, past correspondence is violated. The threat model here assumes the safety of one's private key. (3) The outgoing email is saved as plaintext. In this case, the threat model assumes that one's computer will not be compromised. For most GPGP users, I'm guessing that options #1 and/or #2 are most common. Option #3 requires no special treatment in the case of a search of the email DB. And, as you correctly point out, option #1 emails are impossible to decrypt for the sender, hence they also require no special treatment and, in fact, are the same as option #3 emails for all intents and purposes. It is with emails that fall into the option #2 category that a find function would require a private key so that the plaintext would be accessible for examination. Frankly, I believe that the "intelligent" handling of encrypted email by MUAs is a major stumbling block to the wide-spread adoption of GPGP. In my view, it is a serious drawback for an MUA not to allow access to encrypted communications easily (for viewing/searching/processing) when one does, in fact, possess a key capable of decrypting the ciphertext. Thank you for your reply, Xavier! Hannes. -- Email: [EMAIL PROTECTED] <*> PGP ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Mahogany-Users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mahogany-users
