1272223 - Feature request: Message compose window should warn user when replying to the message where recipient differs from sender due to header REPLY TO.

Status: UNCONFIRMED

(Thunderbird :: Message Compose Window, enhancement)

Description

[u571238]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/49.0.2623.108 Chrome/49.0.2623.108 Safari/537.36

Steps to reproduce:

1. Somebody sent incoming e-mail with different FROM and REPLY-TO headers. Please note that same situation might occur when SENDER and FROM headers aren't same.
2. User is not an IT expert - he does not know he will reply to another account than he might thought. Even IT expert can be inattentive for a while.
3. User hits "Reply" button, writes his reply and hits "Send" button.


Actual results:

Message is sent. Reply is sent to another account than original message came from and user is surprised (better case) or he does not noticed (usual case).


Expected results:

Message optionally could warn "Recipient differs from sender! Accept? [Yes] [No] [Learn more]".

Note: In my personal opinion it should be by default ON but this feature is breaking current behavior so it may by set at preferences optionally, default OFF.

Comment 1

[chrizilla]

Reporter makes very thoughtful points. This feature is a good countermeasure against email spoofing, phishing, email fraud and all sorts of scams. Not a cure-all of course, but an added protective layer.

This could be implemented in the same way users are warned about remote images:
yellow warning bar below the mail header with [x] to close.

I think the reporter's suggestion for the warning text is good, but could be further clarified, such as:
Sender asks you to to reply to a different address than the sender's address. Accept? [YES] [NO] [NO, use sender address instead] [learn more] [X]

Spontaneous thoughts for button behaviour:

• YES: warning disappears, no action is taken (i.e. TO address remains)
• NO: deletes the TO field
• NO, use sender address instead: the TO field (populated by REPLY-TO) is replaced by the sender address
• [X]: defaults to NO
• learn more: overlay/popup with a brief summary of the potential danger, like "If you don't know the sender, this could be a phishing attempt." (+ maybe also explaining the button behaviour ?)