Should a favicon only be shown if the from address is in the SDID?

[lieser]

Currently the favicon is added only based on the signing domain (SDID). This could maybe cause confusion if a domain that is in the favicon list is also hosting a mailing list which is DKIM signed.

An example for this are the Thunderbird mailing list that are signed by discuss.thunderbird.net (https://thunderbird.topicbox.com/groups).
All mails send via this list currently show a Thunderbird logo before the sender, and not just for mails send by Thunderbird employees with a @thunderbird.net mail address.
As the lists do have a footer (and currently also add the list name to the subject, which was not the case in the past and may change again), it is hopefully clear that not everyone there is speaking in the name of Thunderbird.
But I could imagine that at least some do get confused by this, so I'm thinking about restricting it to showing the favicons only if the from address is in the SDID.

A similar think are e.g. the GitHub notification mails. A difference to the mailing list case is that there the from address is always [email protected], and only the display name of the address is set to the users display name who posted.
So all this notifications would still show the GitHub logo, and hopefully too will not get confused as messages from GitHub employees.

Would be nice to hear some opinions on this.

[dodmi]

Hi,
I really like your addon, which has done a great job here, for years. And I like to say thank you for discussing such a change before implementing it. Actually, I'm still using DKIM verifier 2.2.0 and am therefore referring to this old version - in case something has changed.

I'm perfectly fine with the behavior of displaying the favicon on the base of the signing domain (like in v. 2.2.0).

For GitHub: It's the official GitHub notification system mailing, so it's perfectly fine to have a GitHub favicon displayed. It even helps to quickly recognize: This is GitHub and NOT a person with display name "Foo", which sent that mail. It's like any other forum notification: The official site notifies you, that there's something you may be interested in.

For open mailing lists: This is more difficult as the mailing list content can really be originating from any person with any opinion and any intention. But I'd say people, who are using such mailing lists, are aware of this fact and technically, it's the official Thunderbird mailing list mail system, sending the mail. And people not using such mailing list won't get mails from an official mailing list mail system - so the argument is the same: The icon helps me to see, the sender is the official mail system.

I guess, with this change, you'll also loose this useful feature for some other companies using it the other way round. So for example the company Foo, signing all its mails with SDID foo.com, but having mail addresses @sales.foo.com @hr.foo.com @research.foo.com or @newyork.foo.com, @losangeles.foo.com ... will loose its favicon.

In general: Making the match for favicon display stricter, will probably break it the other way round and you might not catch all cases you'd like to catch and be in the same situation

• You'd need to remove GitHub favicon completely, since all mails come from @github.com (and probably some other favicons - if you are able to identify them...)
• You'd have the problem, that you can't add favicons for company Foo from above, even if you want to

As this is nothing you can derive from a DKIM signature, you'd need more flexibility, since it depends on how companies use their mail domains, you'd need to implement an own ruleset, if a favicon should be displayed or not, after the DKIM verification was passed. This is a lot of work and you'd have to recheck your rules from time to time, as companies might modify their services.

Offtopic: I'm at version 2.2.0, you'll be releasing version 4: Were there a lot of feature changes and fixes in case I'd like to backport them to the 2.2.0 version?

[dodmi]

Maybe I don't understand, how this works...
I thought from your mailing list example, that you handle the @discuss.thunderbird.net addresses equal to @thunderbird.net, because of the information in the DKIM header and plan to change this [display the icon only if the mail domain is exactly the domain in the DKIM header].
I had in mind, that this could also bei vice versa and that you'd be in the same situation, that you can't display a favicon, even if you want to. Therefore my example with the Foo company.

Thank you for the info; I'll have a look for this fixes and updates and try to backport them to the old version.

[lieser]

I thought from your mailing list example, that you handle the @discuss.thunderbird.net addresses equal to @thunderbird.net, because of the information in the DKIM header and plan to change this [display the icon only if the mail domain is exactly the domain in the DKIM header].

Note that my initial example does not contain a @discuss.thunderbird.net (from) address. It only contains an discuss.thunderbird.net SDID, which can be totally different from the domain of the from address.

There is an icon entry for the thunderbird.net domain. And if an email is signed by that domain, or any sub domain (e.g. discuss.thunderbird.net), it will get the icon. The from address currently does not matter at all.

Some examples if there would be an icon entry for foo.example.com (x: icon shown, -: no icon):

SDID	From	Current	Restricted From
foo.example.com	@foo.example.com	x	x
foo.example.com	@sub.foo.example.com	x	x
foo.example.com	@example.com	x	? (probably -)
foo.example.com	@bar.com	x	- (this change is the main idea)
sub.foo.example.com	@foo.example.com	x	? (probably x)
sub.foo.example.com	@sub.foo.example.com	x	x
sub.foo.example.com	@example.com	x	? (probably -)
sub.foo.example.com	@bar.com	x	- (this change is the main idea)
example.com	@foo.example.com	-	-
example.com	@sub.foo.example.com	-	-
example.com	@example.com	-	-
example.com	@bar.com	-	-
bar.com	@foo.example.com	-	-
bar.com	@bar.com	-	-

The above should be the result of this two checks:

1. Is the SDID in (i.e. equal or a sub domain of) the domain in the favicon list
   • this is the current existing check
2. Is the domain of the From address in (i.e. equal or a sub domain of) the domain in the favicon list
   • this would be the new check, and I think better than the from address is in the SDID check that I had initially in mind

[lieser]

For back porting, the relevant commits should be:

• fixed parsing of version: e113420
  • Note that I myself currently fail to detect which of the many changes is the actual fix
• fixed parsing of quoted SDID and AUID: c32c8ae
• fixed missing reason on fail resulting in error: 8e72417

Note that although I would be happy to upload an updated version here on GitHub if you make the effort of back porting, I will probably not be able to upload it to ATN, so no automatic update for others. ATN unfortunately has some issue with uploading versions for older TB versions.

[dodmi]

Thank you for elaborating. I think, I've understood the issue now. Above, I thought, that the sender address for the Thunderbird mailing list is always a @discuss.thunderbird.net address. But in fact the original sender address isn't replaced at all?

First impulse: That's a good idea. It'll prevent, that any relayed mail from a foreign domain will get any marks, that could lead to enhanced user trust.
Second impulse: But in general, the mail provider, who signs the mails, has to ensure, that he only signs mails, he's fine with.

I could also imagine a fitting case, but I don't know, if it's a real world issue:
Think of the Foo company again, having small offices all around in Europe, but is using one central mail system on their main domain foo.com.
The employees in the different countries get mail addresses on their local domains: @foo.uk, @foo.es, @foo.fr, @foo.de, ... but all traffic is handled by the mail server central-mail.foo.com and SDID foo.com.
This will work with the current implementation, but won't with the planned one.

Again, you will probably not catch all cases with the current or the planned implementation.

PS: Thank's again for the efforts of searching the relevant commits.

[dodmi]

It's me agian,
I've found a real life example for the above problem:
Companies, using Microsoft 365 (Exchange Online), but don't change the default DKIM policy.
As I understand, the SDID is <tenantname>.onmicrosoft.com for all registered mail domains. So, such a company could never get a favicon, if you'd implement the new policy.