Last Comment Bug 5328 - When "To:" line one address which contains 8-bit characters, mail is not sent even when other addresses are correct
: When "To:" line one address which contains 8-bit characters, mail is not sent...
Status: VERIFIED FIXED
DEPEND - Intl
:
Product: MailNews Core
Classification: Components
Component: Internationalization (show other bugs)
: Trunk
: x86 Windows NT
: P3 normal (vote)
: M9
Assigned To: rhp (gone)
: Katsuhiko Momoi
Mentors:
Depends on:
Blocks: 7228
  Show dependency treegraph
 
Reported: 1999-04-20 16:27 PDT by Katsuhiko Momoi
Modified: 2008-07-31 01:22 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Katsuhiko Momoi 1999-04-20 16:27:55 PDT
** Observed with 4/20/99 Win32 build **

1. Compose a message and add 2-3 addresses to "To:" and "CC:" lines.
2. Include one illegal address which contains 8-bit characters like
   this:

   grète@netscape.com

   The rest of the addresses should be legal ones.

3. Now send this msg.
4. This message will not go out to anyone.
   (A temporary file is created in the temporary directory, however.)
Comment 1 nhottanscp 1999-04-21 18:16:59 PDT
What do we want here? Do we want to generate address list with only valid
addresses or includes invalid addresses?
What if all the addresses are invalid, do we want to send the mail?
Looks like this is not really i18n but more generic validation issue.
Phil, any idea?
Comment 2 Katsuhiko Momoi 1999-04-21 18:24:59 PDT
I think we should at least mimic 4.5x behavior.
Let the server handle these kinds of errors.
The client should NOT refuse to send out msgs simply because they
contains illegal 8-bit characters in addr-spec.
Comment 3 Phil Peterson 1999-04-22 09:50:59 PDT
So, the bug is that we don't send the message? If so, reassign to
ducarroz@netscape.com.

Note that we do have a preference for allowing 8bit headers, but it isn't
visible in the UI. See the use of mail.strictly_mime_headers in msgsend.cpp

cc'ing jefft@netscape.com to make sure I have this right.
Comment 4 Phil Peterson 1999-04-28 18:12:59 PDT
M6
Comment 5 Katsuhiko Momoi 1999-05-04 18:22:59 PDT
I think we need a spec to deal with this kind of cases.
Let me add info which has come to light since I filed this bug.

1. I sent 2-3 msgs containing 2-3 the following kind of addr-spec
   using Communicator 4.6:

   JPN@netscape.com

   along with at least one correct/legal address.

   This was several days ago. I still haven't received this msg
   at the legal address.
   However, I see this msg in my Sent folder on the IMAP server.

   I'm not sure if this msg really went out or not. Maybe it
   it still wandering somewhere. My current guess is that
   it did not.

2. If 1 is true, then 4.6 behavior is similar to what I reported for
   5.0.

3. In either case, this is not desirable behavior. Based on 1 & 2, I'm
   changing my mind on this and want to suggest that we check for
   this kind of illegal addr-spec and ask the user to re-input in
   legal format before accepting to send it out.

4. By the way, looking at the source of the msgs stored in the Sent
   folder, I find that we B-encode the entire string including "@".
   See this example where the CC line contains the type of address
   I mentioned above. (Note: I still haven't received this msg at
    momoi@netscape.com.)

   Date: Thu, 29 Apr 1999 00:21:37 -0700
   From: Katsuhiko Momoi <momoi@netscape.com>
   To: momoi@netscape.com
   CC: =?iso-2022-jp?B?GyRCRW0wZhsoQkBwb2x5Z2xvdC5tY29tLmNvbQ==?=
Comment 6 Jean-Francois Ducarroz 1999-05-14 12:02:59 PDT
it must be a back-end issue. Reassigned to Rich
Comment 7 rhp (gone) 1999-06-15 16:47:59 PDT
Will look into for M8.
Comment 8 rhp (gone) 1999-07-05 22:33:59 PDT
Pushing out again :-(

- rhp
Comment 9 rhp (gone) 1999-08-05 15:23:59 PDT
This should work now. I've taken the approach that it will send the message and
the valid addresses will get through and you will get a bounce message on the
others. I don't like getting too fancy mucking with address information for
fear of not sending something valid. I would rather error on the side of
getting more bounce messages than not sending good email.

Oh, in my testing, it seems that 4.5 would seemingly send the message, but
nothing would ever get delivered and no bounce would happen so I think we are
better off with 5.0 than where we were with 4.x.

- rhp
Comment 10 Katsuhiko Momoi 1999-08-13 20:02:59 PDT
** Checked with 8/13/99 Win32 build **

I'm going to mark this fix verified.
I sent a message to 4 people with one of them containing
8-bit character in the address_spec itself.

momoi@netscape.com
momoi8@polyglot.mcom.com
momoi8@kaze.mcom.com
"grète"@netscape.com

I got the first 3 msgs but the 4th one was
bounced with an error msg. This is in accord with
the current fix.
The only problem was that the 4th one got bounced for
a wrong reason -- not because the user of the name "grète" does
not exist but because the following recipient:

    Recipient: <" ="@netscape.com>
    Reason:    <" ="@netscape.com>... User unknown

does not exist.

We are clearly doing something wrong when the "to: " line
contains 8-bit characters either in NAME or real address part
of:  8-bit_NAME <8bit_id@netscape.com>.

See Bug 11892 for details.

Note You need to log in before you can comment on or make changes to this bug.