At 12:04 PM -0500 2/25/03, ted crane wrote:Regardless of the direction of discussions and suggestions that might arise from my previous question, it should be noted that SIMS is receiving one 250 message and one 452 message, but is reporting two 452 messages in the log. Or so it seems.
However, the 4xx messages, in general, apply to the entire message rather than to individual transactions. According to the RFC, the valid 4xx codes at the "RCPT TO" point are:
450 Requested mail action not taken: mailbox unavailable [E.g., mailbox busy]
451 Requested action aborted: local error in processing
452 Requested action not taken: insufficient system storage
While I could understand a 450 or 451 message for an individual mailbox,
a 452 message to me would indicate that I should abort the ENTIRE message
(after all, they're out of room - why take what little they have left?)
and try later when the problem is corrected.
As Ted mentioned, this software does state that it isn't RFC compliant. OTOH, 452 does seem to be the closest proper response, based on RFC 2821. They seem to be applying the size limit for recipients, but reducing it from the RFC mandatory minimum of 100, down to 1. 452 is listed as a relevant response ("too many recipients"). If SIMS were sending a message with 101 recipient, got this error, and failed to transmit for those 100 recipients, removing them from the list, it _would_ be non-compliant. I haven't tested this case, though, and can't speak to its compliance here.
I'm quoting part of the relevant RFC below. The software *is* non-compliant, but there still may be compliance issues in SIMS. I understand that non-compliance, but I also feel that it is obnoxious and should not be encouraged. If I wanted to send separate emails, I'd send separate emails.
HTH, Tim
4.5.3.1 Size limits and minimums
[snip]
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.Errors due to exceeding these limits may be reported by using the reply codes. Some examples of reply codes are:
500 Line too long.
or
501 Path too long
or
452 Too many recipients (see below)
or
552 Too much mail data. RFC 821 [30] incorrectly listed the error where an SMTP server
exhausts its implementation limit on the number of RCPT commands
("too many recipients") as having reply code 552. The correct reply
code for this condition is 452. Clients SHOULD treat a 552 code in
this case as a temporary, rather than permanent, failure so the logic
below works.When a conforming SMTP server encounters this condition, it has at least 100 successful RCPT commands in its recipients buffer. If the server is able to accept the message, then at least these 100 addresses will be removed from the SMTP client's queue. When the client attempts retransmission of those addresses which received 452 responses, at least 100 of these will be able to fit in the SMTP server's recipients buffer. Each retransmission attempt which is able to deliver anything will be able to dispose of at least 100 of these recipients.
If an SMTP server has an implementation limit on the number of RCPT commands and this limit is exhausted, it MUST use a response code of 452 (but the client SHOULD also be prepared for a 552, as noted above). If the server has a configured site-policy limitation on the number of RCPT commands, it MAY instead use a 5XX response code. This would be most appropriate if the policy limitation was intended to apply if the total recipient count for a particular message body were enforced even if that message body was sent in multiple mail transactions.
--
We're at Code Orange right now and panic is the new black.
-- Paul F. Tompkins
############################################################# This message is sent to you because you are subscribed to the mailing list <[EMAIL PROTECTED]>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
