Accepting A Meeting By Selecting The 'Send Response' Option Causes Response To Be Sent Via Default SMTP Server And Not SMTP Server Associated With The Actual Account To Which The Meeting Request Was Sent
Categories
(Thunderbird :: Untriaged, defect)
Tracking
(Not tracked)
People
(Reporter: bugzilla_mozilla_org_001, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0
Steps to reproduce:
I replied to a meeting request and selected the 'Send Response' option.
Actual results:
This particular instance of Thunderbird handles numerous accounts / domains. Each domain has it's own SMTP server, but that server is used by all accounts for that domain (whilst the FQDN is the same for each domain, the names of the SMTP servers are different for each account associated with that domain). Thunderbird seems to make the somewhat arbitrary decision to make the default SMTP server that of the last account / domain added. Why is this, why have a default SMTP server at all (it's not possible to 'unset' or otherwise make null the default SMTP server)? Anyway, that's not the main issue.
The problem arises when a meeting request is sent to a given account associated with a given domain. When accepting the meeting request and electing to 'send a response' (as opposed to not doing so), instead of that response being sent out by the SMTP server associated with that account, it gets sent out by the default SMTP server which in this case was associated with a different account and domain. The issue is therefore, that meeting responses should be sent out via the SMTP server associated with the account and not the default SMTP server (unless there is no SMTP server associated with the account.
Expected results:
The meeting reply should have been sent from the SMTP server associated with the account and not the default SMTP server. The upshot of this is that the meeting organizer may see a response that appears to come from someone from a completely different organization.
|
||
Comment 1•5 years ago
|
||
Reporter,
Do you see this also when using version 78?
|
Reporter | |
Comment 2•5 years ago
|
||
I am attempting to reproduce this on version 78. I have attempted sending an event from one account to another (both known to Thunderbird). I created the calendar for one account, then created an event to which I invited the other account. However, when the event arrived in the other account's inbox, there was a message saying "This message contains an event that has already been processed", and, as such, did not offer any response options. The event was in the future, so not sure why it thought it had been processed already. If you could provide some sort of keystroke-by-keystroke idiot's guide, I'd appreciate it.
|
|
Reporter | |
Comment 3•5 years ago
|
||
I tried creating an event in GMail and sending it to one of my Thunderbird accounts. I responded from that (Thunderbird) account and the response, when received in GMail, appeared to come from the correct Thunderbird account (and not the default SMTP account), so the issue may have been resolved.
Resolved per whiteboard and Comment 3
|
||
Comment 6•4 years ago
|
||
I personally don't think this is resolved as I'm seeing this on v78.7.0 (64bit) Mac OS.
I have multiple email accounts on Thunderbird.
Let's simplify it to 2 accounts: [a@work.com] and [b@home.com]
[a@work.com] is my work email, [b@home.com] is my personal gmail.
I get sent a calendar invite to [b@home.com] - I click the 'accept' button for this. The response is sent from my work email [a@work.com] so the person creating the event now has an attendee that was not invited and my actual account has not responded.
Even setting the default SMTP to [b@home.com] (gmail) it is showing the event organiser that [a@work.com] is attending.
I would expect that the response to a calendar invite (.ics) would be sent as a 'reply' to the email account is was sent to (i.e. using that accounts SMTP settings etc).
|
||
Comment 7•4 years ago
|
||
(In reply to Matthew Morley from comment #6)
I personally don't think this is resolved as I'm seeing this on v78.7.0 (64bit) Mac OS.
Sure Matthew, we definitely have unresolved issues here.
Comment 3 wasn't very certain, and due to the intricate fallback sequence (see Bug 1562896 Comment 14) which allegedly involves first the email associated to the calendar, then the attendee address and lastly the default SMTP, it's not easy to understand what's going on. Let's mark this a duplicate of 1562896 until we're quite sure that we've fixed that somehow.
Description
•