The default bug view has changed. See this FAQ.

Too many recipients when copy/paste address line or sending from MS Access (increase max to 2000)

RESOLVED FIXED in Thunderbird 3.0b3

Status

MailNews Core
Backend
RESOLVED FIXED
12 years ago
7 years ago

People

(Reporter: nigel_quayle, Assigned: Gavin McCullagh)

Tracking

({fixed1.8.1.24})

unspecified
Thunderbird 3.0b3
x86
Windows XP
fixed1.8.1.24

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
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

11 years ago
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...
QA Contact: general

Comment 2

9 years ago
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

9 years ago
BTW: I have SMTP/POP email account not the MAPI

Comment 4

9 years ago
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.
(Assignee)

Comment 6

9 years ago
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?

(Assignee)

Comment 7

9 years ago
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
(Assignee)

Comment 8

9 years ago
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

Updated

9 years ago
Assignee: mscott → nobody

Comment 9

9 years ago
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!
(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
(Assignee)

Comment 11

9 years ago
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
(Assignee)

Comment 12

8 years ago
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
(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 ?
(Assignee)

Comment 14

8 years ago
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
(Assignee)

Comment 15

8 years ago
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.
Attachment #373713 - Flags: review?
Attachment #373713 - Flags: review? → review?(bienvenu)

Updated

8 years ago
Attachment #373713 - Flags: review?(bienvenu) → review+
David does this needs super-review to land ?

Comment 17

8 years ago
Yes, bienvenu: wanna sr it too?
Assignee: nobody → www_gmc
Status: UNCONFIRMED → ASSIGNED
Component: General → Backend
Ever confirmed: true
Product: Thunderbird → MailNews Core
QA Contact: general → backend
Target Milestone: --- → Thunderbird 3.0b3

Updated

8 years ago
Attachment #373713 - Flags: superreview+

Updated

8 years ago
Keywords: checkin-needed
Summary: Too many recipients when copy/paste address line or sending from MS Access → Too many recipients when copy/paste address line or sending from MS Access (increase max to 2000)
Thanks for the patch, this is now checked in to trunk: http://hg.mozilla.org/comm-central/rev/7eabb9c5de71
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
(Assignee)

Comment 19

8 years ago
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

8 years ago
(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.
(Assignee)

Comment 21

8 years ago
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.
(Assignee)

Comment 22

8 years ago
....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.
(Assignee)

Comment 23

8 years ago
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 24

8 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago8 years ago
Resolution: --- → FIXED
(Assignee)

Updated

8 years ago
Attachment #373713 - Flags: approval1.8.1.next?
Attachment #373713 - Flags: approval1.8.0.next?
(Assignee)

Comment 25

8 years ago
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

Updated

8 years ago
Attachment #373713 - Flags: approval1.8.0.next?
(Assignee)

Comment 26

8 years ago
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

8 years ago
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 1.8.1.24, a=dveditz for release-drivers
Attachment #373713 - Flags: approval1.8.1.next? → approval1.8.1.next+

Updated

7 years ago
Keywords: fixed1.8.1.24

Comment 29

7 years ago
fixed landed for 1.8.1.24
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.
You need to log in before you can comment on or make changes to this bug.