Vitriol

From brainsik
Jump to navigation Jump to search

ToDo

  • per user, need to store which forums or threads (think about this) they are receiving via email.
    • ross wants to be able to stop receiving emails for a particular thread on a single mailing list
  • check out the mosuki nonce table which is used for both email replies and forgot-password nonces. perhaps replace the reply_email table with a nonce table.

Schema

_base
id Integer primary_key = True, index = True
created DateTime nullable = False
updated DateTime nullable = False
user INHERITS _base
id Integer primary_key = True, index = True
created DateTime nullable = False
updated DateTime nullable = False
nick Unicode(127) nullable = False
last_login DateTime
user_email INHERITS _base
id Integer primary_key = True, index = True
created DateTime nullable = False
updated DateTime nullable = False
address Unicode(320) nullable = False
owner → user(id) nullable = False
primary Boolean nullable = False
verified Boolean nullable = False
reply_from Boolean nullable = False
bounce Boolean nullable = False
openid
openid_url Unicode(512) primary_key = True
owner → user(id) nullable = False, index = True
created DateTime nullable = False
forum INHERITS _base
id Integer primary_key = True, index = True
created DateTime nullable = False
updated DateTime nullable = False
title Unicode(127) nullable = False
thread
id Integer primary_key = True, index = True
created DateTime nullable = False
updated DateTime nullable = False
forum_id → forum(id) nullable = False, index = True
post_id → post(id) nullable = False
thread_view
user_id → user(id) primary_key = True, index = True
thread_id → thread(id) primary_key = True, index = True
last_view DateTime nullable = False
post INHERITS _base
id Integer primary_key = True, index = True
created DateTime nullable = False
updated DateTime nullable = False
thread_id → thread(id)
in_reply_to → post(id)
owner → user(id) nullable = False
title Unicode(127) nullable = False
body UnicodeText nullable = False
body_updated DateTime
mutable Boolean nullable = False
email_reply
reply_key Integer primary_key = True, index = True
post_id → post(id) nullable = False
user_id → user(id) nullable = False
created DateTime nullable = False
times_used Integer nullable = False

Reply by Email

Users who receive forum posts or private messages by email can reply directly from their mail program. We do this by including a reply key in the forum post email. The reply key identifies the user who received the email and the post to reply to.

There are a few ways we can go about configuration.

  • Highly: Add two columns to the email_reply table which specify the max number of uses and expiration date. These can be set on a per message basis.
  • Moderately: Add a 'class' column to the email_reply table and have settings for each class of messages (e.g., public posts versus private messages)
  • Minimally: Use a global setting.

How is the reply key embedded in email? The original way we did this was to use it as part of the "Reply-To" address. This has the unfortunate side-effect of filling a user's "previously used address" list with bad addresses – often attached to the names of people they regularly email.

Other approaches would use either the subject or body of the message. The problems with these is mangling/destruction of the key. However, this is the way much mailing list software does verification and the regular user generally top-replies, leaving the entire quoted body untouched.

How do we protect the site when reply keys are leaked?

  • keys expire
  • keys can only be used a limited number of times
  • email envelope "From" header must match one of the user's verified addresses

What can I do with a stolen reply key? You can send replies as the user the key was generated for. You have to send your email from an address that matches one of the original users' verified address.