Closed
Bug 300937
Opened 19 years ago
Closed 3 years ago
RFC 2821 section 4.5.3.1 subsection "recipients buffer" limit not handled gracefully
Categories
(MailNews Core :: Networking: SMTP, defect)
MailNews Core
Networking: SMTP
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: derek.diget+bugzilla.mozilla.org-20050713, Unassigned)
Details
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20040618 Build Identifier: If a message is attempted to be sent with more recipients than the submission servers allows, Thunderbird gives an error and does not send the message or follow the behavior outlined in RFC 2821 section 4.5.3.1 subsection "recipients buffer". The error the user gets is as follows: "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: 4.5.3 Too many recipients specified.." Reproducible: Always Steps to Reproduce: 1. Have the submission SMTP server set to have a limit on envelope recipients equal or greater to the RFC2821 limit of 100. Say, 100. 2. Attempt to submit a message with 101 or more recipients. 3. Get error mentioned above. Actual Results: "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: 4.5.3 Too many recipients specified.." Expected Results: Per RFC 2821 section 4.5.3.1 subsection "recipients buffer" recipients buffer The minimum total number of recipients that must be buffered is 100 recipients. Rejection of messages (for excessive recipients) with fewer than 100 RCPT commands is a violation of this specification. The general principle that relaying SMTP servers MUST NOT, and delivery SMTP servers SHOULD NOT, perform validation tests on message headers suggests that rejecting a message based on the total number of recipients shown in header fields is to be discouraged. A server which imposes a limit on the number of recipients MUST behave in an orderly fashion, such as to reject additional addresses over its limit rather than silently discarding addresses previously accepted. A client that needs to deliver a message containing over 100 RCPT commands SHOULD be prepared to transmit in 100-recipient "chunks" if the server declines to accept more than 100 recipients in a single message. Thunderbird should have sent the messsage with the first "chunk" of recipients, done a RSET, and attempted to send the next "chunk" of recipients.
Updated•19 years ago
|
Assignee: mscott → nobody
Component: Message Compose Window → Networking: SMTP
Product: Thunderbird → Core
Version: unspecified → Trunk
Reporter | ||
Comment 1•18 years ago
|
||
I see a connection to this bug and bugs 197134 and 276029 in that the Networking:SMTP component needs to be able to handle the different SMTP response codes that a submission server replys with and handled them gracefully.
Comment 2•16 years ago
|
||
Bienvenu, thoughts?
Assignee | ||
Updated•16 years ago
|
Product: Core → MailNews Core
Updated•16 years ago
|
QA Contact: networking.smtp
Comment 3•15 years ago
|
||
bienvenu ping shall this be set to new ?
Comment 4•15 years ago
|
||
yes - we've done some work to handle invalid recipient errors, so if that work doesn't include detecting this error code, it shouldn't be too hard to extend it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 5•3 years ago
|
||
Version 91 has all new smtp backend code. If you can still reproduce this issue, please file a new bug report https://bugzilla.mozilla.org/enter_bug.cgi?product=MailNews%20Core&component=Networking%3A%20SMTP
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•