Mimi Yin wrote:
>> + What are valid recipient addresses to use?
>
> I'm not sure I understand this question.
The recipient email addresses are another namespace to be managed and
designed. Not every string you send as a recipient address will be valid.
Or maybe it is.
I do encourage it to be thought of as a namespace. And as suggested,
there's both right-hand-side (RHS) and left-hand-side (LHS) components to
this email namespace. Each side can be further divided by traditional
punctuation-based ways to structure plaintext (osaf-officecal@,
office.osaf@, [EMAIL PROTECTED], office-submit@, office-query@, etc).
> [EMAIL PROTECTED]
Yes, but even in strings there can be affordances. We can provide a
free-for-all, first-come-first-served gets the alias in a completely flat
namespace, which is sorta what I get from the run-together above. Some
carefully placed structure might help this aspect of usage. I now see below
you were thinking auto-generated, in which case they are still structured
somehow.
>> + How do addresses map to calendars? (1-1, 1 to many, many to 1)
>
> What are reasons for having multiple addresses per share?
Probably different operations per share. One alias for all-day event
submissions, one alias for regular events, one for free-form items, one for
SMS. One for deletions, one for searches. Ideas only, for clarification;
not proposals. I realize these other operations are not relevant to the
discussion of the "email submission" case.
>> + How are new addresses created?
>
> Auto-generated when a collection is shared.
Ah, you've moved on to a specific implementation model, ok.
What scheme do you propose for address creation? I suspect we must include
both components of the user -> collection pair. Probably concatenated with
punctuation: "jared.work@" and "jared.personal@" perhaps. Your idea?
SMTP format addresses have certain restrictions on syntax. Do any SMTP
restrictions (punctuation, no spaces, perhaps internationalization problems)
now become restrictions on the names of collections? Probably not. So
there's at least some mapping step between the two. I bet any proposed spec
starts with "strip whitespace" :) Not sure what else is needed offhand.
But I can't help think the user needs some control over this; if my Chandler
share name is "Work (client)" or something, perhaps the person would like to
be able to select the string that maps to in email (I think parentheses
might be out as an allowed character too, btw). I suppose the same problem
exists for any URLs you want to hand out to ("private" name used now becomes
visible by others). I'd guess our answer is to set the hassle aside and
make them name their collections the way they want the email to appear?
Brian mentions the "leaked address" problem as another motivator for wanting
to be able to set and change the email alias used.
If the email address is shown in say a Chandler dialog, I wonder how it
determines what to display. Did it ask the server for the name assigned and
use that? Did it present a dialog to the user, with
whitespace/known-bad-email-characters stripped out, and ask the server to
use that address for this collection? Who's driving?
Does the user get to select whether an email address is autocreated? A user
might reasonably wish to decline submissions. Indeed, they might wish to
turn it off and on as an administrative function later.
Feasibility? Not convenient given current architectures, but there's at
least a few different ways to implement "auto-creation" of the address. We
could go again for tight Cosmo integration. During collection creation and
deletion on the server, Cosmo could update a relational table of valid
submission email addresses and the collection URLs they map to. The MTA and
email robot would then look up in this table for each email submission
processed.
We can also do loose coupling (and an easy implementation) by just having an
external script poll/query the server administratively for all available
collections and create the complete list of aliases to allow.
(Architecturally, you need to collect all the valid addresses into a single
list for the MTA to know what's a valid submission address, and what should
instead be refused.)
Another option is to have the Hosted Service manage the alias/collection
mapping itself and have either Cosmo or Chandler call it via XML-RPC when
the service is shared. Transparent to the user, so still automated, but
this approach introduces a network service outside the Cosmo codebase which
is an awkward thing to consider and is not being proposed here.
I think it's fair to say that if needed, we could figure out fully automated
creation of accounts. Before getting far into implementations again, I'd
say I'd be happier be more comfortable having something like a behinds the
scenes system where the Hosted
>> Security-through-obscurity?
>> + Is authentication info put into the recipient alias?
>
> Like a password?
Something like a password. A ticket's like that too. Turns out from our
other thread we didn't put auth info in the recipient alias, we want to put
it in the sender alias.
The operational constraint here is that you can not reasonably do all of
these simultaneously:
- Accept email from any machine on the Internet
- Have no secret anywhere in the incoming email
- Forward all contents of all submissions to Chandler on the assumption that
it's a parseable action
Otherwise we will have created a system where literally hundreds of spam
messages a day can end up being submitted to every collection of every
user's account.
>> + Are the addresses temporary or permanent?
>
> Permanent. Otherwise adding items via email will become a real pain.
Ok. Permanent brings the pain of spam targeting of these addresses. The
design must uncomfortably account for that. The other thread seems to
approach some workable conclusions.
>> + What domain name (right-hand-side of the address) is used for the
>> address?
>
> Something friendly that connects the address to the hosted service :o)
> Is your proposal below to allow users to define their own email
> addresses, an anti-spam measure?
Mmmm, it's not so much a spam measure as a possible place to put one half of
the user+collection combination. It's a minor pain to implement, but it
should be on the table in design conversations as it could be a benefit.
>> + Are multiple domain names or just a single one in use?
>
> What are reasons for having multiple ones?
Namespace paritioning.
-- Jared
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
