As a receiving SMTP server, a maximum message size makes sense. A huge message takes up space after it is received. A full disk makes users unhappy.
A maximum number of messages per sender in a fixed time period makes sense, especially if combined with other spam indicators. Spam makes users unhappy too.
I'm currently sending mail through an SMTP relay which has a limit unlike either of those: a maximum session size. It is separate from any limit on the number of messages that can be accepted or the size of those messages.
A series of 1000 messages, each one being a few hundred KB, will only go through if the TCP connection is closed and reopened half-way through. If they're sent all in one TCP connection, this happens:
552 4.3.1 Session size exceeds fixed maximum session size
(There is a related question that mentions the same error message, but it only nibbles around the edges of the issue; my question is about policy decisions, not about precise calculations of what will fit in a particular limit.)
From the sender's point of view, this is a major nuisance. It forces you to break up your sending batches to fit a limit that you can't even know about until you've run into it.
From the receiver's point of view, what is gained? A sender is not prevented from sending to many messages, or messages that are too large. It's only made inconvenient to send a moderate number of medium-sized messages. The use of one TCP connection or multiple TCP connections is something that the users can never possibly know about.
So, main question: what was going on in the minds of the implementors when they invented the concept of a session size limit? And what reason could a server administrator have for enabling it?
YOU CAN STOP READING HERE, IGNORE THE REST, AND TACKLE THE MAIN QUESTION
Up until now I haven't named any names, because I really want some explanation of the fundamental idea here, not some clever client-side workaround. Now I will add details...
The server and clients here are under the control of the same organization. I run (some of) the clients, which are Adobe ColdFusion web applications. The only thing I can do to influence the size of an SMTP session from that end would be to disable connection reuse entirely. So I could go to one message per connection, but then I'd be making a ton of connections, which might run into some other limit (a more justifiable one even).
The server is IIS (not Exchange, which is mentioned in the other question). It identifies itself like this:
220 sendmail.example Microsoft ESMTP MAIL Service, Version: 7.5.7601.17514 ready at Wed, 1 Feb 2017 14:38:49 -0500
The problem is more annoying than you'd guess from seeing the error message, because IIS sends the 552 response and closes the connection immediately when the byte limit is hit, rather than waiting for a point in the conversation where it is the server's turn to talk. Being interrupted in the middle of sending a message, ColdFusion responds in the stupidest way possible: it logs the message as successfully sent. (I plan a separate bug report on that.)
Messages just randomly disappear based on their position within the TCP stream, and the only reason I know what happened is that I finally caught it happening with Wireshark.
I want to ask the SMTP server administrator to remove the session size limit because it serves no purpose and it's triggering a nasty bug that loses mail. So the secondary question: is it possible in IIS to remove the session size limit without also removing the message size limit? As far as I can tell, those 2 limits currently have the same value.