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.
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>)
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:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
