PythonCard Email Application
This page is intended to capture issues for creating a sample email application in PythonCard.
Fred Pacquier created the fpop sample. fpop is modeled after the Japanese nPOP email program, but is designed to delete unwanted email such as SPAM from a POP3 server before the email is downloaded to the users local machine.
After spending some time with Fred's first pass at fpop, I started updating it with more features for viewing and sending email, automatically tagging SPAM for deletion, etc. I'm naive enough to think that we can create a basic email client using the standard Python libraries and PythonCard for the application framework. If nothing else, this will be a good stress test of the framework <wink>.
Email package
I decided to focus on using the latest version of the email module for the handling of messages. The most recent version of the email package is newer than what is included with Python 2.2.1 and so the package will likely get included with the email sample app to simplify usage.
Mailbox format
I would like to use one of the standard mailbox formats already supported by Python. We would probably maintain additional index files to speed up searching and displaying mailboxes as they get large.
I have done some experimentation with importing mail messages (using the rfc822 library) into relational stores (Access, SQL Server, most recently MySQL with full text indexing), and would like to discuss whether this would offer additional benefits that might make it worth including this feature. I'm sure that the email module will be quite easy to adapt to. [SH]
Some Proposed Features
- To, Cc, Bcc fields must support auto-complete of name/email addresses pulled from an address book
- Inbox, Outbox, Sent, Deleted and Draft mailboxes. Some of the names might be different.
- Simple rules set for automatically moving incoming messages or messages from a particular folder into the proper mailbox for mailing lists, SPAM filtering, etc.
- SPAM blacklist
- figure out the registry and COM necessary so that the email app will be used when other apps try and compose an email via a mailto URL...
display mail threads using Tree component or indents in MultiColumnList
- possibly support some smarts for identifying URLs in email to automatically extend selections for launching a URL in a browser, opening a new message for a mailto, etc.
- how about an automatically-updated SPAM blacklist? There must be sources on the 'Net, and it would seem sensible to make use of such information if it would help. [SH]
Mail handling semantics and policies
Headers that are typically hidden from the user
- In-Reply-To
- References
- X-Mailer
- X-Attribution
- ... and many others. Isn't it sometimes more useful to let the users say what they *do* want to see, or at least give them an include/exclude choice? [SH]
Replies versus Forward
- Replies don't include attachments from an original email, a forwarded message does.
Replies should provide at least simple quoting using >. If possible more sophisticated X-Attribution style quoting can be applied
- On replies, the Subject gets a "Re: " prepended if it doesn't already have one.
- Should a Reply-To header override any of the semantics below?
non-nested citations (using X-Attribution header or initials)
[From Barry Warsaw]
Google's historical Usenet archives are a wonderful and scary thing. I couldn't remember who invented non-nested citations, and a quick search showed that it's been a long time:
But this nice posting includes the comments in one of the original versions of the file, which reveals that it was Martin Neitzel who invented it.
Here's an example.
>>>>> "KA" == Kevin Altis <altis@semi-retired.com> writes:
KA> I'm assuming the code for Supercite is elisp not Python?
Yup.
Reply
- The first item in the From header of the original message is used for the To.
You should certainly reply to the Reply-To address if such a header was present in the original message [SH].
- Cc, Bcc from the original message are dropped.
You should not see any Bcc headers coming in, since the feature works by transmitting the message to the user without including any header data. Relaying MTAs must save information about who should receive the message separately from the message content. If you are a Bcc recipient your address should appear nowhere in the headers (unless you are also listed as a recipient via To or Cc headers [SH].
- There should be an option that allows addresses from messages to be added to the address book easily in some preferred format [SH]
Reply to Group
Not sure here what meaning "group" has, unless the software will recognise subscribed mailing lists (perhaps recognizing particular headers from mailman and other list managers). Of course, if the program were to become a news client as well this feature would be more comprehensible. But do we want to rewrite Outlook Express? [SH]
Reply to All
Forward
- The From, To and Cc fields are not used from the original message.
- The Subject gets a "Fwd: " prepended if it doesn't already have one.
- Any attachments from the original message are included.
- Should In-Reply-To and References be included?
Message Threading
Jamie Zawinski describes the algorithm used by Netscape Mail and News 2.0 and 3.0 for message threading
RFCs
RFC 2822 - Internet Message Format
RFC 2821 - Simple Mail Transfer Protocol (SMTP)
RFC 2231 - MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
RFC 1939 - Post Office Protocol - Version 3 (POP3)
See http://www.faqs.org/rfcs/rfc-activeT.html for other related RFCs
References
Fetchmail FAQ - additional POP3 issues
Contributors
Initials indicate comments by particular individuals.
- [KEA] Kevin Altis
[SH] SteveHolden
Changes
- 2002-07-16 [KEA] created
- 2002-07-23 [SH] responded