On Jul 19, 2006, at 6:06 AM, Jared Rhine wrote:
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.
I think we would like the ability for items to arrive as NOTES by default, if a specific kind has NOT been specified in the email or specified in a malformed way.
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.
Just for my edumacation...what are the various inroads for SPAM? Are there numbers on how much SPAM each of these methods accounts for? (percentage-wise)
+ Dictionary spam
+ Phishing for email addresses
+ I give an email address out to sketchy company x - they sell my email address to spammers
+ I get a virus that goes through my address book and spams all the email addresses I have in my address book
...Others?
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?
I think I've been imagining that the whitelist + quarantine workflows would be done in the Dashboard. Items queue up and until you 'approve them' they don't end up on the calendar as events or on task lists as tasks. They're events wrapped in a bubble layer of generic 'Note-ness', so-to-speak. I've talked to bkirsch about this from a stamping/communications perspective 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.
What if we have our own contacts list? e.g. The project Ernesto is working on:
http://wiki.osafoundation.org/bin/view/Journal/AddressBookProject