1

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.

2

From the small information I seen from Microsoft, see below quote, I think it was to prevent a loop when a mail client send a mail in a session, the mail is refused during the session and then the mail client retry to send. (thus making a loop)

Select the Limit session size to (KB) check box, and then type a value to indicate the maximum total size (in kilobytes) of all messages in a given connection. This number will always be larger than the maximum message size and should be set carefully because the connecting message transfer agent (MTA) is likely to resubmit the message repeatedly. The default size is 10240 KB. This value should be greater than or equal to the value entered for Limit message size to (KB).

From my own point of view;

I see an use for that limit as if in example I start to sell some viagra, via email "publicity", I could target a mail server and send a lot of "publicity" in one session before my IP get listed on public RBL list, as like Exchange check the initial remote connection. (reference)

IP Block List Providers are part of the connection filtering feature in Exchange. When the IP Block List Providers feature is enabled on a computer, the Connection Filter agent queries the specified IP Block List provider services to determine if the messaging server that has initiated the connection is a host that is known to send spam.


Keep in mind too that if your server send via a smarthost, like your ISP smtp's server, the ISP often scan outgoing email with RBL listing to be sure to limit the impact their customer have on the internet if their customer got infected with a spambot.

I bring that point as you can search for email throttling, as many big service will lower your IP reputation score if you send too much email to them in a short period.

A side note, there is an interesting question about a web service that send a lot of email.

  • So there are a couple of plausible reasons for a session size limit... both of them seem like obscure scenarios that don't apply in my case. I'm glad to see your first blockquote confirm that the session size is separately configurable. I found a copy of that documentation here for IIS 6, but couldn't find any equivalent documentation for IIS 7/7.5 so I just hope the options are still in the same place – Wumpus Q. Wumbley Feb 1 '17 at 21:40

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.