Bugzilla

(In reply to Jorg K (CEST = GMT+2) from comment #9)
> Note the tips in bug 1468959 comment #1 and the longer discussion in bug 1577082 comment #4. Apparently it's related to which e-mail is associated with the calendar:

As usual, Jörg was providing all the useful answers, as one of the comments he pointed out seems to have the full explanation for the current unexpected behaviours. If this description is correct,  the algorithm for finding the right sender to accept the invite is completely flawed as it won't even try sending from the attendee address first. Also this involves more than the email address associated to the receiving calendar, as there are other fallback mechanisms which can also result in TB's default account to be used for sending, which might explain why some users including myself have reported that (but it could also be that the default address is associated to the receiving calendar).

So the comment reports the following fallback sequence:
When accepting an event invitation sent to foo@bar.com as invited attendee and received with TB, try (in order of preference):
1) send with **email address associated to receiving calendar** (which may or may not be foo@bar.com - nonsense! this bug. I guess when you create a calendar, it will be populated with your default email, but you won't know about it, or forget.)
2) if no email address associated with that calendar: "try to guess a sending identity based on foo@bar.com"; I understand that's the same as: try to send using **attendee address (foo@bar.com**; this should be used first! I also wonder if the guessing algorithm works right - because that should typically not fail for the receiving account except when emails are internally redirected and received with bar@baz.com)
3) If 1) and 2) fail, fall back to using **TB's default account address**for sending (which may or may not be foo@bar.com - this bug).

I think 1) and 2) need to be swapped.
- first try to send using an address which matches the attendee address (which will typically be the receiving account, so we can check that first if it matches).
- then use the address associated to receiving calendar
- if all else fails, use default address

Expecting users to create a calendar for each of their accounts does not make sense.

(In reply to [:MakeMyDay] from Bug 1468959 Comment 1)
> Is there an identity configured for the calendar, the event was stored into
> when accepting the invitation? Was that different then A?
> 
> For sending replies the email identity configured in the respective calendar
> properties (available from context menu in the calendar list in the
> calendar/task view tab) is primarily used. If there's none, Lightning tries
> to make a guess based on the email recipient and ultimately falls back as a
> last resort to the system default email account. The latter is usually the
> case if the invitation was sent bcc or to a serverside resolved email list,
> so the email addresses configured in TB email identities cannot be resolved.
> 
> If you want to deal with email invitations and be safe to that regard, it is
> recommended to configure exactly one writable calendar for each TB email
> identity.

(In reply to Jorg K (CEST = GMT+2) from comment #9)
> Note the tips in bug 1468959 comment #1 and the longer discussion in bug 1577082 comment #4. Apparently it's related to which e-mail is associated with the calendar:

As usual, Jörg was providing all the useful answers, as one of the comments he pointed out seems to have the full explanation for the current unexpected behaviours. If this description is correct,  the algorithm for finding the right sender to accept the invite is completely flawed as it won't even try sending from the attendee address first. Also this involves more than the email address associated to the receiving calendar, as there are other fallback mechanisms which can also result in TB's default account to be used for sending, which might explain why some users including myself have reported that (but it could also be that the default address is associated to the receiving calendar).

So the comment reports the following fallback sequence:
When accepting an event invitation sent to foo@bar.com as invited attendee and received with TB, try (in order of preference):
1) send with **email address associated to receiving calendar** (which may or may not be foo@bar.com - nonsense! this bug. I guess when you create a calendar, it will be populated with your default email, but you won't know about it, or forget.)
2) if no email address associated with that calendar: "try to guess a sending identity based on foo@bar.com"; I understand that's the same as: try to send using **attendee address (foo@bar.com**; this should be used first! I also wonder if the guessing algorithm works right - because that should typically not fail for the receiving account except when emails are internally redirected and received with bar@baz.com)
3) If 1) and 2) fail, fall back to using **TB's default account address** for sending (which may or may not be foo@bar.com - this bug).

I think 1) and 2) need to be swapped.
- first try to send using an address which matches the attendee address (which will typically be the receiving account, so we can check that first if it matches).
- then use the address associated to receiving calendar
- if all else fails, use default address

Expecting users to create a calendar for each of their accounts does not make sense.

