Closed Bug 1385839 Opened 7 years ago Closed 7 years ago

"Reply to self": Reply-to not honoured. From: equals To: and BCC used triggers "reply to self"

Categories

(Thunderbird :: Untriaged, defect)

54 Branch
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: thomas, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170628075643

Steps to reproduce:

We have multiple different websites that send (ecommerce order related) emails to the store with a copy to the recipient.

Incoming email:
     TO = FROM (the store's email, 'self'),
     REPLY-TO = customer email,
     BCC is in use, but to a different email address.

In all cases this is sent via Google for Business hosted email accounts.
I have tried deleting address book entries of 'self', but to no avail. If I locate the email in the "sent" folder (which will have a copy due to sending from the same account), both reply options work as expected.


Other users appear to have experienced a very similar issue, where replying to a mailing list sends an email to 'self' instead of to the list's reply-to address.


Actual results:

Clicking "REPLY" composes a response with:
     TO = store's email (incorrect)
     REPLY-TO = same REPLY-TO as from incoming email (incorrect)

Clicking "REPLY ALL" composes a response with:
     as above
     + BCC = BCC as from incoming email (appears to defeat the point of BCC, but this could be due to sending from self to self - i.e. it probably isn't necessary to hide BCC from self)


Expected results:

The expected behaviour in both cases would be:
     TO = REPLY-TO of incoming email (in this case the customer's email)
     NO OTHER RECIPIENTS
Ignoring Reply-To for mailing list replies is a different issue, see bug 1309486.

I've set up a case as described and can confirm that the "reply to self" ignores "Reply-to".

With something like this:
BCC: henk@henk.com.au
To: huhu@jorgk.com
From: jorgk@jorgk.com (that's me)
Reply-To: haha@jorgk.com

I'm triggering the reply-to-self logic which basically repeats the same e-mail as observed:

To: huhu@jorgk.com
From: jorgk@jorgk.com
Reply-To: haha@jorgk.com
(BCC included again when Reply All is used).

I don't think we're going to change that. Magnus?
Flags: needinfo?(mkmelin+mozilla)
Am I to understand that this current behaviour is intentional in the "reply to self" case?

If so I'd say that the ecommerce setup I have described above is a very common use case.
What exactly is the reason for not honouring reply-to in this scenario?
Or to phrase this question another way: Who would send an email to themselves and set a reply-to header, if not for a deliberate and calculated reason based on the expectation that it would be honoured?

If there is no wish to "upset the balance" and keep the current behaviour as standard, would it at least be possible to create some kind of option (a flag in advanced settings only is fine) that would allow the (arguably more intuitive) behaviour that I have described?
Let me first state that all our unpaid volunteers like to work hard to make the product more suitable for your e-commerce application.

Coming back to the issue here: Yes, if you reply to a message sent by yourself, you generally trigger TB's "reply to self" case which is different to a normal reply. If you reply to such a message, you usually don't want the reply to go to yourself again, but to the recipient. Are are exceptions to the "reply to self" rule, for example if To: equals From:, but read on how BCC enters the play.

"Reply to self" cannot be switched off, there is only a preference mailnews.reply_to_self_check_all_ident that can make it worse by checking all identities for a "self match".

"Reply to self" is coded here:
https://dxr.mozilla.org/comm-central/rev/f593d2d106c15ad9682a35eaa1a8679e7127acd6/mailnews/compose/src/nsMsgCompose.cpp#2701

Reading a little further on
https://dxr.mozilla.org/comm-central/rev/f593d2d106c15ad9682a35eaa1a8679e7127acd6/mailnews/compose/src/nsMsgCompose.cpp#2717
we see:

// However, "From:me To:me" should be treated as
// reply-to-self if we have a Bcc. If we don't have a Bcc we
// might have the case of a generated mail of the style
// "From:me To:me Reply-To:customer". Then we need to do a
// normal reply to the customer.

So you have three options:
1) Don't add a BCC or don't reply to the message which has the BCC, typically the
   message in the sent folder. The received message shouldn't have the BCC, right?
   Then the system will work already as you desire.
2) Change the From: to something else. Then you won't trigger the "reply to self" behaviour.
3) Move the message from the sent folder which is usually associated with the From: account
   to a (local) folder not associated with the account. Then you also won't trigger
   the "reply to self" behaviour (unless mailnews.reply_to_self_check_all_ident is true).
   The received message in the inbox surely also won't have the BCC, right?

I'm a little confused by your comment #0:
If I locate the email in the "sent" folder (...), both reply options work as expected.

I thought the message in the sent folder will trigger the undesired behaviour since it has the BCC in it, no? The received message in the inbox shouldn't trigger the undesired behaviour since it has no BCC.

What am I missing?
Summary: Reply/reply to all: "Reply-to" not honoured, BCC exposed → "Reply to self": Reply-to not honoured. From: equals To: and BCC used triggers "reply to self"
These are good pointers, thank you.

> I'm a little confused by your comment #0:
> If I locate the email in the "sent" folder (...), both reply options work as expected.

I was in fact mistaken, sorry. Both emails look the same and both trigger the (for me undesirable) behaviour. I must have clicked on one that was addressed to the customer, in which case it replies to the customer, who in that case would also have been the original recipient.


I have now tried both your suggestions, by sending a message from a different identity on the same account in Google Mail.
Result is that as expected I could confirm both your workarounds 1) and 2) as valid.

Some additional notes:
Workaround 1)
    The inclusion of an identity is irrelevant when not using BCC.
Workaround 2)
    Reply-to-self is still triggered with "TO=self" if Thunderbird knows the FROM email as an identity
    (added in "Manage Identities" in account settings). It doesn't seem to matter whether it is really an alias.
    It is NOT triggered if Thunderbird does not know it as an identity.


This is good news for me, as I now have an effective workaround (as per your suggestion 2) - change the originating email address and do not add it as a known identity in TB).
I am not 100% convinced that the behaviour is intuitive (especially as not really documented - maybe this entry helps), however, unless anybody else is experiencing this as an issue, I'm happy to have this resolved as "works for me" or "workaround available". I do not know what the "industry standard" is in dealing with these special cases, so I just assume that you've probably got it working the same way as everyone else. No wonder then the proliferation of "no-reply@"...

Thanks again for your helpful suggestions.
By the way, I do not know why the incoming emails have the BCC on them. Perhaps this is a quirk in Google Mail, which may treat both the sent and incoming mail as the same object? In a sense you haven't really "sent" the email to yourself, but simply tagged it to appear in both "sent" and "inbox". That would explain this slight curiosity and is not something that TB could possibly address.
(In reply to Thomas from comment #4)
> These are good pointers, thank you.
It took me hours to look at your problem. I even ran TB in the debugger to verify my suggestions.

> I am not 100% convinced that the behaviour is intuitive (especially as not
> really documented - maybe this entry helps), ...
I'm also not even 80% convinced ;-) That "reply to self" case has some really twisted code and until I read through it, I didn't know that BCC comes into play as well. I'll close the bug.

> Thanks again for your helpful suggestions.
https://donate.mozilla.org/en-US/thunderbird/ ;-)
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Flags: needinfo?(mkmelin+mozilla)
Resolution: --- → INVALID
> https://donate.mozilla.org/en-US/thunderbird/ ;-)
Done ;-)
You need to log in before you can comment on or make changes to this bug.