搜尋 Mozilla 技術支援網站

防止技術支援詐騙。我們絕對不會要求您撥打電話或發送簡訊,或是提供個人資訊。請用「回報濫用」功能回報可疑的行為。

了解更多

non-ASCII characters in the local part of the recipient address

  • 6 回覆
  • 1 有這個問題
  • 1 次檢視
  • 最近回覆由 Matt

more options

This question was also asked here: https://support.mozilla.org/en-US/questions/1082352

However, that answer is completely bogus. The correct answer would be the second sentence of the alert message:

There are non-ASCII characters in the local part of the recipient address. This is not yet supported. Please change this address and try again.

(The third sentence is nidicolous, it means "send your mail to someone else".)

Previous versions of TB accepted UTF-8 addresses without questions and without checking. Support can be checked by looking at SMTPUTF8 in the ehlo response. Then, sending a message with UTF-8 characters is just the same as with ASCII. So, it is more interoperable to unconditionally try to send than to blindly refrain to even try. Is there an option to re-enable the old behavior?

TIA Ale

This question was also asked here: https://support.mozilla.org/en-US/questions/1082352 However, that answer is completely bogus. The correct answer would be the second sentence of the alert message: There are non-ASCII characters in the local part of the recipient address. This is not yet supported. Please change this address and try again. (The third sentence is nidicolous, it means "send your mail to someone else".) Previous versions of TB accepted UTF-8 addresses without questions and without checking. Support can be checked by looking at SMTPUTF8 in the ehlo response. Then, sending a message with UTF-8 characters is just the same as with ASCII. So, it is more interoperable to unconditionally try to send than to blindly refrain to even try. Is there an option to re-enable the old behavior? TIA Ale
附加的畫面擷圖

由 Matt 於 修改

所有回覆 (6)

more options

Thunderbird issue was fixed in version 20 https://bugzilla.mozilla.org/show_bug.cgi?id=127399 So what you are seeing is either a recent regression that no one else has reported, or caused by something else.

Can you reproduce on something other than whatever flavor of Linux you are using with the release version? I have no issues on Windows sending to UTF domain names.

more options

Do you imply Thunderbird works better under Windoze than on Linux? FWIW, version 60.7.2 (32 bit) under the former fails just as well as the same version (64 bit) on the latter. Try send me a message...

The bug you mention is a very old bug, closed 7 years ago. It is about IDN, and comment 95 shows that the fix is clearly entangled in catching "illegal characters" in the local part. Perhaps, it was the antecedent versions the ones which were working?

If a server supports SMTPUTF8, a mail client doesn't need to do any encoding at all. UTF8 and ASCII can be treated alike (except on making DNS queries, in that case domain names still have to be encoded according to IDNA.) Note that there is no recovery if your server doesn't support SMTPUTF8. You cannot write to that address, period. So, I just need an option to skip any checking. If I want to write to an EAI address, it is my duty to find a working server. Clients should just not broach.

more options

I imply that unless you install Thunderbird from a build on the thunderbird.net site that it might not even have the same menu as I would expect.

Most Linux distributions build their own from source codes.

Further is is common for issues to exist on one operating system and not on another. In the case of Unicode fonts, Ubuntu users had issues with scaling caused by the fonts in their distribution. but it was first reported as a Thunderbird bug.

I am also saying I am unable to reproduce what you say on a windows version using Window 10. I tried using all the addresses in my earlier bug about blank email addresses.

However I can reproduce with your example. I suggest you file a bug. https://bugzilla.mozilla.org If you post a link here I will mark it at confirmed.

more options

Done, bug#1563891.

Thanks

more options

You know, this bug still exists in 60.6.1 (64-bit) for Linux. The thing is that I have no control over the email address as I am sending a "return receipt" for an email.

What would be a real help is for the actual local address to be displayed in the error message.

What is really strange is that I have examined the source and find no problem with either the sender email or the return address.

more options

dee3 said

You know, this bug still exists in 60.6.1 (64-bit) for Linux. The thing is that I have no control over the email address as I am sending a "return receipt" for an email.

The bug will continue to exist until such time as it is fixed. I suggest you follow the bug, and perhaps vote for it if it is important to you. The last comment does not bode well for an early fix.