(In reply to [:MakeMyDay] from Bug 1468959 Comment 1)
> Is there an identity configured for the calendar, the event was stored into
> when accepting the invitation? Was that different then A?
> 
> For sending replies the email identity configured in the respective calendar
> properties (available from context menu in the calendar list in the
> calendar/task view tab) is primarily used. If there's none, Lightning tries
> to make a guess based on the email recipient and ultimately falls back as a
> last resort to the system default email account. The latter is usually the
> case if the invitation was sent bcc or to a serverside resolved email list,
> so the email addresses configured in TB email identities cannot be resolved.
> 
> If you want to deal with email invitations and be safe to that regard, it is
> recommended to configure exactly one writable calendar for each TB email
> identity.

(In reply to Jorg K (CEST = GMT+2) from comment #9)
> Note the tips in bug 1468959 comment #1 and the longer discussion in bug 1577082 comment #4. Apparently it's related to which e-mail is associated with the calendar:

As usual, Jörg was providing all the useful answers, as one of the comments he pointed out seems to have the full explanation for the current unexpected behaviours. If this description is correct,  the algorithm for finding the right sender to accept the invite is completely flawed as it won't even try sending from the attendee address first. Also this involves more than the email address associated to the receiving calendar, as there are other fallback mechanisms which can also result in TB's default account to be used for sending, which might explain why some users including myself have reported that (but it could also be that the default address is associated to the receiving calendar).

So the comment reports the following fallback sequence:
When accepting an event invitation sent to foo@bar.com as invited attendee and received with TB, try (in order of preference):
1) send with **email address associated to receiving calendar** (which may or may not be foo@bar.com - nonsense! this bug. I guess when you create a calendar, it will be populated with your default email, but you won't know about it, or forget.)
2) if no email address associated with that calendar: "try to guess a sending identity based on foo@bar.com"; I understand that's the same as: try to send using **attendee address (foo@bar.com**; this should be used first! I also wonder if the guessing algorithm works right - because that should typically not fail for the receiving account except when emails are internally redirected and received with bar@baz.com)
3) If 1) and 2) fail, fall back to using **TB's default account address** for sending (which may or may not be foo@bar.com - this bug).

**To fix this bug, I think 1) and 2) need to be swapped.**
- first try to send using an address which matches the attendee address (which will typically be the receiving account, so we can check that first if it matches).
- then use the address associated to receiving calendar
- if all else fails, use default address

Expecting users to create a calendar for each of their accounts does not make sense.

(In reply to [:MakeMyDay] from Bug 1468959 Comment 1)
> Is there an identity configured for the calendar, the event was stored into
> when accepting the invitation? Was that different then A?
> 
> For sending replies the email identity configured in the respective calendar
> properties (available from context menu in the calendar list in the
> calendar/task view tab) is primarily used. If there's none, Lightning tries
> to make a guess based on the email recipient and ultimately falls back as a
> last resort to the system default email account. The latter is usually the
> case if the invitation was sent bcc or to a serverside resolved email list,
> so the email addresses configured in TB email identities cannot be resolved.
> 
> If you want to deal with email invitations and be safe to that regard, it is
> recommended to configure exactly one writable calendar for each TB email
> identity.

(In reply to Jorg K (CEST = GMT+2) from comment #9)
> Note the tips in bug 1468959 comment #1 and the longer discussion in bug 1577082 comment #4. Apparently it's related to which e-mail is associated with the calendar:

As usual, Jörg was providing all the useful answers, as one of the comments he pointed out seems to have the full explanation for the current unexpected behaviours. If this description is correct,  the algorithm for finding the right sender to accept the invite is completely flawed as it won't even try sending from the attendee address first. Also this involves more than the email address associated to the receiving calendar, as there are other fallback mechanisms which can also result in TB's default account to be used for sending, which might explain why some users including myself have reported that (but it could also be that the default address is associated to the receiving calendar).

So the comment reports the following fallback sequence:
When accepting an event invitation sent to foo@bar.com as invited attendee and received with TB, try (in order of preference):
1) send with **email address associated to receiving calendar** (which may or may not be foo@bar.com - nonsense! this bug. I guess when you create a calendar, it will be populated with your default email, but you won't know about it, or forget.)
2) if no email address associated with that calendar: "try to guess a sending identity based on foo@bar.com"; I understand that's the same as: try to send using **attendee address (foo@bar.com**; this should be used first! I also wonder if the guessing algorithm works right - because that should typically not fail for the receiving account except when emails are internally redirected and received with bar@baz.com)
3) If 1) and 2) fail, fall back to using **TB's default account address** for sending (which may or may not be foo@bar.com - this bug).

