128539 - Unable to send mail to non-ascii mailing list through the address picker

Status: VERIFIED FIXED

(MailNews Core :: Internationalization, defect, P3)

Description

[marina]

*** observed with 2002-03-01 builds **** on Mac and Windows
This is a recent regression. When the mail list is made up from all  non-ascii
chars it is not recognized as a valid recipient and you get an error message
"Null recipient is not accepted" In case there are one or several non-ascii
chars in the mailing list you do not an error while sending but the mail doesn't
get to the recipient and after analyzing the return mail you see that the
mailing list name was stripped from all non-ascii chars , for ex. "Àlîst"
becomes "lst"
Steps to reproduce:
- cerate or select from the PAB a mail list that has non-ascii chars in it;
- send mail, note the error message coming up about a null recipient, i'll
attach the screen shot. There are problems to send mail to ascii list as well.
It looks like the autocomplete is not done against the description and it treats
the list as <[e-mail]> . I don't know if this bug is already filed.
Cc'ing nbaca

Comment 1

[marina]

Attachment: here is an errror message you get when sending mail to the non-ascii mail list

Comment 2

[marina]

I am trying to track down the build when the regression was introduced, it looks
now as it was between 02/12 and 02/25, i'll narrow it down.

Comment 3

[marina]

Ok, the regression was introduced by some check ins between 2002-02-19-18 build
( the last good build) and 2002-02-20-03 (the first bad build)cc'ing racham

Comment 4

[nhottanscp]

The list name contains non ASCII but cards in the list are ASCII only, it that
correct?

Comment 5

[marina]

it looks like the contents of the mailing list are not important, i used both (
ascii , non-ascii), i am not able to send with a non-ascii mail list containing
ascii cards .

Comment 6

[nhottanscp]

I created a list named "Àlîst" and added two e-mail addresses but cannot
reproduce the problem, the mail was sent without the error. I used my debug
build updated this morning.
Marina, could you try it again with the latest build?

Comment 7

[marina]

Naoki, you'll be able to send mail using "ְlמst" as a mailing list name, however
the mail won't reach the recipient , you'll get Mail administrator error where
you'll see the problem : the mail list is stripped of all accented chars, it
looks like "lst". If you'll try to send to the list that would be made of all
non-ascii chars like "יייי" then you'll get an error while sending.

Comment 8

[ji]

It seems this only happena when using the address picker.
It doesn't happen when opening a compose window and filling out recipients
fields through auto-complete.

Comment 9

[marina]

yes, it happens when using address picker or when the address book is open and
you select the mailing list and click compose (wich is the same mechanism as
address picker). On Mac OS X when the mailing list name has only non-ascii and
is rather long like for ex. "יייייייי" it hangs the application

Comment 10

[ji]

Nominating for nsbeta1.

Comment 11

[marina]

There are two problems in this bug report:
1. the mailing does not get expanded correctly through the address picker or
when send directly from the PAB , it expands agaist the mailing list name not
against description as it should,(and it does it correctly when just typed into
the Composition window), so the the same problem is encoutered when mail is send
to an ascii mailing list as well( i was already wondering whether this bug was
filed in core, i'll go ahead and log it now) 
2. the problem with sending to a mailing list with non-ascii name

Comment 12

[Frank Tang]

regression, nsbeta1+

Comment 13

[nhottanscp]

I think this will be fixed when the mailing list expansion bug 129113 is fixed.
If the list is expanded to actual e-mails then the non ASCII list name will not
be used for sending.

Comment 14

[marina]

i agree that when bug #129113 will be fixed this problem will be gone. I am
waiting for 129113

Comment 15

[ji]

Checked 03/28 build for this. It seems fixed with the patch for bug 129113.

Comment 16

[nhottanscp]

fixed by bug 129113

Comment 17

[marina]

verified as fixed with 2002-04-16 trunk build and 2002-04-15 branch build