Brainstorming about email with Grant

From the stickie board...

0.7 invitation support

• send/receive bugs
• stamping bugs
• account dialog
• reply/replyall/forward

Plausible Email

• HTML rendering
• email auto complete
• pop3
• email attachments ui
• email attachments model
• detail view printing
• mime doc handling
• rule builder

check out Zimbra's approach to rules

Dogfood Email

• search infrastructure #2
• search ui #2
• imap support
• multiple email accounts
• imap folder view and synchronization
• imap folder view and sync ui and prefs
• junk management
• html editing
• anti-spam library (pick which one to use)

is client side anti-spam really necessary here?

imap support can/should be broken down into subcomponents

simple html editing is much easier than full blown html editing: a basic subset for pretty messages not so hard (bold text, etc.), but being able to receive a complex html page with tables, and be able to edit and reply to that, is more challenging

Usable Email

• threading
• spam detection
• launch separate detail view
• outlook import/export
• rich text editing (plain txt vs rich text gymnastics)
• spell checking
• inline image display
• attachments ui #2
• mail import
• mail list manager
• printing #2
• imap offline support (new stickie)

reading the outlook format directly is hard

offline support is hard

security

University Email

• SASL, weird authentication schemes
• Quota management

Open questions about usable email in 1.0

• Will the repository be able to support it?
  • How does the repository support it? Do we separate the file storage?

IMAP and POP

• Two forks for IMAP:
  • support stuff within a single folder
    • disconnected
    • connected
  • general folder management
• IMAP: How much of the message do you choose to cache on the client?
• IMAP: flags, tags
• How do you manage messages in pop?
  • multiple machines, servers run out of space
• Tested against various servers (both imap and pop)

Questions and Ideas

If we start from the assumption that the target user will continue to use their existing email client...

• Does the user start with a clean slate for Chandler email (new account just for chandler-email)?
• Does Chandler have a window on the user's existing email on the IMAP server?

How can we make limit the window on the user's existing email?

• Only see 1 folder what are the consequences?
• Only see limited # of messages, by time period or most recent n messages
• Chandler "knows" the information but delegates the work to another client -- import just meta data
• Only pick 1 or 2 clients that we "interoperate" with

Clean slate options:

• Only support one imap server, of our choice
• We host chandler email as part of the service (only support invitation workflow, for example)