Identity detection should be based on Envelope-To

UNCONFIRMED
Unassigned

Status

Thunderbird
Account Manager
--
major
UNCONFIRMED
5 years ago
4 years ago

People

(Reporter: Bachsau, Unassigned)

Tracking

(Depends on: 1 bug)

24 Branch
x86
Linux

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
User Agent: Opera/9.80 (X11; Linux i686) Presto/2.12.388 Version/12.15

Steps to reproduce:

I set a different archive folder for an alternative identity on the same account.


Actual results:

Some e-mails were archived correctly but most of them were not. Especialy mail from lists were always archived in the default folder.


Expected results:

E-mails should be separated correctly based on Envelope-To header.
(Reporter)

Updated

5 years ago
Severity: normal → major
(Reporter)

Updated

5 years ago
Component: Untriaged → General
> Actual results:
> Some e-mails were archived correctly but most of them were not.

Are you loking phenomenon of bug 819392?

> Expected results:
> E-mails should be separated correctly based on Envelope-To header.

As known by bug 819392 comment #24, currently used header in Archive is Delivered-To: only. Open sepatate enhancement bug for Envelope-To: header, please.
> http://mxr.mozilla.org/comm-central/source/mail/base/content/mailCommands.js#55
> 55   function findDeliveredToIdentityEmail()
can be enhanced to findSomethingToIdentity(HeaderName) where HeaderName = Dlivered-to:, Envelope-To:, etc...
(Reporter)

Comment 2

