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? > + 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. > + 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. 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. 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. 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 > + *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 > 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. -- Jared _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
