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?

DanBig
  • 11,393
  • 1
  • 28
  • 53
chriddy
  • 33
  • 3
  • 2. and 3. should be "bounce" message, sorry! – chriddy Sep 12 '13 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 '13 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 '13 at 18:38
  • Thanks to everyone who commented. I have learned a lot about SMTP from this discussion. – chriddy Sep 14 '13 at 09: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 '16 at 11:13

2 Answers2

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: you@your.com 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.

Community
  • 1
Ruscal
  • 1,223
  • 6
  • 13
  • 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 '13 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 '13 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 '13 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.

Matt Sergeant
  • 504
  • 2
  • 5
  • 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 '13 at 09:19