3

If an MTA receives an email that exceeds the message size limit, which bevaviour is preferred? What is the default for common mail servers?

  1. Reject the email during the SMTP session. The delivering MTA must send a bounce message to the original sender.
  2. Accept the mail and send a bounce message to the original sender immediately.
  3. Accept the mail and send a bounce message to the original sender after a timeout.

I've seen a server do 3. and wait for 5 days before sending the bounce. It seems to me this behavior does not make sense as the message size limit is not likely to change often. Should an exceeded message size limit not be immediately regarded as a permanent error?

5
  • 2. and 3. should be "bounce" message, sorry!
    – chriddy
    Sep 12, 2013 at 13:38
  • 5
    Neither 2 nor 3 make technical sense to me. Why would you want to accept the message and then send a bounce message? The purpose of having a limit is to not have to deal with messages that exceed a certain size. By accepting the message, you're dealing with it, which strikes me as counterintuitive to having a message size limit.
    – joeqwerty
    Sep 12, 2013 at 13:43
  • Thanks Joe, I agree. Question is if any RFC forbids a server to do 2. or 3. If I see this behaviour, would there be a reason for a complaint to the postmaster? It is definitely annoying to have an email "disapper" for 5 days.
    – chriddy
    Sep 12, 2013 at 18:38
  • Thanks to everyone who commented. I have learned a lot about SMTP from this discussion.
    – chriddy
    Sep 14, 2013 at 9:20
  • I am late to the party here but I have a question because I am working on a smtp server implementation. What is the state of the smtp server session when an email is "rejected"? For example, The server detects that a message is too large and sends a 552. Does the client now have to restart the handshake with EHLO? Or can the client start over at MAIL FROM?
    – cchampion
    Jun 15, 2016 at 11:13

2 Answers 2

4

RFC 1860 Section 6.1(2) states that upon reciept of a mail message that is larger than the maximum size limit, the receiving server may respond to the sending server with an SMTP status of "552 message size exceeds fixed maximium message size"

The MTA isn't required to respond to the rejection with a 522, but that is the preferred method (and expected by most other MTAs and mail administrators).

The rejection notice to the sender is handled by the senders MTA and should not be a factor of your MTA. Your server sending NDRs is a potential spam issue (I craft SMTP messages with a MAIL FROM: [email protected] and you get all of my bounces because someone else's MTA improperly sent you NDRs)

But to directly answer your question. #1 is the only method that follows with all the RFCs relating to SMTP as well as with generally accepted practice and spam reduction practices.

3
  • Other acceptable codes from the receiving MTA are 534 (Message too big for receiving system) 523 (message too big for mailbox, if the mailbox has a limit smaller than the system general limit), 522 (if the mailbox is full, even if the size would normally allow transit)..
    – Ruscal
    Sep 12, 2013 at 16:37
  • Thank you, Ruscal, for your well-reasoned answer. How would, e.g., a Postfix installation behave by default? In the docs at postfix.org, I find the parameter message_size_limit, but no way to configure what happens when it is exceeded.
    – chriddy
    Sep 12, 2013 at 18:35
  • Postfix shoud respond to the attempted transmission with a 5** code. I have seen message_size_limit cause 5.3.4 from Postfix (Message exceeds system defined limits). So it would reject the message before data transmit (assuming ESMTP w/ EHLO handshake; otherwise it would listen to the whole DATA stream and then respond with the 5.3.4. Either way ends with the receiver telling the sender that a 5xx error occurred)
    – Ruscal
    Sep 13, 2013 at 18:15
1

Note that I suspect #3 is happening because the mailbox is full, but the receiving system believes it may eventually be empty enough to receive the mail. It probably sends back a 4xx error (temporary failure) and the sending system keeps trying for 5 days, and then sends a bounce to the user.

Also as a further comment to Ruscal's excellent summary above, there's a complication with receiving mail that you can't send that response code in the middle of the DATA session. You have to wait until the end of data marker (\r\n.\r\n) before you can send it. This means some systems MAY just disconnect (after trying to send the 522 response anyway) at the point of the mail being too large, to prevent DATA size DoS attacks. This isn't common, but it is an unfortunate weakness of the (old) SMTP system.

If however both systems are using ESMTP and support RFC 1653, then this can be mitigated before the DATA is transmitted.

1
  • Actually, the error message was "message size limit exceeded", but it still took 5 days. I should have provided more data in my original question.
    – chriddy
    Sep 14, 2013 at 9:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .