International Characters In Domain

[RealAct]

I have noticed that mail coming from the domain deepinenespañol.org is shown as:

Invalid (Should be signed by xn--deepinenespaol-1nb.org)

deepinenespañol.org / xn--deepinenespaol-1nb.org are exactly the same domain. When mail from this domain arrives at providers such as Gmail or Hotmail, everything shows as legit DKIM /SPF/DMARC etc.

Am I missing something? I didn't want to report this as a bug because I'm not sure if maybe I'm missing something.
Anyone experiencing such an issue?
Thanks.

[lieser]

The add-on does not understand and interpret the IDNA encoding in any way. So for it the IDNA encoded xn--deepinenespaol-1nb.org and the probably UTF-8 encoded deepinenespañol.org are two different string.

Note that although some initial works to support UTF-8 in the header has started it is still incomplete and needs to be enabled with the hidden preference internationalized.enable. See also #163.

Although not testes, as long as the From header is still only ASCII from your report it seems that UTF-8 encoded domains in the DKIM signature do not cause problems.
Did you already try to extend your sign rule for the domain to also allow deepinenespañol.org as the SDID?

Also in case the email does not contain some personal data what your are unwilling to share with me, it would be nice if you could send it to me ([email protected]) as a saved .eml file. It would be good to have some real world examples then I will hopefully find time in the future to implement proper UTF-8 support.

[RealAct]

Thanks a lot for taking the time to reply and give me all the additional details.

I really do appreciate your interest. I have gone ahead and created an e-mail account for you on the domain, so you may check and play with it yourself.

I have sent the details of the account to the account you mentioned above @posteo.net

Once again, thanks a lot for looking into this as I really love the extension, and I'm sure many international users have it installed on their Thunderbird clients.

Best Regards
-Eli

[lieser]

The e-mail you send me was signed by xn--deepinenespaol-1nb.org, and not the more interesting deepinenespañol.org. Could you check again what was the SDID (the d-tag in the DKIM-Signature) in the email which cause problems for you?

And thanks for the test account, unfortunately the login does not work.
Also note that I will probably not need it that much. A single email with an UTF-8 encoded domain should be enough for initial testing.

[RealAct]

Hi,
Thanks once again for responding.

Weird that the account password didn't work, I could reset it, but it is ok if you won't have much use for it

Yes the emails are signed by xn--deepinenespaol-1nb.org because that the real domain. When you try to set up DMARC SPF etc you are not allowed the international characters, farther more, if you enter them in most configuration systems they get automatically switched to xn--deepinenespaol-1nb.org charset.

I believe the thunderbird plugin would need a way to translate domains such as xn--deepinenespaol-1nb.org internally when it finds them and report them as properly signed? I'm not sure honestly, not a programmer here 😂

In any case I thank you for looking into this.

[lieser]

For me the addon already did successfully verify the email you send me.
It's just that it did not decode the n--deepinenespaol-1nb.org back into a nicer looking domain.
Besides the ugly domain name everything should work with IDNA encoded Domains, as this to the addon look like any other "normal" ASCII domain.

SDID is the short form of how in DKIM the domain that is signing the email is called. And is stored in the d-tag of the signature.

The question now is why the addon things out should be signed by a different SDID in your case.
Like I wrote my guess is an incorrect sign rule you have created locally. See also https://github.com/lieser/dkim_verifier/wiki/Sign-rules.
You should check the rules and make sure they are correct.

[RealAct]

BTW sorry I didn't say anything regarding your question about SDID (the d-tag in the DKIM-Signature). I'm not sure what that is, but I'll investigate.