identity_select: match received header in reverse order (#10158)#10159
identity_select: match received header in reverse order (#10158)#10159johndoh wants to merge 4 commits into
Conversation
|
After looking at this some more, and testing it on more emails in my inbox, I think there is a problem. The get_email_from_header() function claims to return an array, and then the select() function checks each identity in turn until it finds an in_array() match. But get_email_from_header() always returns an array with one element - the first email address that it finds. (Or, it can fail to find an email address, in which case it seems to return either a null array or the array of raw headers matching the search term, both of which are even wrong-er.) The problem is that a mailing list might preserve headers from before the email gets listified. In that case, the email addresses in the headers will be: mailbox address In one email that I'm looking at, the bottom (oldest) received: header is: Received: from blah blah Searching from either the top or the bottom gives the wrong result for these emails. Maybe something like this: |
|
With my version, I don't think there is any point in reversing the headers. The identity that will be selected is the first one in the $p['identities'] array, in whatever order foreach() presents them, that matches any email address in any of the user-selected headers. On my system, the first identity on the Settings/Identities page is my real mailbox name, and then the aliases are listed alphabetically. Maybe we should reverse that list in the select() function before giving it to foreach. |
|
I take your point about checking all the Received headers not just one but I think relying on the order of the identities is a mistake so instead I made it look for a matching identity in the (reverse) order of the Received headers. |
|
Looks good. Tested and working on my system. |
RFC 5321 says that additional
Receivedheaders should be prepended:I also adjusted the regex because having
<>around the email address is common but not required.closes #10158