Last Comment Bug 305168 - Too many recipients when copy/paste address line or sending from MS Access (increase max to 2000)
: Too many recipients when copy/paste address line or sending from MS Access (i...
Status: RESOLVED FIXED
: fixed1.8.1.24
Product: MailNews Core
Classification: Components
Component: Backend (show other bugs)
: unspecified
: x86 Windows XP
: -- normal (vote)
: Thunderbird 3.0b3
Assigned To: Gavin McCullagh
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-18 22:54 PDT by nigel_quayle
Modified: 2010-02-19 16:03 PST (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
patch to increase the maximum recipients for MAPI calls from 100 to 2000 (338 bytes, patch)
2009-04-20 12:28 PDT, Gavin McCullagh
mozilla: review+
mozilla: superreview+
dveditz: approval1.8.1.next+
Details | Diff | Review

Description nigel_quayle 2005-08-18 22:54:42 PDT
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
Comment 1 Hans Peter Kunz 2006-10-31 10:19:22 PST
I use Thunderbird 1.5.0.7 (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...
Comment 2 Biju 2008-06-05 23:19:11 PDT
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 ==============
Comment 3 Biju 2008-06-05 23:21:12 PDT
BTW: I have SMTP/POP email account not the MAPI
Comment 4 Przemyslaw Bialik 2008-06-06 11:09:41 PDT
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) ?
Comment 5 WADA 2008-06-06 16:01:01 PDT
(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.
Comment 6 Gavin McCullagh 2008-06-12 08:46:29 PDT
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?

Comment 7 Gavin McCullagh 2008-08-26 10:01:55 PDT
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
Comment 8 Gavin McCullagh 2008-08-26 10:06:12 PDT
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
Comment 9 Hans Peter Kunz 2008-08-29 02:59:40 PDT
The limit up 100 recipients is still there in the current version 2.0.0.16 (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!
Comment 10 Mark Banner (:standard8) 2008-08-29 04:02:55 PDT
(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
Comment 11 Gavin McCullagh 2008-08-29 04:19:20 PDT
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
Comment 12 Gavin McCullagh 2009-04-20 08:51:36 PDT
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 2.0.0.21 for testing, we'll happily supply it.

Gavin
Comment 13 Ludovic Hirlimann [:Usul] 2009-04-20 11:18:30 PDT
(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 2.0.0.21 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 ?
Comment 14 Gavin McCullagh 2009-04-20 11:45:27 PDT
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
Comment 15 Gavin McCullagh 2009-04-20 12:28:25 PDT
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.
Comment 16 Ludovic Hirlimann [:Usul] 2009-04-21 07:49:15 PDT
David does this needs super-review to land ?
Comment 17 Magnus Melin 2009-04-21 12:55:47 PDT
Yes, bienvenu: wanna sr it too?
Comment 18 Mark Banner (:standard8) 2009-04-22 00:34:56 PDT
Thanks for the patch, this is now checked in to trunk: http://hg.mozilla.org/comm-central/rev/7eabb9c5de71
Comment 19 Gavin McCullagh 2009-04-22 02:46:14 PDT
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?
Comment 20 David :Bienvenu 2009-04-22 07:01:07 PDT
(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.
Comment 21 Gavin McCullagh 2009-04-22 08:29:08 PDT
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.
Comment 22 Gavin McCullagh 2009-04-22 08:29:55 PDT
....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.
Comment 23 Gavin McCullagh 2009-08-31 09:56:40 PDT
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 v2.0.0.23??

Thanks,
Gavin
Comment 24 Magnus Melin 2009-08-31 10:18:43 PDT
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 25 Gavin McCullagh 2009-08-31 10:28:20 PDT
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
Comment 26 Gavin McCullagh 2009-11-10 06:22:00 PST
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?
Comment 27 David :Bienvenu 2009-11-10 06:40:23 PST
This will be in v3, which should come out in a matter of weeks.
Comment 28 Daniel Veditz [:dveditz] 2010-01-19 12:48:24 PST
Comment on attachment 373713 [details] [diff] [review]
patch to increase the maximum recipients for MAPI calls from 100 to 2000

Approved for 1.8.1.24, a=dveditz for release-drivers
Comment 29 David :Bienvenu 2010-01-19 17:19:55 PST
fixed landed for 1.8.1.24
Comment 30 Al Billings [:abillings] 2010-02-19 16:03:21 PST
Can someone who was encountering this issue attempt their e-mail using the nightly Thunderbird 2.0.0.24pre 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.

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