Bugzilla

With this change you can now compose and send emails to an address like mimì@foà.it having any UTF8 character provided the smtp server EHLO response lists the capability SMTPUTF8. The address is not modified in any way, keeping and sending the UTF8 bytes as is.

When SMTPUTF8 is not listed (as with my usual server) you still get the error about the local part (string before the @) being uncorrectable if it contains non-ASCII UTF8. If  the local part doesn't, the domain part is still converted to punycode (using ACE converter) if it contains non-ASCII UTF8.

I had to move the code that loops through the recipient addresses since its current place is before the EHLO command is issued so it is unknown at that point if SMTPUTF8 is supported.

My changes are inspired by the suggestions here: https://rant.gulbrandsen.priv.no/eai+email.  

There is still a problem when replying, forwarding or editing as new an existing email with non-ASCII UTF8 addresses. The address fields have the non-ASCII UTF8 replaced with the invalid/replacement chararcter sequence as show here:  Attachment 9156903 [details]

With this change you can now compose and send emails to an address like mimì@foà.it having any UTF8 character provided the smtp server EHLO response lists the capability SMTPUTF8. The address is not modified in any way, keeping and sending the UTF8 bytes as is.

When SMTPUTF8 is not listed (as with my usual server) you still get the error about the local part (string before the @) being uncorrectable if it contains non-ASCII UTF8. If  the local part doesn't, the domain part is still converted to punycode (using ACE converter) if it contains non-ASCII UTF8.

I had to move the code that loops through the recipient addresses since its current place is before the EHLO command is issued so it is unknown at that point if SMTPUTF8 is supported.

My changes are inspired by the suggestions here: https://rant.gulbrandsen.priv.no/eai+email.  

There is still a problem when replying, forwarding or editing as new an existing email with non-ASCII UTF8 addresses. The address fields have the non-ASCII UTF8 replaced with the invalid/replacement chararcter sequence as show here:  Attachment 9156903 [details]

Edit: I probably also need to verify that the local and domain strings are truly UTF8. If not, local part need to be rejected. Not sure about domain part, maybe stilll convert it?

Alessandro, I noticed that after an email is sent with your smtp server, tb opens a new imap connection and then appends the just sent email to the "Sent" mailbox. Tb sends the ENABLE UTF8=ACCEPT for the new connection right before the append but the courier imap server responds with the alert anyhow. Otherwise, I never see the alert as long as UTF8=ACCEPT pref is true. (This also pertains to bug 1571672.)

With this change you can now compose and send emails to an address like mimì@foà.it having any UTF8 character provided the smtp server EHLO response lists the capability SMTPUTF8. The address is not modified in any way, keeping and sending the UTF8 bytes as is.

When SMTPUTF8 is not listed (as with my usual server) you still get the error about the local part (string before the @) being uncorrectable if it contains non-ASCII UTF8. If  the local part is pure ASCII, the domain part is still converted to punycode (using ACE converter) if it contains non-ASCII UTF8.

I had to move the code that loops through the recipient addresses since its current place is before the EHLO command is issued so it is unknown at that point if SMTPUTF8 is supported.

My changes are inspired by the suggestions here: https://rant.gulbrandsen.priv.no/eai+email.  

There is still a problem when replying, forwarding or editing as new an existing email with non-ASCII UTF8 addresses. The address fields have the non-ASCII UTF8 replaced with the invalid/replacement chararcter sequence as show here:  Attachment 9156903 [details].
Edit: This is now fixed in Bug 1658361 and was caused by a regression as reporter Ale V. pointed out.

Edit: I probably also need to verify that the local and domain strings are truly UTF8. If not, local part need to be rejected. Not sure about domain part, maybe stilll convert it?

Alessandro, I noticed that after an email is sent with your smtp server, tb opens a new imap connection and then appends the just sent email to the "Sent" mailbox. Tb sends the ENABLE UTF8=ACCEPT for the new connection right before the append but the courier imap server responds with the alert anyhow. Otherwise, I never see the alert as long as UTF8=ACCEPT pref is true. (This also pertains to bug 1571672 and is fixed there.)

With this change you can now compose and send emails to an address like mimì@foà.it having any UTF8 character provided the smtp server EHLO response lists the capability SMTPUTF8. The address is not modified in any way, keeping and sending the UTF8 bytes as is.

When SMTPUTF8 is not listed (as with my usual server) you still get the error about the local part (string before the @) being uncorrectable if it contains non-ASCII UTF8. If  the local part is pure ASCII, the domain part is still converted to punycode (using ACE converter) if it contains non-ASCII UTF8.

I had to move the code that loops through the recipient addresses since its current place is before the EHLO command is issued so it is unknown at that point if SMTPUTF8 is supported.

My changes are inspired by the suggestions here: https://rant.gulbrandsen.priv.no/eai+email.  

There is still a problem when replying, forwarding or editing as new an existing email with non-ASCII UTF8 addresses. The address fields have the non-ASCII UTF8 replaced with the invalid/replacement character sequence as show here:  Attachment 9156903 [details].
Edit: This is now fixed in Bug 1658361 and was caused by a regression as reporter Alessandro V. pointed out.

Edit: I probably also need to verify that the local and domain strings are truly UTF8. If not, local part need to be rejected. Not sure about domain part, maybe still convert it?

Alessandro, I noticed that after an email is sent with your smtp server, tb opens a new imap connection and then appends the just sent email to the "Sent" mailbox. Tb sends the ENABLE UTF8=ACCEPT for the new connection right before the append but the courier imap server responds with the alert anyhow. Otherwise, I never see the alert as long as "allow UTF8=ACCEPT" pref is false. 
Edit: This also pertains to bug 1571672 comment 59 and is fixed there.