В качестве принимающего SMTP-сервера максимальный размер сообщения имеет смысл. Большое сообщение занимает место после получения. Полный диск недоволен пользователями.
Максимальное количество сообщений на отправителя за фиксированный период времени имеет смысл, особенно в сочетании с другими индикаторами спама. Спам тоже недоволен пользователями.
В настоящее время я отправляю почту через ретранслятор SMTP, у которого есть ограничение, отличное от любого из них: максимальный размер сеанса. Он не связан с любым ограничением количества сообщений, которые могут быть приняты, или размера этих сообщений.
Последовательность из 1000 сообщений, каждое из которых составляет несколько сотен КБ, будет отправлена только в том случае, если TCP-соединение будет закрыто и повторно открыто на полпути. Если они отправляются все в одном TCP-соединении, происходит следующее:
552 4.3.1 Session size exceeds fixed maximum session size
(Там есть связанный вопрос в котором упоминается то же самое сообщение об ошибке, но при этом затрагиваются только края проблемы; мой вопрос касается политических решений, а не точных расчетов того, что вписывается в конкретный предел.)
С точки зрения отправителя, это серьезная неприятность. Это заставляет вас разбивать пакеты отправки, чтобы соответствовать пределу, о котором вы даже не можете знать, пока не столкнетесь с ним.
Что получается с точки зрения получателя? Отправитель не предотвратить от отправки на множество сообщений или сообщений слишком большого размера. Только неудобно отправлять умеренное количество сообщений среднего размера. Использование одного или нескольких TCP-соединений - это то, о чем пользователи никогда не узнают.
Так, главный вопрос: Что происходило в головах разработчиков, когда они изобрели концепцию ограничения размера сеанса? И по какой причине администратор сервера мог ее включить?
ВЫ МОЖЕТЕ ПРЕКРАТИТЬ ЗДЕСЬ, ПРОПУСТИТЬ ОТДЫХ И РАЗРЕШИТЬ НА ГЛАВНЫЙ ВОПРОС
До сих пор я не называл никаких имен, потому что мне действительно нужно какое-то объяснение фундаментальной идеи здесь, а не какое-то умное обходное решение на стороне клиента. Сейчас добавлю подробности ...
Сервер и клиенты здесь находятся под управлением одной организации. Я запускаю (некоторые из) клиентов, которые являются веб-приложениями Adobe ColdFusion. Единственное, что я могу сделать, чтобы повлиять на размер SMTP-сеанса с этой стороны, - это полностью отключить повторное использование соединения. Таким образом, я мог бы перейти к одному сообщению для каждого соединения, но тогда я бы установил тонну соединений, которые могли бы выйти за какой-то другой предел (даже более оправданный).
Сервер - это IIS (а не Exchange, о котором упоминается в другом вопросе). Он идентифицирует себя так:
220 sendmail.example Microsoft ESMTP MAIL Service, Version: 7.5.7601.17514 ready at Wed, 1 Feb 2017 14:38:49 -0500
Проблема более раздражает, чем вы могли бы предположить, увидев сообщение об ошибке, потому что IIS отправляет ответ 552 и закрывает соединение. немедленно когда достигнут лимит байтов, вместо того, чтобы ждать момента в разговоре, когда наступит очередь говорить сервера. Будучи прерванным в середине отправки сообщения, ColdFusion отвечает самым глупым из возможных способов: он регистрирует сообщение как успешно отправленное. (Я планирую написать об этом отдельный отчет об ошибке.)
Сообщения просто исчезают случайным образом на основе их положения в потоке TCP, и единственная причина, по которой я знаю, что произошло, - это то, что я наконец уловил это с помощью Wireshark.
Я хочу попросить администратора SMTP-сервера удалить ограничение на размер сеанса, потому что оно бесполезно и вызывает неприятную ошибку, которая приводит к потере почты. Так что второстепенный вопрос: Возможно ли в IIS удалить ограничение на размер сеанса, не удаляя при этом ограничение на размер сообщения? Насколько я могу судить, эти 2 ограничения в настоящее время имеют одинаковое значение.
Из небольшой информации, которую я получил от Microsoft, см. Цитату ниже, я думаю, что это было сделано для предотвращения цикла, когда почтовый клиент отправляет письмо в сеансе, почта отклоняется во время сеанса, а затем почтовый клиент повторяет попытку отправки. (таким образом делая петлю)
Установите флажок «Ограничить размер сеанса до (КБ)», а затем введите значение, указывающее максимальный общий размер (в килобайтах) всех сообщений в данном подключении. Это число всегда будет больше, чем максимальный размер сообщения, и его следует устанавливать осторожно, поскольку агент передачи сообщений (MTA), вероятно, повторно отправит сообщение повторно. Размер по умолчанию - 10240 КБ. Это значение должно быть больше или равно значению, введенному для параметра Ограничить размер сообщения до (КБ).
С моей точки зрения;
Я вижу использование этого ограничения, как если бы, например, я начал продавать некоторую виагру, с помощью электронной почты «публичность», я мог бы настроить таргетинг на почтовый сервер и отправить много «публичности» за один сеанс, прежде чем мой IP-адрес попадет в общедоступный список RBL. , как и Exchange, проверяет исходное удаленное соединение. (ссылка)
Поставщики черных списков IP-адресов являются частью функции фильтрации подключений в Exchange. Если на компьютере включена функция поставщиков черного списка IP-адресов, агент фильтра подключений запрашивает указанные службы поставщика черного списка IP-адресов, чтобы определить, инициировал соединение - это хост, который рассылает спам.
Также имейте в виду, что если ваш сервер отправляет через смарт-хост, например smtp-сервер вашего интернет-провайдера, интернет-провайдер часто сканирует исходящую электронную почту со списком RBL, чтобы быть уверенным, что ограничит влияние своего клиента на Интернет, если его клиент заразился спам-ботом.
Я привожу этот момент, поскольку вы можете искать регулирование электронной почты, поскольку многие крупные службы снизят ваш рейтинг IP-репутации, если вы отправите им слишком много электронной почты за короткий период.
Кстати, есть интересный вопрос о веб-сервисе, который рассылает много писем.