[Design] Email options: email submission to collections

[Mimi Yin]

Seems like we're converging on a solid proposal. We need to get to  
this point with the other 'Bridging the Gap between Chandler and  
other Email clients' proposals (e.g. Chandler as an IMAP client,  
Pulling down mail with special Chandler headers, etc) to be able to  
start a prioritization discussion about what we're heading for in the  
Beta / 1.0 timeframe.

See more in-line...

On Aug 2, 2006, at 12:39 PM, Jared Rhine wrote:

> Mimi Yin wrote:
>> So if I understand you correctly:
>> + Its hard to manipulate things on the RHS
>
> More technical trickery is required by the Hosted Service.  A good  
> kind of
> technical trickery, and one-time trickery, which I'm up for.  For  
> Cosmo, I'm
> think it's no harder or perhaps even easier.  For a UI, it's  
> probably the
> same (same functions like "that address is already picked; please pick
> another").
>
> Where do we think the UI for this is located?

Either in Scooby or Chandler. Whichever is more expedient.

>
>> + It's more work to auto-generate email addresses
>
> Seems like it, yes.
>
>> + There are benefits to requiring that users submit structure email
>> addresses (e.g. /EVENT) mostly relating to wedding out SPAM
>
> Agreed.
>
>> + Why don't we ix-nay the RHS stuff. I agree it's more elegant,  
>> but not
>> a must-have?
>
> The backend components are likely to just see a plain string.  LHS- 
> only is a
> generalization of the LHS+RHS which is a generalization of "arbitrary
> address".  So it is primarily a design/UI/workflow issue.  Not a  
> must-have.
>
> I agree to starting with a LHS-only implementation.  Richer  
> implementations
> can come later with interfering with this design, and LHS-only  
> would be the
> most common case for anyone else trying to implement a email-to- 
> collection
> gateway.
>
>> + That leaves us with a user-defined LHS, which would rule out  
>> using the
>> LHS to define the Kind of item you would like to submit (e.g.
>> events at mycalendar.osaf.us <mailto:events at mycalendar.osaf.us>)
>
> I don't think LHS necessarily rules out additional semantics.  The  
> UI could
> collect additional info about the submission email: "Should emails  
> to this
> address be considered A) Events or B) Notes? by default".
>
> You could also introduce conventions on top of the user-chosen  
> LHS.  Say the
> user chose "bobs-bitchin-calendar".  That could default to assuming  
> events.
>  But every address would get a couple of "bolt-on" automatic aliases:
>
>   bobs-bitchin-calendar at submit.osaf.us
>   bobs-bitchin-calendar.note at submit.osaf.us
>   bobs-bitchin-calendar.event at submit.osaf.us
>   bobs-bitchin-calendar.reference at submit.osaf.us
>   bobs-bitchin-calendar.sms at submit.osaf.us
>   bobs-bitchin-calendar.mail-me-a-pdf-of-my-calendar at submit.osaf.us
>
> This technique, too, is a refinement of "let user chose a LHS"  
> approach
> which can be added later without interference.
>
> For now, I'd keep both asking user for more info about the submission
> address and extra strings appended to the end out of our next spec.

Okay, good phasing suggestion.

>
>> + However, since structured email is more desirable from a security
>> standpoint anyway, let's try out forcing users to have something
>> like: /EVENT, /TASK in the Subject line. (Is that enough  
>> structure? or
>> Do we need more?)
>
> We probably need more someday.  But let's prototype something with  
> just
> this, to gain practical experience, so we don't block on this  
> thorny issue now.
>
> Spam protection is expensive in either labor, capital, or  
> maintenance to
> minimize.  Without secrets (passwords, tickets, etc), any email  
> address
> accessible from the open Internet is at risk for spam, from "never  
> actually
> received any" to "this address is now officially useless".   
> Automated spam
> filtering system will achieve success of between 95% and 99.99%.   
> You can't
> reach 100% without adopting a "deny everything except..." policy.
>
> BTW, the user can't also control their subject line, in cases like SMS
> gateways and email-from-mobile-phone.  It's fair to say let's start  
> with
> /TYPE required on the subject line to get more practical experience.

Sounds good.

>
> I believe the design here should be extensible.  On the long list of
> possible enhancements beyond our emerging spec, I believe users should
> someday be offered to turn a submission email into a "password  
> protected"
> address.  In that model, no email that didn't contain the password  
> would
> ever be accepted: "/EVENT MyPasswoRd pto thursday".  Other logics  
> should be
> able to be plugged in so implement other lightweight (or strongly- 
> secured)
> mechanism for remote submission to collections.

Yup. Agreed.

>
> Of course each new type of logic requires UI development, so I  
> think the
> /EVENT model is an excellent, really lightweight place to start.  I  
> dunno
> how far it will take us.

Hopefully enough to figure out the right next steps ;o)

>
> The developers have some technical challenges:
> + Figure out where to store even just the single email address  
> attached to
> the target collection
> + Figure out what infrastructure would be needed if additional  
> attributes
> are required later (whitelist, default submission type, etc)
> + How to allow UIs to query the server to determine if a given  
> address is
> available (across all emails that have been claimed by all users)
> + How the list of collections, emails, whitelists, and other  
> metadata will
> be communicated to the Hosted Service so a traditional email stack  
> (Postfix)
> can be used to integrate processing of inbound emails

These might be good to through to the dev lists after we figure out  
where this proposal falls on the Beta/1.0 prioritization list.

>
>> + *Question:* If there is no /EVENT or /TASK in the subject line,  
>> can we
>> accept the submission just as a Note or Communications item?
>
> Yes, though that would seem to be in conflict with the last spec  
> point of
> "forcing users to have something like: /EVENT, /TASK in the Subject  
> line".
> Submissions either require the header or they don't, in terms of  
> whether
> they get added to Chandler in one form or another.  I recommend  
> starting the
> spec with "required for all submissions" for now

Okay.

>
>> It would
>> minimize the risk of SPAM since Chandler wouldn't recognize it as  
>> an event.
>
> It minimizes the risk of event spam, but introduces the possibility  
> for Note
> spam and/or Communications spam.
>
>> + If we require a particular structure in order to recognize email
>> submissions as events and tasks, do you feel we still need to  
>> implement
>> quarantining and/or whitelisting right away?
>
> "Right away" for next 3 months proof-of-concepts?  Alpha?  Beta?  I  
> think
> for strict proof-of-concepts, we can defer quarantining and/or  
> whitelisting.
>  We probably can't get to Beta without at least either or both.   
> For the
> immediate next deliverable (proof-of-concept/prototype/plausible  
> levels), I
> think whitelisting and quarantining can be deferred and would  
> approve of
> that approach.

Okay.

>
> -- Jared
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design