Open Bug 197134 Opened 17 years ago Updated 6 months ago

Mail not sent if one mail recipient generates an SMTP "550 unknown user" code

Categories

(MailNews Core :: Networking: SMTP, defect)

defect
Not set

Tracking

(Not tracked)

People

(Reporter: Saul.Tannenbaum, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030304
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030304

When Mozilla talks to an SMTP server and the server returns a 550 code,
Mozilla generates an alert dialog box saying "An error occured while sending
mail. The mail server responded "unknown user". Please check the message
recipients and try again."

While this is reasonable for a mail message with a single recipient, with multiple
recipients, the user is left to guess which address is bad. 

Mozilla should:

- provide better feedback as to which address is bad
- offer to send the mail anyway and let the SMTP server provide
feedback via a bounce message.


Reproducible: Always

Steps to Reproduce:
1. Send mail to any SMTP server that will produce a 550 error code.
2.
3.

Actual Results:  
Mozilla generates an alert dialog box saying "An error occured while sending
mail. The mail server responded "unknown user". Please check the message
recipients and try again.

Expected Results:  
Mozilla should:

- provide better feedback as to which address is bad
- offer to send the mail anyway and let the SMTP server provide
feedback via a bounce message.
> provide better feedback as to which address is bad

Not every SMTP server will only say "unknown user". Many also say which
recipient failed.
But it's no problem to add the address which has been rejected to the error
message. E.g. "An error occured while sending mail to user@domain.net. The mail
server responded: "unknown user". Please check the message recipients and try
again."

The problem is when to report the problem and how.
Say you want send a message to 30 recipients. Should the dialog pop up for each
rejected one? Or at the end of the list? The more recipients the more probable
are multiple rejected addresses.

> offer to send the mail anyway

This is an internal problem at the moment. The standard error dialog only has
"OK" but no second button for "Cancel". So it's only possible to inform the user
but not to let him choose to continue or to stop.

> and let the SMTP server provide feedback via a bounce message.

Er, that's impossible AFAIK.
If a SMTP server responses with an error to our RCPT TO line it won't take the
message for this recipient even if we continue with the mail.

So the user finally has one problem (at least when he has a lot of recipients).
If he continues or not, after clicking the error dialog away, he won't know
which have been rejected. So it will be a hard job to sort them out (to correct
a typo in the address, for research on the persons new address or whatever).
*** Bug 243002 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
(In reply to comment #1)
> > and let the SMTP server provide feedback via a bounce message.
> 
> Er, that's impossible AFAIK.
> If a SMTP server responses with an error to our RCPT TO line it won't take the
> message for this recipient even if we continue with the mail.

Correct - what I would suggest, however, is that Mozilla could continue sending the message, and after the sending is completed, display a dialog that lists all of the addresses that failed, along with the error messages:

"An error occured while sending mail.  The following addresses were rejected:

tim@heck: Unroutable address
joe@bloggs.com: User unknown
jane@smith.com: Relaying Denied

All other recipients were delivered properly.  Please check these failed addresses and try again."

Then, the message, with successful recipients, could be processed as sent as normal, and a new message could be generated with the same body, but just the failed recipients, so the user could check them and re-send if appropriate.

Obviously this makes fixing the issue much more complicated.  However, I think it is the best behavior from the user perspective.  Also, it doesn't cause Mozilla to violate the SMTP protocol, which it is doing currently.  Right now, when it gets a rejection in the middle of sending, it will unceremoniously drop the SMTP connection without so much as a QUIT.  At the very least, it should send a QUIT if it's going to continue with the current behavior.
Having just come across this problem myself, and doing a tcpdump to see what was actually happening, Thunderbird appears to bomb out of the SMTP session as soon as it sees the 550 code from the server, without so much as a QUIT or anything! This is not very compliant!
(In reply to comment #4)
> Thunderbird appears to bomb out of the SMTP session as soon as it sees the 550
> code from the server, without so much as a QUIT or anything!

True, see bug 62836. 

To whomever is in charge....this bug is very similar to 276029. :)

One point to add is don't forget about 4xx SMTP response codes, too.
As I read this and bug 276029, I also see a connection to bug 300937 in that the Networking:SMTP component needs to be able to handle the different SMTP response codes a submission server might give back to TB gracefully.
Due to a Thunderbird Alert pop-up message that was flat out wrong, I was sent on a wild goose chase costing well over eight hours of effort to overcome an SMTP failure problem. While my problem pulled a 551 SMTP server error and earlier comments here mention a "550 code", and having read the earlier comments, I post under this bug as the best fit.

(Scott, if my comment does not in fact relate to this bug, would you raise it as a new bug or move it to the most appropriate one? Also, it's a quick fix to remove the inaccuracy in the present error message, and in my view should definitely go into the next release. Thanks.)

Using Mozilla Thunderbird version 1.5.0.9 (20061207) I tried to send to a list of 64 addresses, and it failed. The precise Mozilla Alert message read:

"An error occurred while sending mail. The mail server responded: not our customer. Please verify that your email address is correct in your Mail preferences and try again."

I knew my Mail preferences were OK because I have no problem sending emails from day to day. I also confirmed that by sending test emails. I carried out all sorts of experiments to try and nail down a repeatable case that failed. Thanks to Outlook Express, I suddenly got the answer.

Under Outlook Express I put together and tried to send the same offending email as I tried to send under Mozilla Thunderbird, and to the same addressees. It triggered the same error, but the Outlook Express error message told the true story and had much more information, as follows:

"The message could not be sent because one of the recipients was rejected by the server. The rejected e-mail address was 'georgeC6@comcast.net'. Subject 'Fw: Tell Congress to Stop President Bush from Attacking Iran!', Account: 'Comcast-OE', Server: 'smtp.comcast.net', Protocol: SMTP, Server Response: '551 not our customer', Port: 25, Secure(SSL): No, Server Error: 551, Error Number: 0x800CCC79"

From this I saw that the error was generated _not_ because my user ID/password in the email send request to comcast.net was incorrect, but because one of the _addresses_ was to another comcast.net customer but referenced a discontinued user account. This completely explained my experimental results in trying to find out what went wrong. Furthermore, I then knew exactly what to do to correct the fault. (Incidentally, Comcast's handling of this seem wrong to me: why reject a complete list because of an immediately detectable erroneous Comcast address? Why not relay to __all__ addresses and let erroneous Comcast emails bounce back like any others?)

If any of you are comcast.net users, you can demonstrate the behavior. (It may be common to other  email ISPs. I don't know.) Mail to a spurious Comcast address and to yourself at Comcast or any other valid address you have. For example,  xxxx99@comcast.net and yourself@comcast.net. The whole list is rejected, the 551 error message occurs, and nothing goes to yourself@comcast.net. Remove xxxx99@comcast.net from the list, and the email does go through to you.

I notice similarities in the Thunderbird error wording quoted in the Bug 228198 discussion ("An error occurred while sending mail.  The mail server responded: 5.7.1 <to_name@to_server.domain>... Relaying denied.  Please verify that your email address is correct in your Mail preferences and try again.") Might that message be erroneous also??? In any case, I would suggest that:

1. all error messages returned by the SMTP server be handled in a uniform manner capturing as much information as possible from the server,

2. all the server info be passed back to the Thunderbird user - just like OE does or better, and

3. all Thunderbird error messages passed back to the user (a) contain full and accurate info on how to correct the problem, and (b) be __verified_for_accuracy__ ASAP to save users from being misled and incensed.

Before I retired from a career in engineering software development work, I made sure great attention was paid to the accuracy, completeness and helpfulness of error messages generated for users. I know it saved countless man hours and calls for help to the systems group in trying to get out of trouble.

Please upgrade the severity of this bug to _Major_, because of the impact to countless Thunderbird users; I, for one, was tearing my hair out!

Sorry if I seem to preach, but sloppiness tends to get me going. Anyway, thanks for all the volunteered effort. I support the open source movement all the way.
John, please see my comment 8 in bug 276029. In the way of a general improvement of SMTP feedback I'm also about to give more information on the specific address.

In regards to the error message you cited from bug 228198 I'd like to hear from you why it would be erroneous. I don't see that right now.
Christian, Please disregard my questioning of the bug 228198 message. My only thought was that if one error message is incorrect, another one that shares some of the same words, namely "Please verify that your email address is correct in your Mail preferences and try again" may similarly be incorrect and mislead. Also, I wasn't sure if all of the quote was verbatim, because "5.7.1" seemed a bit odd if it was meant to refer to a server error number "571". I haven't studied bug 228198, so should not have mentioned it. Sorry.

Looking at the bug description again, I'm puzzled that the problem described seems to be the same one I report (comment 8), but it is with respect to server error code 550, and not 551 as in my case. Yet the message quoted in the bug description fits my 551 case better than the Thunderbird message I got. What is the difference between error codes 550 and 551 precisely? Very confusing.

I have never worked with the client/SMTP-server protocol, but in the case of a 551 error it seems to me that the client, Thunderbird, must either (a) first submit each recipient's address to the server to find out if it's acceptable, then decide which, if any, of the acceptable addresses it will send the email to, or (b) submit the email with all its recipient addresses present, then the server will reject the email completely if it encounters an unacceptable recipient address. Which is true? Just a question in my own mind.

From our point of view there's no difference between 550 and 551.
What you're confused by is bug 294296 which was caused by one of my patches. So that if a recipient was rejected the user got the same message as for sender rejected resulting in "Please verify that your email address is correct" instead of "Please check the message recipients".
I wasn't aware of that until recently. It was fixed in the bug above.

Regarding your question about the transmission procedure:
The client sends one RCPT TO command for each recipient to the server. The server directly answers each command either with ok or some error.
If the client continues with other recipients after an error and also submits the mail text, the server finally sends the mail to all ok recipients.
But the client can also stop at each point e.g. to only submit the message if all recpipients are ok. That's what we do because it's simpler to code and clearer for the user (it's at least from my point of view as a user).
Thanks, Christian. That helps a lot.

Testing with OE, I found out the difference between error codes 550 and 551. I agree that the solution is the same in both cases, namely correct or remove the bad addresses, but for clarity why not tell the whole story and avoid ambiguities? I wouldn't think it's so hard to do. I've worked up a format for the Alert pop-up display that I think would satisfy most users. (If even more info might be helpful for possible debug, perhaps an optional 'verbose' mode could be made available sometime, such that when it is switched on all the extra stuff as in the OE messages would be added to the Alert content. I think it is important to check _all_ the recipient addresses and provide a full report at one time, because it's annoying to the user to be made to winkle out an error and retry, one error at a time - especially if it's a long list with numerous old addresses, say. My tests indicate that OE does not check all the addresses, so TB has a chance to do better than OE in that respect.

I agree that it would be messy, and probably undesirable, to reconstruct the sender's email with the bad addresses removed so it could be sent without error. I think it's better that the sender sort that out and make his own decisions.

Here's an illustration of my layout for the Alert pop-up:

******************************************************************************
*  Thunderbird did not send your email because the server reported           *
*  the following error(s) in addresses for the recipients:                   *
*                                                                            *
*  Server error 550 - destination server domain name                         *
*                     [after the '@' character] not found by DNS             *
*     john654@zzz3useless.com                                                *
*     joan.shaw@xxx5defunct.net                                              *
*     k.ashcroft@zz4ivorytower.ac.uk                                         *
*                                                                            *
*  Server error 551 - not a customer [before the '@' character] of           *
*                     the email service you are using for this email.        *                         
*     zzzxx55@comcast.net                                                    *
*     zz84xxxxx@comcast.net                                                  *
*     zzx5xxxx@comcast.net                                                   *
*     zzz77xxzz@comcast.net                                                  *
*                                                                            *
*  Please correct or remove each of the above recipient addresses in         *
*  your email and try again.                                                 *
*                                                                            *
****************************************************************************-*


If I were doing the coding, my pseudo-code/structured-English to generate the content would probably be along the following lines:

instantiate a bucket list for each server error code that can occur: list_550, list_551 ... ;
set all lists to empty;

for each_recipient_address {
  send RCPT TO command to server.
  If server_error550 { add address to list_550; }
  If server_error551 { add address to list_551; }
      .
      .
      .
}

if all the lists are empty then { send the email;}
else {
  instantiate an alert message: alert;
  alert.initialize_to_empty;

  alert.add ("Thunderbird did not send your email because the server reported
              the following error(s) in addresses for the recipients:
               ");
  if list_550 is not empty then {
    alert.add ("Server error 550 - destination server domain name
                  [after the '@' character] not found by DNS
                   ");
    for each list_550 address {alert.write ("   $address\n"); }
  }
  alert.add ("\n");

  if list_551 is not empty then {
    alert.add ("Server error 551 - not a customer [before the '@' character] of
                the email service you are using for this email.
                ");
    for each list_551 address {alert.write ("   $address\n"); }
  }
  alert.add ("\n");

        .
        .
        .

  alert.add ("Please correct or remove each of the above recipient addresses in
              your email and try again.");

  generate_alert_popup ("Thunderbird", alert.get() );
}

What do you think?
Errata. In comment 12, for  alert.write  please read  alert.add
> Testing with OE, I found out the difference between error
> codes 550 and 551.

I'm not sure I understand the difference myself 100% from reading the standard (RFC 2821). But I don't think it's (always) how you used it in your proposal.
In short according to the RFC 550 stands for "Requested action not taken: mailbox unavailable e.g., mailbox not found, no access, or command rejected for policy reasons)" and 551 for "User not local". As I understand it 551 should be used as a 550 with address update information. As always not all servers follow the standard so other differentiations might be used by them.

I'm absolutely agree with you we should provide the users with as much informations as possible to solve the problem. And I see the more recipients you have the more tedious the one-by-one strategy will be. Hopefully I don't see the simple solution, but the obstacles in the way are as follows:

The text for a 551 should be an address update information, so it would apply specifically to each recipient address. Even if it doesn't (as I read from your first post) it could vary according to the exact error of the address. For 550 I know it can, consider only the two cases of "Mailbox unavailable" and "Relaying denied".

In order not to muddle up informations the alert would have to have the format of
"Thunderbird did not send your email because the server reported the following error(s) in addresses for the recipients:

address - servers error message
address - servers error message
...

Please correct or remove each of the above recipient addresses in your email and try again."

I don't know if our alerts have a maximum size (in pixels as well as bytes) but I fear such an error is likely to be bigger than some screens.

In addition there are servers outside which after some number of negative responses quit the connection with a message of "To much errors, disconnecting." which would cause us to display just that message without more info.

To accomodate that, at least a new kind of alerts with a scrollable area for a huge amount of information and a some new handling of final errors is needed. Logging such a (possibly huge amount of) informations to a file is insufficient I think.
First of all, the main problem with the present approach of stopping once an error is encountered is that you have to retry once for each error until they are all corrected. This isn't very user-friendly.

Second, I'm not exactly sure of the circumstances or versions, but I've seen cases where the error message from the SMTP server is not relayed back to the user. This makes it extremely difficult for the user to correct the problem so this approach absolutely must be avoided.

Third, while some servers do include the offending address in the error they return, you cannot count on it being there. This means that it is imperative that you include the address in the error report yourself (and I would not bother with the optimization of looking for the address in the error before adding it yourself). As others have pointed out, not understanding the context of an error can result in HUGE goose-chasing exercises and is the absolute bane of front-line support teams.

Fourth, the idea of grouping error responses by error code sounds good, but you need to realize that SMTP error codes aren't sufficiently specific for there to be a single unique code for all possible errors. The SMTP server I work on probably has a dozen different error messages that come back with 550 in front and a dozen more that come back with 551. And these are just the predefined messages - it is easy for sites to add whatever custom error messages they like and many sites do exactly this. I think a better approach is to list the recipients that errors associated with them in the order they appeared in original user's recipient list. This makes it easier for users to find their problems and fix them.

Fifth, it might make sense to parse out SMTP enhanced status codes (RFC 2034) if any are returned. These codes are sufficiently specific that they might be useful in presenting a localized error message from a client-side table. 

Finally, I think having an option to "send anyway as long as some recipients are good" would be a nice thing to have. The client I use most often has this capability and I routinely take advantage of it. This capability is, however, not the main problem here, and while I think it should be addressed it would be understandable if it cannot be.





1. Yes, that's what I already wrote and agree with you. The advantage is, that it's easy to implement and present and it's not error prone because of servers disconnecting.

2. That's possible though I don't know of any at the moment. But with some specific situation I could find and improve that.

3.&4. Agreed, that's what's reflected in the format I showed in my last post.

5. Added to the long run ToDo.


All in all the main problem will be how to implement that in our code since from what I see new infrastructure is needed. But that of course shouldn't concern you.
Christian, I've now browsed RFC 2821 (at http://www.faqs.org/rfcs/rfc2821.html) and appreciate better the latitude allowed (and from what you say, sometimes misused by) implementers of SMTP servers. So I agree with you that it's better to just list each error in turn and quote whatever text(if any) accompanies the 3 digit error code. 

> I'm not sure I understand the difference myself 100% from reading the standard
> (RFC 2821). But I don't think it's (always) how you used it in your proposal.

With the simpler approach, we would not attempt any interpretation of the messages received, but the Mozilla generated error report could point to http://www.faqs.org/rfcs/rfc2821.html Section 4.2 for users who are interested or need to know about these subtleties. Most users will just want to know which addresses to correct or remove, then re-send.

> "Thunderbird did not send your email because the server reported the following
> error(s) in addresses for the recipients:
> 
> address - servers error message
> address - servers error message
> ...
> 
> Please correct or remove each of the above recipient addresses in your email
> and try again."
> 

Yes, that would be the simpler approach.

> I don't know if our alerts have a maximum size (in pixels as well as bytes) but
> I fear such an error is likely to be bigger than some screens.

I'm now convinced that writing to an error log file is the best way to go, but it must be easily and quickly accessible by the user for perusal, printing etc. In any case, just having the file available is a lot better than what we have now. See my display illustrations of a file format below.

> In addition there are servers outside which after some number of negative
> responses quit the connection with a message of "To much errors,
> disconnecting." which would cause us to display just that message without more
> info.
> 

I'm sure you detect when the server explicitly breaks off any further communication (error code 421), or you judge a break off has happened after some retry/timeout mechanism. In that case, and with the luxury of a file to write to, you would report what happened, and, importantly, warn the user that more errors may turn up with the next send attempt (because of possible remaining addresses that were never tested by RCPT TO commands, for example).

RFC 2821 Section 3.9 insists on the server sending at least a 3 digit error code following every command received, and says that if one is not received by the client, then that situation should be treated "as if a 451 response had been received and act accordingly." I think that answers the issue raised by Ned (comment 15 paragraph 2). Obviously if a 451 code is (effectively) received, all to do with the last command sent to the server must be ignored, because the 451 response provides no comment on it.

SENDING TO ALL THE VALID ADDRESSES ANYWAY.

I agree with Ned (comment 15 last paragraph) that an option to send to all valid addresses anyway is a good idea. Obviously, it has to be an option, because the sender might require delivery of the message to all the addressees at the same time. Telephone by voice or FAX, for example, may be used simultaneously to reach those for whom no valid email address can be found.

Also, I think it is important to strip out the invalid recipient addresses from the sender's To: Cc: and Bcc: headers so that what is actually attempted agrees with the header addresses. This way, the sender avoids (a) giving the false impression that an attempt to send to bad addresses had been made, and (b) knowingly informing recipients of bad addresses.

If I were implementing this feature, I might do it in the following way:

(a) to submit the RCPT TO commands, process each of the To: Cc: and Bcc: header lists in turn, and build - as the commands are processed in turn - a set of revised header address lists that contain only addresses acceptable to the server.

(b) if at least (A) one unacceptable address, _and_ (B) one acceptable address is found, then build a revised email that is identical to the submitted email, but with
    (i) all non-empty revised header lists substituted for the original lists, and
   (ii) " - ADDRESSES REVISED" appended to the subject line,

then place the rebuilt email in the Templates folder.

This way, all automatic revisions of the email are retained, and the user can re-send (with " - ADDRESSES REVISED" removed, of course) or delete the templates as he wishes.

ERROR LOG FORMAT.

Illustrations of the content of an an error log file (email_SMTP_errors.txt, say) might be as follows.

In the following illustration the client was able to use the RCPT TO command to get a successful status response for all the senders recipient addresses.


--- Illustration 1 -- begin--------------------------------

Thunderbird did not send the email with the subject line
     Layoff Notice
that you tried to send
     10:30am Friday, December 15, 2006
because the SMTP server reported the following error codes and messages for invalid addresses for your recipients:                  

     john654@zzz3useless.com            550 - domain not found by DNS      
     zzzxx55@comcast.net                551 - not a customer of Comcast
     zz84xxxxx@comcast.net              551 - not a customer of Comcast
     zzx5xxxx@comcast.net               551 - not a customer of Comcast
     joan.shaw@xxx5defunct.net          550 - domain not found by DNS  
     k.ashcroft@zz4ivorytower.ac.uk     550 - domain not found by DNS  
     zzz77xxzz@comcast.net              551 - not a customer of Comcast

Please correct or remove each of the above recipient addresses in your email and try again.

Alternatively, use as you wish the Thunderbird revised email(s), from which invalid addresses have been removed, in the Templates folder with Subject line
     Layoff Notice - ADDRESSES REVISED

To understand better the meaning of server error codes and messages, please consult the RFC 2821 SMTP standard in Section 4.2  at
http://www.faqs.org/rfcs/rfc2821.html

--- Illustration 1 -- end   -------------------------------

In the next illustration the client was able to use the RCPT TO command to get a successful status response for only some of senders recipient addresses, before the server ceased to communicate.

--- Illustration 2 -- begin--------------------------------

Thunderbird did not send the email with the subject line
     Layoff Notice
that you tried to send
     10:30am Friday, December 15, 2006
because the SMTP server reported the following error codes and messages for invalid addresses for your recipients:                  

     john654@zzz3useless.com            550 - domain not found by DNS      
     zzzxx55@comcast.net                551 - not a customer of Comcast
     zz84xxxxx@comcast.net              551 - not a customer of Comcast

Because of too many address errors, or for other reasons, the server broke off communication. After any corrections, a re-send of your email may or may not reveal more errors.

Please correct or remove each of the above recipient addresses in your email and try again.

Alternatively, use (after editing the Subject line) or delete as you wish the Thunderbird revised email(s), from which invalid addresses have been removed, in the Templates folder with Subject line
     Layoff Notice -  - ADDRESSES REVISED

To understand better the meaning of server error codes and messages, please consult the RFC 2821 SMTP standard in Section 4.2  at http://www.faqs.org/rfcs/rfc2821.html

--- Illustration 2 -- end   -------------------------------

In the following case none of the sender's 3 supplied addresses were found to be valid.

--- Illustration 3 -- begin--------------------------------

Thunderbird did not send the email with the subject line
     Layoff Notice
that you tried to send
     10:30am Friday, December 15, 2006
because the SMTP server reported the following error codes and messages 

for invalid addresses for your recipients:                  

     john654@zzz3useless.com            550 - domain not found by DNS      
     zzzxx55@comcast.net                551 - not a customer of Comcast
     zz84xxxxx@comcast.net              551 - not a customer of Comcast

Please correct or remove each of the above recipient addresses in your email and try again.

To understand better the meaning of server error codes and messages, please consult the RFC 2821 SMTP standard in Section 4.2  at http://www.faqs.org/rfcs/rfc2821.html

--- Illustration 3 -- end   -------------------------------

In the following case server communication failed before even one RCPT TO command completed successfully.

--- Illustration 4 -- begin--------------------------------

Thunderbird did not send the email with the subject line
     Layoff Notice
that you tried to send
     10:30am Friday, December 15, 2006

The server broke off communication unexpectedly, before any
recipient addresses could be processed.

To understand better the meaning of server error codes and messages, please consult the RFC 2821 SMTP standard in Section 4.2  at http://www.faqs.org/rfcs/rfc2821.html

--- Illustration 4 -- end   -------------------------------

IMPLEMENTATION STAGES.

I visualize a number of possible implementation stages - not necessarily in priority order - as follows:

(a) implement an error log file as suggested above, and say in the Alert where it is (in a "reports" folder in the Thunderbird installation directory tree, say, - by default).

(b) for each RCPT TO command, add any supplementary information the server can provide through other commands to the log file entry. (comment 15 paragraph 5 seems relevant, too.)

(c) implement an "Email Error Log" option in the "View" drop down menu, and refer to it in the Alert - in addition to saying where the file it is. This lets the user browse the error report immediately - in a scrolled window, say. If a write option is not provided in the resulting display window, cut-and-paste should be usable for printing purposes etc. 

(d) implement placing revised emails in the Templates folder, and say they are there in the Alert.

(e) as a minor refinement, allow the Thunderbird user to specify a different folder from the "reports" folder in the Thunderbird installation directory tree.

WORDING for the ALERT POP-UP.

Here, I'm assuming  a full implementation of steps (a) through (e) as stated above. Short of that, the wording would be cut back appropriately.

---- begin ---------------------------------------------------------
Thunderbird
--------------------------------------------------------------------
Thunderbird did not send your email because the server reported
error(s). See details in
   C:\Program Files\Mozilla Thunderbird\reports\email_SMTP_errors.txt

Use Mozilla    View | Email Error Log    to see file contents.
---- end -----------------------------------------------------------

If a revised email is placed in the Templates folder the following would be used:

---- begin ---------------------------------------------------------
Thunderbird
--------------------------------------------------------------------
Thunderbird did not send your email because the server reported
error(s). See details in
   C:\Program Files\Mozilla Thunderbird\reports\email_SMTP_errors.txt

Use Mozilla    View | Email Error Log    to see file contents.

A Thunderbird revised version of your original email with invalid addresses
removed has been placed in the Templates folder for this Mozilla mail account.
---- end -----------------------------------------------------------

I hope the above ideas help a bit. Please point out any inaccuracies or bad points. Thanks.
Thank you John for your thinking into the problem and extensive draft.

A logfile undoubtly gives the ability to be quite exhaustive on anything and also is quite easy to implement. I already thought about that but wasn't convinced it's the right way to go.
I don't think Joe User will be happy digging in directories for some strange file to just get his mail send. So some UI for reports would be nice. Having an UI for generating general communication logs is anyways a long standing todo for me.
Logs/Reports should definitely go into the users profile folder for various reasons - not at least for privacy.

Currently I'm as well not sure if the SMTP protocol handler has the infrastructure to create mails.
I guess the whole effort will - as you already wrote - be a multiple steps task.

Please do not expect that all that will done right away. As mentioned in comment 9 at least a more informational alert is already underway. I'll let this bug know when launching into any other steps.
Thanks, Christian. I'll stay on the CC list for this bug and await further news. Your efforts are appreciated.
Duplicate of this bug: 402939
Assignee: mscott → nobody
QA Contact: nbaca → networking.smtp
I joined the bugzilla group today because I am having this bug occur in an email list of 100 addresses on comcast.net. It is nice to see that it is on the bug list. Comment 8 closely parallels the steps I followed this morning. The output message of Thunderbird looks like the one I got in Outlook. Outlook Express on the other hand gives the offending email address in its text.

I think that adding the bad email address in the output of the current error message would be sufficient to fix this bug in Thunderbird. I agree with several comments that Comcast should just take the email and send me a rejection. I will send them a complaint on this subject.

I definitely would rate this bug "Major" since I have long email lists.

Gerry (Comment 21) illustrates once more the frustration experienced when using Thunderbird to send an email to many recipients, and as I discussed in Comment 8. I tried sending such an email again about six months ago, but gave up because it wasn't worth the effort to find the bad addresses.

As a first simple step, I agree with you, Gerry, that to report at least _one_ bad address would fix the bug and be a _great_ improvement. But just as easily - and so much better - would be to report up to as many bad addresses as the Alert pop-up can accommodate. Five or six would be wonderful.

And, yes, this bug should be rated "Major". Just think of all the _hundreds_ of frustrated users being turned off Thunderbird by this easily fixed inadequacy.

I see work on this bug is currently 'unassigned'. I wish I could jump in and help but I'm too busy with web application work. Anyone else?
Update on my comment of 2/12/2008.

Thunderbird now displays the bad Comcast address when I send to a large email list. If I send the email only to the bad address the error message doesn't contain the address.

I am pretty sure that on 2/12 I wasn't seeing a bad Comcast address that was contained in a large email list.
Today I am not seeing the bad address again. I have tried to narrow down the scenario that causes different output messages at different times in order to help a potential developer fix this issue but am perplexed. One thought of mine is that there may be multiple pieces of code in Thunderbird that handle the received error message differently. Another is that Comcast doesn't format its message consistently but this isn't likely in my opinion.
Product: Core → MailNews Core
Summary: Mozilla will not send mail if one mail recipient generates an SMTP "550 unknown user" code → Mail not sent if one mail recipient generates an SMTP "550 unknown user" code
You need to log in before you can comment on or make changes to this bug.