5 years ago
Delivered-To does not always exist, but Envelope-To does.
(In reply to Bachsau from comment #2)
> Delivered-To does not always exist, but Envelope-To does.

Which is actual problem of this bug?
(one problem per a bug is rule at bugzilla.mozilla.org)

(A) May be similar phenomenon to bug 819392, in which "archive setting of currently selected mail's identity is used when multiple mails are selected at thread pane whe archive is requested" is involved. 
> Actual results:
> Some e-mails were archived correctly but most of them were not.

(B) Enhnacement request to use Envelope-To: header in Archiving of Tb.
> Expected results:
> E-mails should be separated correctly based on Envelope-To header.
(Reporter)

Comment 4

5 years ago
(In reply to WADA from comment #3)
> Which is actual problem of this bug?
> (one problem per a bug is rule at bugzilla.mozilla.org)

The actual problem is that most e-mails are not correctly sorted into the folders that belong to the identity of the receiving adress.
(In reply to Bachsau from comment #4)
> The actual problem is that most e-mails are not correctly sorted into
> the folders that belong to the identity of the receiving address.

What is "correctness of 'moved to folder choice' in Archive of Tb"?

(1) As I wrote in bug 871326 comment #8, "Archive in Tb" was initially designed as "per account" feature, with supporting next;
- When Global Inbox is used and mail is moved to Inbox of "Local
  Folders", add X-Account-Key: accoutN header.
- When Archive, choose archive setting of account set in X-Account-Key.
(2) And, as seen in phenomenon of "archive setting of a mail(looks currently selected mail) is used by Archive when multiple mails are selected", Tb doesn't always check archive setting of each mail of multiple selected mails. A reason of such behavior is that archive is initially designed as "per account" basis.
(3) And, Copies&Folder panel was chosen as "place to set archive folder", because "archive folder choice" is almost same as draft/sent folder choice. Unfortunately, Copies&Folders was/is "per identity" setting. Fortunately, "Copies&Folder of per identity setting" works pretty well even for "Archive" setting. And, archive code fortunately processes the "per identity archive setting" well.
So, if only one mail is selected at Thread pane and Archive is requested, Archive works as if "per identity feature".

Cause of inconsistent behavior in Archive of Tb is:
  Current "Archive in Tb" is partially "per account feature"
  and partially "per identity feature".
AFAIK, decision on "per account feature" or "per identity feature" is not done. Some parts of code was written as "per account" feature and other parts was written as "per identity" feature.
Cause of inconsistent behavior in Archive of Tb is never "Envelope-To: header is not used in determination of move target folder".

If "per account feature", correct action is removing "per identity" part.
If "per identity feature", correct action is supporting "per identity" properly everywhere.
Because current Archive can work as "per identity feature" if only one mail is selected, I don't think "forcing archive=per account" is mandatory.
Do you use Global Inbox? Do you move mails downloaded via POP3 account to other account of Tb?
If one of two answers is Yes, and if you do Archive with selecting multiple mails at Thread pane, following phenomenon perhaps can be observed.
  All mail is moved to archive folder for an identity of X-Account-Key:
  (usually first identity) of a selected mail(perhaps currently selected
   mail). i.e. X-Account-Key: of other mails is ignored.
Isolate such phenomenon, please.
Bachsau(bug opener), do you see "move to unexpected archive folder by Archive" even by "Archive with selecting only one mail at Thread Pane"?
Depends on: 819392
(Reporter)

Comment 8

5 years ago
I didn't know this issue is special to the archive function.

> Do you use Global Inbox?
Yes and I also have multiple adresses delivered to one inbox that I want to be archived in different folders.

> Do you move mails downloaded via POP3 account to other account of Tb?
No, but I sometimes do with mails downloaded via IMAP, and I don't try to archive those mails.

> do you see "move to unexpected archive folder by Archive" even by "Archive with selecting only one mail at Thread Pane"
Will have to test that for a while...

> "Archive in Tb" was initially designed as "per account" feature
Needs to be changed. Copies&Folders are per Identity for good reason, and we need archive function to follow that. It must be changed to check the headers of each and every mail selected.

See, I have an adress that mostly only receives Mails. I don't want an extra account for it, because I don't need separate drafts, inbox, sendt and templates folders. But I want them to be archived separately from all other mails on that account to keep them organized later.
(In reply to Bachsau from comment #8)
> I didn't know this issue is special to the archive function.

"Identity selection based on some message header data" part itself is not archive only phenomenon.
- In Reply, "account selection for identity selection for pre-set From:
  address of Reply mail" is also based on X-Accout-Keys: which is
  written always if downloaded from POP3 server.
- In Reply, Envelope-To: header is not looked too.
This is because same routine is used by Reply and Archive.
See bugs listed in dependency tree for meta bug 699681, please.

In Reply, problem by "Reply to self" is Reply unique issue.
If "Reply to self", mailnews.reply_to_self_check_all_ident is relevant.
In Archive, "per identity archive folder selection, archive_granularity" can work, but "mail.identity.idN.archive_enabled of non-default identity(non-first identity)" is not currently read, because Archive was originally "per account" feature, even after the "per identity mail.identity.idN.archive_enabled" is saved after fix of Bug 871326.

If folder owner is "Local Folders", accociated identity doesn't exist. Because of this, Tb looks to use "all identities of all accounts" in identity selection, if folder owner is "Local Folders" and if X-account-Keys: doesn't exist in mail or accountX specified in X-Account-Key: is not defined in Tb.
If account is deleted and re-defined, or if mail is imported from other Tb, "non-existent account in X-Accout-Key:" may happen. Further, "account specified in X-Account-Key: == Local Folders or Smart Folders which doesn't have associate identity" may occur.
Because you have many POP3 accounts and use Global Inbox, please be careful in understanding and/or analysis of problem/symptom what you see.
FYI.

If IMAP, X-Account-Key: is not written, even when Offline-use=On folder. So, as far as mails are kept in IMAP folder, "account who owns the IMAP mail folder" is always used by Tb's "X-Account-Key: based identity selection", even after mail move between IMAP accounts.
This is big difference of IMAP case from POP3 case.

If "copy/move mail from IMAP folder to POP3 folder(and Local Folders)" is executed, "mail with no X-Mozilla-Keys:" happens in local mail folder.

When "copy/move mail from POP3 folder(and Local Folders) to IMAP folder", IIRC, Tb removes X-Account-Key: upon upload. So, "mail with X-Mozilla-Keys: header in IMAP folder" usually doesn't occur. However, if copy/move/transfer of mails is repeated, "mail with X-Mozilla-Keys: header in IMAP folder" may happen even in IMAP folder.
If "mail with X-Mozilla-Keys: header" happens, Tb's "X-Account-Key: based identity selection" is applied even when IMAP folder.

Please be careful in undestanding phenomena what you see.
(Reporter)

Comment 11

5 years ago
Tested this for a few days now, and still observe this phenomena for mailing lists but now for other mails, and I still think this could be fixed by using "Evenlope-to".
(In reply to Bachsau from comment #11)
> I still think this could be fixed by using "Evenlope-to".

Do yu understand test result of bug 819392 comment #26 and comment #27(contains correction of 26) on Delivered-To: header?
(Reporter)

Comment 13

5 years ago
No. I think this another problem. Not checking the identity of all mails out of a set of selected mails is one thing. Using the wrong header to detect identities is another. I don't realy get what you want to tell me.
(In reply to Bachsau from comment #13)
> I don't realy get what you want to tell me.

What I want to tell you is;
  As seen in bug 819392 comment #26 which is test of Delivered-To: case,
  even if Deliverd-To: header exists in mail and Tb actually has check
  logic on Deliverd-To:, if multiple mails are selected,
  Tb's Archive currently works as "per account feature"(initial design),
  because identity is selected based on only one mail in selected
  multiple mails.
  "Repeatedly saying 'Envelope-To: header is not checked is cause of
  problem' and 'checking Envelope-To: fixes all problems', with ignoring
  the fact and with ignoring 'X-Account-Key: is used in identity
  selection in Archive of Tb'", is nonsense.
As known by bug 819392 comment #26, Tb surely checks Delivered-To: header. Recently, many servers add Delivered-To:.
Are you talking about "no your identity in To:, CC:, no Delivered-To:, but your identity in Envelope-To:" case? (i.e. usable one is Envelope-To: only)
Or talking about "no your identity in To:, CC:, your identity in Delivered-To:, and your identity in Envelope-To:" case?

If Delivered-To: is also contained in message source, do you see your problem by "select only one mail at Thread Pane, and Archive"?
If "no Delivered-To:, Envelope-To: only is usable", do you see your problem by following? (emulation of Envelope-To: check)
(1) Create a local mail folder under relevant account in Tb(call FolderX),
    save the mail as .eml file(call email.eml),
    edit email.eml, change Envelope-To: header to Delivered-To: header,
    (search Google for format of each header by yourself, please)
    drag email.eml to Thread pane of FolderX(import by Drag&Drop of .eml)
(2) Select the mail(only one mail), Archive.
(In reply to Bachsau from comment #2)
> Delivered-To does not always exist, but Envelope-To does.

"Envelope-To: always exists" is never "always true in any place".
(1) Envelope-To: is added by SMTP server,
    and many of them looks to add the header.
    However "SMTP server doesn't add Envelope-To:" is permitted action.
(2) Envelope-To: is added by SMTP server based on RCPT command of SMTP.
    So, there is no reason to add Envelope-To: header
    when mail is sent via non-SMTP.
    Example.
    Mail from Gmail account to Gmail account via Web mail.
    There is no need to use actual SMTP server in this case.
    And, even if SMTP is used in internal system of Gmail,
    Gmail's program can skip "add Envelope-To:" freely.
    Gmail doesn't look to add Envelope-To: when mail is sent from Gmail
    account to Gmail account via Gmail's SMTP, even though the mail is
    actually passed from mail client to Gmail's SMTP server using
    protocol named SMTP via network.

Please don't ask Tb's code change based on not-always-correct assumption.
(Reporter)

Comment 18

5 years ago
> If Delivered-To: is also contained in message source, do you see your problem by "select only one mail at Thread Pane, and Archive"?

Most of my mails don't have that header, so I couldn't try this. This is why I complained about Envelope-To. I have to admit that I haven't read about when Envelope-To is added. I just observed that most if not every of my mails have that header present, while Delivered-To is not. And that it always contained the correct identity adress.

> Are you talking about "no your identity in To:, CC:, no Delivered-To:, but your identity in Envelope-To:" case? (i.e. usable one is Envelope-To: only)

This is exactly what I was talking about. I receive lots of mail from mailing lists. In one of my mailboxes they contain Delviered-To-Headers, but with only the adress of the mailing list in Delivered-To and my adress in Envelope-To. So maybe you could use Delivered-To as a fallback if Envelope-To is not available, as I never saw anything but my identys adress in it.

> Please don't ask Tb's code change based on not-always-correct assumption.
I wan't it to correctly select Identity in every case. I don't really care how it does as long as it works, and currently it does not.
(In reply to Bachsau from comment #18)
I receive lots of mail from
> In one of my mailboxes they contain Delviered-To-Headers, 
> but with only the adress of the mailing list in Delivered-To
> and my adress in Envelope-To.

It indicates;
 (a) Relevant server(s) add Envelope-To:
 (b) Relivamt server(s) add Delivered-To: too
IIUC, one of major purposes of Delivered-To: is "to avoid mail transfer loop", so "final recipient==mail address requested by RCPT" should be written in Delivered-To: if Delivered-To: is added, although "Delivered-To: == final recipient" is never "MUST" and there is no official law/rule on Delivered-To:.

"only the adress of the mailing list in Delivered-To" in your case is simply a bad or wrong implementation in servers which are relevant to mail sending/receiving of the mail, isn't it?

Needless to say, "No identity in To:/CC:, no Delivered-To: header, your identity in Envelope-To:" case,
  sent as BCC:,
  optional Delivered-To: is not written,
  optional Envelope-To: is fortunately written
is relieved by "adding check of Envelope-To: to Archive feature of Tb".
(In reply to Bachsau from comment #18)
> > Are you talking about "no your identity in To:, CC:, no Delivered-To:, but your identity in Envelope-To:" case? (i.e. usable one is Envelope-To: only)
> This is exactly what I was talking about.

If so, because Tb's Archive doesn't check Envelope-To: header as known by bug 819392 which I already pointed, "moved to 'default folder'" is pretty normal, and it is working as designed/implemented currently.
So, enhancement request of "add Envelope-To: check to Tb's archive" is reasonable request.

However, your answer of comment #4 was "not such enhancement request", and your claim still sounds that "incorrect", "not correct", ..., so fix problem by adding Envelope-To: header check...

Question again. (similar to comment #3)
What is actual problem of this bug and what is actual request by this bug?

Comment 21

4 years ago
(In reply to WADA from comment #20)
> (In reply to Bachsau from comment #18)
> > > Are you talking about "no your identity in To:, CC:, no Delivered-To:, but your identity in Envelope-To:" case? (i.e. usable one is Envelope-To: only)
> > This is exactly what I was talking about.
> 
> If so, because Tb's Archive doesn't check Envelope-To: header as known by
> bug 819392 which I already pointed, "moved to 'default folder'" is pretty
> normal, and it is working as designed/implemented currently.
> So, enhancement request of "add Envelope-To: check to Tb's archive" is
> reasonable request.
> 
> However, your answer of comment #4 was "not such enhancement request", and
> your claim still sounds that "incorrect", "not correct", ..., so fix problem
> by adding Envelope-To: header check...
> 
> Question again. (similar to comment #3)
> What is actual problem of this bug and what is actual request by this bug?

Bachsau ?
Component: General → Account Manager
Flags: needinfo?(web)
(Reporter)

Comment 22

4 years ago
I don't want to take this weird, geeky discussion further.
The purpose of this bug is: Make the archive button work as the averange dumb user would expect it to work. One can select an archive folder for every identity and expects the archive button to move selected mails to the folder selected for every individual mail. Thunderbird should use every header, any information available, whatever posible, to detect that folder. Period.

If no one's willing to fix problems in a practical way, thunderbird will remain broken.
Flags: needinfo?(web)
(Reporter)

Comment 23

4 years ago
PS: And what the user expects is, a mail is considered as belonging to the identity the foreign mail server sendt it to by means of "Mail for ...", even if "To/Cc" contains a list adress or anything else.
You need to log in before you can comment on or make changes to this bug.