Mimi Yin wrote: >> It's important to formulate an architecture that is pretty resistant >> to spam attacks.
> What about allowing the shar-ER to specify which emails addresses the > collection will accept emailed items from? Term of art might be "whitelisting". > 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. Term of art might be "quarantining". They are both viable and pretty well understood. Whitelisting is much (much) easier to implement than quarantining. (Whitelisting is a stateless lookup operation; quarantining is highly stateful in that you have to hold on to the submission and go through a process to approve or expire them eventually). A default block-everything-but-allow-whitelists policy is a robust, best-practice security approach. So the "accept-from" list of emails feels pretty solid to me and the current best proposal. There's definite problems in that the From: header on submissions is not a reliable way to identify a sender. But, the combination of whitelist plus specific destination address is pretty good all-told, and I suspect good enough for the Hosted Service Beta purposes. But, maybe we get a third factor for free in this poor-person's-authentication we're doing. Is the design proposal that all submissions have something like "/event blah" or "/item blah" in the subject/body? A "slash-command" or whatever we call them. If so, that's enough of a "special format" to serve as a barrier to a fair amount of automated spam. It would not deter anyone malicious with the ability to set the email From header; I suspect passwords would be necessary to deter a fuller class of malicious users. Or can any email at all be forwarded and accepted to a submission alias (using email client forward, bounce, etc features), where it will be queued up with the the best attributes that can be assigned? If so, then any random spam will also pass the test. Overall, I think this basic auth scheme (with slash-commands preferably, but workable without) is good enough for now. There should be nothing preventing others or us later from implementing other email-submission schemes which provide up to full GPG-signed submissions where the authentication can be done robustly. So if whitelists are how we manage authentication to mitigate the spam issue, then whitelist management becomes the primary work item I think. It's a pain; whitelists are always somewhat out of date, if the group is of any size you spend a lot of time approving new senders, etc. Sometimes you see attempts to integrate contact lists with the whitelist features (for say desktop email clients); often it's an entirely different database though. You'll find, when you admin a mailing list at least, that people use quite a few different email addresses and often want to submit from other email aliases (forwarding from another account). As admin, if you know the group, you probably say, "oh, that's Bob" and go right on. But I'm positing that if this model is used, the quarantine interface would get used quite a bit probably. Quick boundary use case: the office mailing lists get forwards from Wall Street Journal "share this page" functionality a fair bit. The general case is where a 3rd party is forwarding along an email for someone who is in the sharing group. This case would be handled by the standard quarantining mechanism as well, though it's worth mentioning the slight difference in practice and that this is pretty much how permanent email addresses end up leaking. I'm realizing Mailman provides a useful model to explore for this "email queue management" situation. Mailman provides many foundation features; it supports sending to the list if you're already on it (versus public submission). It provides a whitelist of people allowed to send even if they aren't in the group. Mailman also provides quarantining. It manages a queue for each list, so if you don't throw away submissions from people not on the list (an option) but don't want it automatically forwarded along (an option), the list manager(s) get an email reminder (guh, not another one) with a URL to review the queue and reject forever (blacklist), or put on the permanent list of accepted addresses (whitelist), or do a one-time acceptance. Mailman interactions are all web and email mediated. It's kinda a pain. Would it be possible to use the Dashboard to manage the "emails to approve for submission queue" just like any other triage item? Is both a Chandler and web interface required for whitelist/quarantine management or just one? > If I approve an email submission from [EMAIL PROTECTED], then all future > submissions from [EMAIL PROTECTED] are approved as well. That's how I think of whitelisting, though there's also the "temporary approval" or model. Also borrowing from mailing list patterns, approving each submission is the "moderated" mailing list. To confirm, a distinct whitelist system maintained by the Hosted Service is pretty small in overall effort. Integration with contact lists or other products is more complicated. Whatever system maintains the whitelist database itself needs to communicate it to the MTA somehow, for real-time rejection. It's possible to store everything and sort on whitelist later but there's various operational reasons that's not the best practice. -- Jared _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
