This request duplicates the recently re-opened sr #106712.

comment #3:

> Let us imagine that the message with the hash is intercepted; then it would be possible for the interceptor to impersonate that user in that tracker item, wouldn't it?

Often, but the from address is often secured (some newfangled authorised mail-submission-agent system with DNS, I think) and you can check the security of the email path in those cases, so if the user has nominated a from address for a so-secured mail-exchange then you're alright in that case. I suggested the user might nominate an email signature certificate which can't be impersonated much more than the website login.

Even outside those cases, this is limited to commenting so you can clean up once you realise that a user has been impersonated and change the salts as often as you like. On the occasions that a salt has been changed before a user replies you can send out a new address for them to resend their reply to so you can even change the salt very often. If you allow this case then you can indicate that the comment has no or little identity verification so people don't act as if such a comment was an authority. Alternatively or in-addition, on occasion a user could log in and validate the identity of comments sent by email and you could make that easy by sending a digest with a validation link either before or after the emails are spooled into comments. It would still be more practical to converse on development topics than interrupting a user workflow with website visits and the website login process injected between thoughts. The advantage of sending a digest with validation request is that this most awkward case can be handled with a spool separate to the rest of the system.

You currently send a notification email for comments on bugs with the reply address configured as some invalid address like INVALID.NOREPLY@gnu.org.

You could construct an email address like <hash>@savannah.nongnu.org where <hash> is a cryptographic checksum of a string like:

sitesalt,usersalt,username,sr #110907,comment1

where usersalt is a number, incremented whenever spoofing is discovered (for example, if an email has been published including its addresses). There are various schemes you might want to use such as sitesalt,usersalt,referencesalt,username,srnum,comment1 where referencesalt is a salt for the service request which can be changed when spoofing is discovered, etc.

You might want to validate the From address against addresses the user has nominated in their settings. You might prefer to allow users to load several public certificates used to sign their emails instead of or in addition to using salts and validated From addresses.

You might be able to use standard headers used to reference messages in message board systems if email clients still follow the RFCs these days instead of relying on the reply-to address but I would expect a lot of email composers don't bother any more.


I would expect this is a solved problem by now with well-known solutions.

It would be much much better if we could reply to comments about bugs. NNTP would be better than email (especially a newsgroup for each bug), but if an email could have a reply-to address with an encrypted triple of user credential, comment ID, and issue number in it so you don't receive spam even though it's trivial to reply then that would also be better than what we currently have.