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)

defect
Not set
normal

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.
Assignee: mscott → nobody
Component: Message Compose Window → Networking: SMTP
Product: Thunderbird → Core
Version: unspecified → Trunk
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.
Product: Core → MailNews Core
QA Contact: networking.smtp
bienvenu ping shall this be set to new ?
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

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.