Hi Jared,
Here are some questions/comments below.
On Jul 18, 2006, at 2:00 AM, Jared Rhine wrote:
I focus on the recipient email address because a lot of design points
revolve around that:
+ What are valid recipient addresses to use?
I'm not sure I understand this question. Actually I'm pretty sure I
don't understand this question.
[EMAIL PROTECTED]
+ How do addresses map to calendars? (1-1, 1 to many, many to 1)
What are reasons for having multiple addresses per share?
+ How are new addresses created?
Auto-generated when a collection is shared.
+ What information gets coded into the recipient address? Target
calendar?
Yup
Security-through-obscurity?
+ Is authentication info put into the recipient alias?
Like a password?
+ Are the addresses temporary or permanent?
Permanent. Otherwise adding items via email will become a real pain.
+ 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?
+ Are multiple domain names or just a single one in use?
What are reasons for having multiple ones?
+ How likely is the alias to receive dictionary-attack spam (ie,
guessing of
addresses)?
+ How likely is this alias to be published and collected by spammers?
It's important to formulate an architecture that is pretty
resistant to spam
attacks. Who wants spam in their calendar? This is a difficult
problem to
solve without switching to some non-interoperable methods. Some
ideas there:
+ You can have throw-away email addresses. Use a web UI to create
a new
temporary email alias. Run a REST/XML-RPC service which allows
others apps
to create new temporary email aliases before submitting anything.
+ You don't expect humans to send to the address. You use a very
exacting
format that only computers can formulate and send.
+ You expect humans to send, but you use some special (hard to get
right
probably) format, teach it people, and tell them not to tell others or
publish it. You could have a password that needed to be included
in the
submission, and change it periodically.
+ You take your SMTP mail server off the "open net" and only take
submission
from specific upstream mail servers, or specific authorized (possibly
encrypted) clients
What about allowing the shar-ER to specify which emails addresses the
collection will accept emailed items from?
Or queuing up email item submissions, so that they need to be
approved by someone with write access to the share before they are
formally added to the share.
If I approve an email submission from [EMAIL PROTECTED], then all future
submissions from [EMAIL PROTECTED] are approved as well.
It's sort of like setting up a mailing list, but the list of
participants grows organically over time.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
