User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 Build Identifier: Mozilla Thunderbird version 1.0.6 (20050716) Problem first found when developing a Microsoft Access database. There is a facility to email a list of people from the database. A process reads every record, puts all the email addresses into a variable (varEmail) and sends the variable to the Email program with this VBA code: DoCmd.SendObject acSendNoObject, , , varEmail The default Email program will open and place all the addresses into the "To" line. The user may then complete the email message and send. This procedure should work with any MAPI compliant email program. It works well with Outlook, Outlook Express and Eudora. However with Thunderbird, Access returns and error message that there were "Too many message recipients". There are in fact about 150 addresses. I can cut and paste the entire list into Thunderbird's address line, it just will not accept that many addresses from Access. Note: I did not actually send the message - not wanting to upset all those users. I refer to an already logged bug - 113251 which may yet cause problems with too many recipients. The process works with Thunderbird if there are not too many recipients eg 50 Also noted by another user: when cut/paste more than 200 addresses, Thunderbird responds with the following message: "The size of the message you are trying to send exceeds a temporary size limit of the server. The message was not sent, try to reduce the message size and try again. The server responded: Too many recipients." Reproducible: Always Steps to Reproduce: 1.Issue the VBA code from the Access database 2. 3. Actual Results: Error message - Too many Recipients" Expected Results: Inserted all recipients into the "To:" box Refer to Bug 113251
I use Thunderbird 188.8.131.52 (20060909). I want to prepare a mail with many recipients with the MapiSendMail command. I found out that Thunderbird accepts up to exactly 100 recipients, 101 and more recipients are rejected with the error MAPI_E_TOO_MANY_RECIPIENTS. Why only 100 recipients? I guess the developer thought nobody needs more than 100 recipients so he just put this limit here. But I need more recipients! Please remove the check of the number of recipients and allow unlimited recipients. Thanks! BTW: Outlook has no problem with more than 100 recipients...
TB version 3.0a1pre (2008050203) in WinXP I was able to paste >900 comma delimited email-id to the TO: field on pressing tab to move to next line/field, TB started to reformat the mail id to one id per line and gave multiple script too long error message. I kept pressing "Continue" many times and finally the script finished splitting email-id list and reformatting one per line. So it looks like WORKSFORME. Following is the "script too long" message I got. ========== Script too long message ========== A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete. Script: chrome://messenger/content/messengercompose/addressingWidgetOverlay.js:1058 ============== end of message ==============
BTW: I have SMTP/POP email account not the MAPI
http://kb.mozillazine.org/Limits_-_Thunderbird states that: > There appears to be a limit of approximately 60 addresses when sending messages > if you enter each address separately. So what is the current official number of allowed recipients (either in one line or separate) ?
(In reply to comment #4) > So what is the current official number of allowed recipients (either in one line or separate) ? Przemyslaw Bialik, read RFC 2822, please. > http://www.faqs.org/rfcs/rfc2822.html > 2.1.1. Line Length Limits > There are two limits that this standard places on the number of > characters in a line. Each line of characters MUST be no more than > 998 characters, and SHOULD be no more than 78 characters, excluding > the CRLF. This is not limitation by architecture or design. Practical reason. It's described as following in the "2.1.1. Line Length Limits" section. > However, there are so > many implementations which (in compliance with the transport > requirements of [RFC2821]) do not accept messages containing more > than 1000 character including the CR and LF per line, it is important > for implementations not to create such messages. And maximum number of field(==A mail header, To: in this bug's case) is ONE. > 3.6. Field definitions > Field Min number Max number Notes > to 0 1 > cc 0 1 > bcc 0 1 In contrast to RFC 2822, RFC2821(SMTP) itself doesn't limit number of RCPT commands(RECIPIENT). This is the reason why mailing list(and spammers too) can send a mail to many persons at once with short To: <mailing_list_address>(usually no CC:/no BCC:. i.e. sent as bcc). Further, because RFC2821(SMTP) doesn't care for mail header content(defined by RFC2822), spammers can write any From:/To:/CC: header in spam mail.
Hi, we have come across this bug too. We have a mission-critical foxpro database application which is being used by upward of 50 staff. One of its functions is to send an email to users within the database and like the other reports, this fails when there are more than around 100 email addresses. This is forcing users who want to use TB to go back to Outlook and putting egg on our faces for recommending TB. I don't think I believe the RFC line limit is the issue. If you look at section 2.2.3, of the same document it says: Each header field is logically a single line of characters comprising the field name, the colon, and the field body. For convenience however, and to deal with the 998/78 character limitations per line, the field body portion of a header field can be split into a multiple line representation; this is called "folding". The general rule is that wherever this standard allows for folding white space (not simply WSP characters), a CRLF may be inserted before any WSP. For example, the header field: Subject: This is a test can be represented as: Subject: This is a test This bug is a VERY serious problem for us. What can we do to get it fixed?
Hi again, I've had a root around in the code and it looks like fixing this issue would be pretty straightforward -- in that you can just increase the limit. The patch below is written against the latest release of thunderbird, 2.0.18. At the minute I don't have a build environment for TB but I will try and set one up to test this shortly. We _really_ don't want to maintain our own custom version of thunderbird so it would be far preferable if this could be accepted into the mozilla trunk. I don't believe the quoted RFC justifies this limitation and it has been said that Eudora and Outlook don't show this problem. Comments welcome, Gavin --- mozilla/mailnews/mapi/mapiDll/MapiDll.cpp 2004-04-29 20:58:22.000000000 +0100 +++ mozilla2/mailnews/mapi/mapiDll/MapiDll.cpp 2008-08-26 17:43:39.000000000 +0100 @@ -45,7 +45,7 @@ #include "msgMapiMain.h" #define MAX_RECIPS 100 -#define MAX_FILES 100 +#define MAX_FILES 2000 #define MAX_NAME_LEN 256
Ahem! In a little haste, that patch was ever so slightly wrong :-) This time it should be right, see below. Gavin --- mozilla/mailnews/mapi/mapiDll/MapiDll.cpp 2004-04-29 20:58:22.000000000 +0100 +++ mozilla2/mailnews/mapi/mapiDll/MapiDll.cpp 2008-08-26 18:05:09.000000000 +0100 @@ -44,7 +44,7 @@ #include "msgMapi.h" #include "msgMapiMain.h" -#define MAX_RECIPS 100 +#define MAX_RECIPS 2000 #define MAX_FILES 100
The limit up 100 recipients is still there in the current version 184.108.40.206 (20080708) and the MapiSendMail command. Gavin has found the line of code: Hey mozilla-team, it's only ONE line of code to change! Now it's very disappointing to get the message that Dan Mosedale has changed the assignment to "nobody". Don't change the assignment change the single line of code!
(In reply to comment #9) > Now it's very disappointing > to get the message that Dan Mosedale has changed the assignment to "nobody". That was a block change to remove someone from the assignee field who is currently not working on anything mozilla. > Don't change the assignment change the single line of code! Gavin, if you want to get your fix into the tree, please take a look at http://developer.mozilla.org/En/Getting_your_patch_in_the_tree You'll need to make it an attachment for starters, and provide a patch for the current trunk builds as well. For getting the source for these see http://developer.mozilla.org/en/docs/comm-central
Hi, (In reply to comment #10) > Gavin, if you want to get your fix into the tree, please take a look at > http://developer.mozilla.org/En/Getting_your_patch_in_the_tree > > You'll need to make it an attachment for starters, Of course :-) > and provide a patch for the current trunk builds as well. For getting the > source for these see > http://developer.mozilla.org/en/docs/comm-central I'll try and do this next week, thanks. Gavin
Hi, Apologies for the _huge_ delay on this but I haven't had much time for it myself. A student here in the college has been tasked with setting up a build environment, making the above change to the code and testing. Initial indications are very positive. We used our foxpro database application to send a mapi call with over 500 addresses in BCC. This appeared to work perfectly. We didn't actually send the email, but I don't think that should be an issue. Thunderbird popped up a new email window with the full list of emails in the BCC. I've asked him to write a small command line application which reads in a set of email addresses from a file and makes a MAPI call. Hopefully with this tool we can stress test things a little more. If anyone is interested in a built executable of thunderbird 220.127.116.11 for testing, we'll happily supply it. Gavin
(In reply to comment #12) > I've asked him to write a small command line application which reads in a set > of email addresses from a file and makes a MAPI call. Hopefully with this tool > we can stress test things a little more. > > If anyone is interested in a built executable of thunderbird 18.104.22.168 for > testing, we'll happily supply it. Do you also intend to fix Trunk ? Do you intend to release this "stress" tool in the open ?
Hi, (In reply to comment #13) > Do you also intend to fix Trunk ? Yes. We're keen to get this fixed and never have to worry about it again. We have the v3-beta2 downloaded to test it against that too. I know I have some things to do (resubmit as an attachment) which I'll do shortly. I have to check if the patch is different for > Do you intend to release this "stress" tool in the open ? Absolutely. Though it remains to be seen how useful it will be to others. All we have planned at the moment is a short piece of code which will allow the user to pass a file with an arbitrary list of email addresses to a MAPI sendmail call. This will test the limit of how many recipients we can safely pass. If you have ideas for further features, let me know and I'll see what we can get done. It looks like the thunderbird mapi code doesn't change very often so I'm not sure how much is needed here. Gavin
Created attachment 373713 [details] [diff] [review] patch to increase the maximum recipients for MAPI calls from 100 to 2000 following the discussion on this bug and some testing, I'd like to request this patch be reviewed.
David does this needs super-review to land ?
Yes, bienvenu: wanna sr it too?
Thanks for the patch, this is now checked in to trunk: http://hg.mozilla.org/comm-central/rev/7eabb9c5de71
Many thanks for accepting the patch. I realise this is the wrong time to say this but does anyone know what would be a reasonable limit for this. Our choice of 2000 was fairly arbitrary and someone here tells me that even that might not always be enough. Is there a sensible limit which should be placed? Does TB itself have a maximum recipients? Is there any virus-spreading implication in having the number very large?
(In reply to comment #19) > > Is there a sensible limit which should be placed? Does TB itself have a > maximum recipients? Is there any virus-spreading implication in having the > number very large? As I remember, virus-spreading was the whole reason for having this number be relatively small. The code was written around the time some MS products were getting infected regularly. But if you can make one mapi call, you can make two, so it's not like a low number is really making it that much harder for malware. I don't know what a reasonable limit would be - I think the way the code is written, it does require the limit to be a static number, but I don't remember for sure.
Yeah, it's a compiled constant. The number is declared to the pre-processor: #define MAX_RECIPS 100 and used only once: if (lpMessage->nRecipCount > MAX_RECIPS) return MAPI_E_TOO_MANY_RECIPIENTS ; You could easily remove the check entirely, but I'm not sure that would be a good idea. You could make it configurable which might be an interesting compromise in that it could be set to something low like 100 by default but then raised by users who actually need that.
....as you say though, if a virus can send one it can send as many as it likes so perhaps a limit isn't really that useful.
Is there any possibility that this fix could be put into a stable release of v2 any time soon? It doesn't appear to be in v22.214.171.124?? Thanks, Gavin
To ask for it to be included into v2.0.0.x, set the approval1.8.1.next? flag on the patch. At least it's very small, and i haven't heard of any problems caused by it.
Comment on attachment 373713 [details] [diff] [review] patch to increase the maximum recipients for MAPI calls from 100 to 2000 just hoping to get this into a stable release asap. thanks
I see that thunderbird v2 releases are (understandably) rare at this point. Can I assume that any new release of Thunderbird (v2 or v3) will contain this fix? Sorry, I'm a little ignorant of how the patch approval process. We still have staff suffering from this and would rather avoid deploying a build of our own. Is a further release of v2 likely or do we need to wait for v3?
This will be in v3, which should come out in a matter of weeks.
Comment on attachment 373713 [details] [diff] [review] patch to increase the maximum recipients for MAPI calls from 100 to 2000 Approved for 126.96.36.199, a=dveditz for release-drivers
fixed landed for 188.8.131.52
Can someone who was encountering this issue attempt their e-mail using the nightly Thunderbird 184.108.40.206pre build? This can be found at ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-mozilla1.8/. It would be good to verify that this issue is fixed.