Closed Bug 1342809 Opened 6 years ago Closed 1 year ago

Popup warning if answer to no-reply/noreply@ email address

Categories

(Thunderbird :: Message Compose Window, enhancement)

enhancement
Not set
normal

Tracking

(thunderbird_esr78 wontfix)

RESOLVED FIXED
91 Branch
Tracking Status
thunderbird_esr78 --- wontfix

People

(Reporter: marc, Assigned: mkmelin)

References

Details

Attachments

(1 file, 1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce:

I receive a email from "noreply@example.com" and answer to it.


Actual results:

I will likely get a mailer return for a non existent / not used mailbox.


Expected results:

If I click on "answer" it should popup a warning that this recipient would likely not receive mails as such addresses are mainly used for sending. In the ACP there should be an option to add more keywords like "no-reply".

The reason for this idea is mainly because of some of my forum users that try to answer notification mails. And do not think they answer to containing texts. Our notification mails contain only the link to the subscribed thread or pm. I know that because my noreply mailbox exists and I forward all "Re:" mails to our main mailbox and try to help those users to find the correct way to answer. But finally I think it would be better the mail program stops the user before sending such mails, because not many websites have an existing noreply-mailbox.
Summary: Popup warning if answer to noreply@ email address → Suggestion / Feature request: Popup warning if answer to noreply@ email address
Severity: normal → enhancement
Summary: Suggestion / Feature request: Popup warning if answer to noreply@ email address → Popup warning if answer to noreply@ email address

That's a good idea even if no other email clients would do that; my father gets (very) technical auto replies in (international) English, as both he and the site's server administrators are Dutch natives and slightly computer illiterate (with often better logic as I found out, in my view, and simpler requests).

I hope those sites are helped with it as well, by being notified through getting this message, (this report by Marc Gutt,)
https://bugzilla.mozilla.org/show_bug.cgi?id=1342809 Marc Gutt.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Popup warning if answer to noreply@ email address → Popup warning if answer to no-reply/noreply@ email address

I'd suggest we do it like this

When doing any of the reply commands, check From/Reply-To.
if (/no.?reply@/i.test(address)) {
Put up a confirmation.

--- Reply not supported ---

The address (noreply@...) indicates that this is not a monitored address. A reply likely won’t be read by anyone.

                                         [ Reply Anyway ] [ Cancel ]

}

If reply anyway, open the compose window. Otherwise cancel.

Probably code around here: https://searchfox.org/comm-central/rev/b4fe8bb2aada9ad78b5ff543bce5f8e76e4ef9a5/mail/components/compose/content/MsgComposeCommands.js#3515

Assignee: nobody → henry

Perhaps also cater for donotreply@. So if (/^(do)?no.?reply@/i.test(address))

Looking through my inbox I see quite a few which also have a prefix made of a-z/dashes/underscores (something account-noreply@foo) and a couple of do_not_reply@foo. Something more like [a-z-]*(do.)?not?.?reply@ might catch them all, but that could have false positives. :)

@Patrick, good idea. I checked mine, too:

90%:
noreply@
no-reply@

9%:
[A-Z]+-noreply@

1%:
no_reply@
donotreply@
no.reply@
no_reply@
SupportPortal-NotReply@
do-not-reply-here@
do-not-reply@
DoNotReply@
nicht-antworten@ (German for "do not reply")

Possible false-positive that contained "reply@":
cs-reply@

So it seems this could be sufficient:
.*not?.?reply@

(In reply to Marc Gutt from comment #6)

@Patrick, good idea. I checked mine, too:
So it seems this could be sufficient:
.*not?.?reply@

This would capture too much, such as notereply@ and knot-reply@. I would say

/^(.*[-_.])?(donot|not|no)[-_.]?reply([-_.].*)?@/i

Key points:

  1. Only accept the separators [-_.]. So we don't capture notereply. We could extend this with [_\p{Dash}\p{Terminal_Punctuation}] to capture more unicode symbols, but I think this is sufficient.
  2. If there is a prefix, it must end with [-_.]. So we don't capture knot-reply. Similar with a suffix.
  3. Only accept do and not in combination, as part of do-not-reply. Don't match dono-reply.

Out of the ones you listed, only the non-english versions will not match.

That's all great, I like that a lot.

In addition, I'd like to propose this line in the or an email footer (in the very email with the no_reply@[...] sender, put in by the sender), the 'message' being a popup or embedded somewhere, however the user likes it (footer can be hidden like the header, or cut off if the user don't want it, in total or just to keep the b[old], i, and u markup and cut off anything else):

