If we did D, we would need to still be able to pass data:
* Proof that the reply came from replying to the mail, not via a newly-forged email. Replying by email is convenient, but we have to make sure that nobody can forge an email as somebody else.
* The journal name, entry ID and comment ID being replied to.
* Anything else?
Ideas on passing that information:
* We could pass the information as a hash in the subject line. However, this breaks threading in applications that use the subject line for threading, which to my knowledge includes GMail. It also looks a bit ugly, and could trigger spam filters.
* We could pass the information via a specially-formulated Reply-To address which would be parseable to give the info needed. (Note: We should *not* use the From address as a generic Reply-To address as this will mean that users can't add an address to their spam whitelists. That's something that really peeves me about Second Life offline IM notifications.)
* Others?
About the methods used to authenticate the email:
* For security, we should never just have the credentials as a single, standalone hash; this can be copied and used in forged emails very easily. This means that if credential hashing is used, we should *also* hash it with other data, like the entry and comment IDs, which is how it's currently done in the ECP hash. (I would suggest adding journal name to that hash too.)
* We could also use one-time hashes that are randomly generated by LJ for each email. However, doing this would mean both that the user would not be able to reply to the same comment twice from the same email, and also that we would need to expire the hash after a period of time - say, six months. The expirataion thing probably wouldn't be a problem, but I can see the first bit being annoying.
* There is little point in combining both methods, as the problems in the second point would still arise, and there will be no way to interactively ask for a username/password to confirm.
Random other comments:
* We will need to strip signatures and quoted text from the email. The DW code already strips signatures as part of the email posting mechanism, but I don't think it strips quoted text.
* We need to be able to have the capability to parse quoted-printable and/or HTML in case someone replies using that format. (this capability is probably already in email posting)
* Email programs tend to wrap emails to 78 characters a line. In the case where someone replied in plain text (not quoted-printable format or HTML), should we try to reconstruct the original lines or just leave the lines wrapped? (this question is also probably already answered in email posting, too)
Is there anything I've missed here?
(I'm personally still a fan of option (c) in your post; I think re-authenticating is a small price to pay in this case.)
no subject
* Proof that the reply came from replying to the mail, not via a newly-forged email. Replying by email is convenient, but we have to make sure that nobody can forge an email as somebody else.
* The journal name, entry ID and comment ID being replied to.
* Anything else?
Ideas on passing that information:
* We could pass the information as a hash in the subject line. However, this breaks threading in applications that use the subject line for threading, which to my knowledge includes GMail. It also looks a bit ugly, and could trigger spam filters.
* We could pass the information via a specially-formulated Reply-To address which would be parseable to give the info needed. (Note: We should *not* use the From address as a generic Reply-To address as this will mean that users can't add an address to their spam whitelists. That's something that really peeves me about Second Life offline IM notifications.)
* Others?
About the methods used to authenticate the email:
* For security, we should never just have the credentials as a single, standalone hash; this can be copied and used in forged emails very easily. This means that if credential hashing is used, we should *also* hash it with other data, like the entry and comment IDs, which is how it's currently done in the ECP hash. (I would suggest adding journal name to that hash too.)
* We could also use one-time hashes that are randomly generated by LJ for each email. However, doing this would mean both that the user would not be able to reply to the same comment twice from the same email, and also that we would need to expire the hash after a period of time - say, six months. The expirataion thing probably wouldn't be a problem, but I can see the first bit being annoying.
* There is little point in combining both methods, as the problems in the second point would still arise, and there will be no way to interactively ask for a username/password to confirm.
Random other comments:
* We will need to strip signatures and quoted text from the email. The DW code already strips signatures as part of the email posting mechanism, but I don't think it strips quoted text.
* We need to be able to have the capability to parse quoted-printable and/or HTML in case someone replies using that format. (this capability is probably already in email posting)
* Email programs tend to wrap emails to 78 characters a line. In the case where someone replied in plain text (not quoted-printable format or HTML), should we try to reconstruct the original lines or just leave the lines wrapped? (this question is also probably already answered in email posting, too)
Is there anything I've missed here?
(I'm personally still a fan of option (c) in your post; I think re-authenticating is a small price to pay in this case.)