**To fix this bug, I think 1) and 2) need to be swapped.**
- first try to send using an address which matches the attendee address (which will typically be the receiving account, so we can check that first if it matches).
- then use the address associated to receiving calendar
- if all else fails, use default address

**Also, before sending with anything else but the attendee's email address, Thunderbird must ask for confirmation! (privacy)**

Expecting users to create a calendar for each of their accounts does not make sense.

(In reply to [:MakeMyDay] from Bug 1468959 Comment 1)
> Is there an identity configured for the calendar, the event was stored into
> when accepting the invitation? Was that different then A?
> 
> For sending replies the email identity configured in the respective calendar
> properties (available from context menu in the calendar list in the
> calendar/task view tab) is primarily used. If there's none, Lightning tries
> to make a guess based on the email recipient and ultimately falls back as a
> last resort to the system default email account. The latter is usually the
> case if the invitation was sent bcc or to a serverside resolved email list,
> so the email addresses configured in TB email identities cannot be resolved.
> 
> If you want to deal with email invitations and be safe to that regard, it is
> recommended to configure exactly one writable calendar for each TB email
> identity.

(In reply to Jorg K (CEST = GMT+2) from comment #9)
> Note the tips in bug 1468959 comment #1 and the longer discussion in bug 1577082 comment #4. Apparently it's related to which e-mail is associated with the calendar:

As usual, Jörg was providing all the useful answers, as one of the comments he pointed out seems to have the full explanation for the current unexpected behaviours. If this description is correct,  the algorithm for finding the right sender to accept the invite is completely flawed as it won't even try sending from the attendee address first. Also this involves more than the email address associated to the receiving calendar, as there are other fallback mechanisms which can also result in TB's default account to be used for sending, which might explain why some users including myself have reported that (but it could also be that the default address is associated to the receiving calendar).

So the comment reports the following fallback sequence:
When accepting an event invitation sent to foo@bar.com as invited attendee and received with TB, try (in order of preference):
1) send with **email address associated to receiving calendar** (which may or may not be foo@bar.com - nonsense! this bug. I guess when you create a calendar, it will be populated with your default email, but you won't know about it, or forget.)
2) if no email address associated with that calendar: "try to guess a sending identity based on foo@bar.com"; I understand that's the same as: try to send using **attendee address (foo@bar.com**; this should be used first! I also wonder if the guessing algorithm works right - because that should typically not fail for the receiving account except when emails are internally redirected and received with bar@baz.com)
3) If 1) and 2) fail, fall back to using **TB's default account address** for sending (which may or may not be foo@bar.com - this bug).

**To fix this bug, I think 1) and 2) need to be swapped.**
- first try to send using an address which matches the attendee address (which will typically be the receiving account, so we can check that first if it matches).
- then use the address associated to receiving calendar
- if all else fails, use default address

**Also, before sending with anything else but the attendee's email address, Thunderbird must ask for confirmation! (privacy)**

Expecting users to create a calendar for each of their accounts/identities does not make sense.

(In reply to [:MakeMyDay] from Bug 1468959 Comment 1)
> Is there an identity configured for the calendar, the event was stored into
> when accepting the invitation? Was that different then A?
> 
> For sending replies the email identity configured in the respective calendar
> properties (available from context menu in the calendar list in the
> calendar/task view tab) is primarily used. If there's none, Lightning tries
> to make a guess based on the email recipient and ultimately falls back as a
> last resort to the system default email account. The latter is usually the
> case if the invitation was sent bcc or to a serverside resolved email list,
> so the email addresses configured in TB email identities cannot be resolved.
> 
> If you want to deal with email invitations and be safe to that regard, it is
> recommended to configure exactly one writable calendar for each TB email
> identity.