%^%mdb
button reply=message en "Replies to this email address are not monitored. Please follow this link for the contact options: www.website.com, or call this number: 555 555 6. Our website and phone number are registered (publicly verifiable) at www.websites.gov"
%^%mdb.

For your judgement. You may use whatever you may think is relevant. Of course such a footer is useful for other stuff, like replacing HTML all together, making it redundant, or for specifying a password to your inbox, or for specifying a paragraph as source code to optionally syntax highlight, if installed, but the focus here is on the no-reply feature, in addition to and not replacing the handling of Thunderbird itself.

(In reply to bass from comment #8)

In addition, I'd like to propose this line in the or an email footer ...

I'm unsure about your suggestion. If you receive an email from noreply@website.com, do you want thunderbird to add a button that opens a new email composed to, for example, customer-query@website.com? If the organisation sending the email has such an address, it would be their responsibility to include a Reply-To field, or include the information within the email they send. Thunderbird would only get it wrong if it tried to guess an alternative email that accepts queries.

I found one Dutch variant:
geenantwoord@ ('geen antwoord')

Those were the significant versions I think.

@bass, please let's stay on focus here. We're not going to add anything to the message body. We'll just check the sending email and inform with a dialog based on that.

@Magnus, Check. Thanks for straighten me out.

The 91 string freeze is coming up Monday. Any progress?

(In reply to Magnus Melin [:mkmelin] from comment #16)

The 91 string freeze is coming up Monday. Any progress?

I tried to follow the approach you suggested using ComposeStartup, but I couldn't access the composeFields.to property in that method: all the fields are empty strings at this point, but if I print composeFields to the console and print the fields after the window is loaded they are set. I couldn't figure out the logic of the overall process to know where to access the field. And I wasn't sure of the location of the last bailing point before the window is (visually) loaded.

So I was going to ask you about it when you got back. I didn't know this was planned for the 91 release.

Please attach the WIP. It's hard to comment without code.

(In reply to Magnus Melin [:mkmelin] from comment #18)

Please attach the WIP. It's hard to comment without code.

There's no WIP to show, I just did some debugging once my first step failed. I just tried to print console.log(params.composeFields.to) in the place suggested (https://searchfox.org/comm-central/rev/4fe4d110e94220cccdd4cead5bc94c607a5e849c/mail/components/compose/content/MsgComposeCommands.js#3526) and it was empty. But printing the composeFields object to the console, and inspecting it in the Developer Tools Console later and the fields are set.

You can see what I mean using in the same place

  console.log(params.composeFields);
  console.log(`To: ${params.composeFields.to}`);
  console.log(`From: ${params.composeFields.from}`);
  console.log(`Reply-To: ${params.composeFields.replyTo}`);

Do you want something in before the string freeze? (what time is the deadline on the 12th?) Someone suggested that we could push a string only patch just for translators whilst we figure out the implementation.

The merge usually happen European early evening time.

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/5053b99a8b89
Popup warning if answer to no-reply/noreply@ email address. r=henry

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 91 Branch
Regressions: 1720214
Blocks: 1720214
No longer regressions: 1720214
Assignee: henry → mkmelin+mozilla

The message gets triggered for a newsgroup follow-up where the author's address is Someone <noreply@spambouncer.de>.

Please file a new bug about that.

Comment on attachment 9262647 [details]
Bug 1342809 follow-up: Don't check the address on newsgroup-only posts. r=rnons

Revision D138011 was moved to bug 1752741. Setting attachment 9262647 [details] to obsolete.

Attachment #9262647 - Attachment is obsolete: true

Could you reconsider to change the regex from

/^(.*[._-])?(do[._-]?not|no)[._-]?reply([._-].*)?@/

to

/^(.*[._-])?(do[._-]?not|no)[._-]?reply([._+-].*)?@/

? That is, allow "+" after the no-reply part as a separator to allow tagging the From address.

That would allow correctly detecting email address such as

no-reply+1342809@example.com

which I think would be sensible format for automated emails to encode information in the From address in case some mail agent allows replying to that address.

That sounds good. But let's do it in a new bug. Are you able to submit a patch?

You need to log in before you can comment on or make changes to this bug.