Назад | Перейти на главную страницу

MTA обработка слишком больших писем

Если MTA получает электронное письмо, размер которого превышает ограничение на размер сообщения, какой вариант предпочтительнее? Что по умолчанию для обычных почтовых серверов?

  1. Отклонить электронное письмо во время сеанса SMTP. Доставляющий MTA должен отправить сообщение о недоставке исходному отправителю.
  2. Примите почту и немедленно отправьте сообщение о недоставке исходному отправителю.
  3. Примите почту и отправьте сообщение о недоставке исходному отправителю по истечении времени ожидания.

Я видел, как сервер делал 3. и ждал 5 дней, прежде чем отправить отказ. Мне кажется, такое поведение не имеет смысла, поскольку ограничение на размер сообщения вряд ли будет часто меняться. Не следует ли сразу же рассматривать превышение лимита размера сообщения как постоянную ошибку?

RFC 1860 Раздел 6.1 (2) гласит, что при получении почтового сообщения, размер которого превышает максимально допустимый размер, принимающий сервер может ответить отправляющему серверу со статусом SMTP "552 message size exceeds fixed maximium message size"

MTA не обязан отвечать на отказ с помощью 522, но это предпочтительный метод (и ожидается от большинства других MTA и почтовых администраторов).

Уведомление об отказе отправителю обрабатывается MTA отправителя и не должно быть фактором вашего MTA. Ваш сервер, отправляющий отчеты о недоставке, является потенциальной проблемой для спама (я создаю сообщения SMTP с MAIL FROM: you@your.com и вы получаете все мои отказы, потому что чужой MTA неправильно отправил вам NDR)

Но прямо отвечу на ваш вопрос. №1 - это единственный метод, который следует со всеми RFC, относящимися к SMTP, а также с общепринятой практикой и практикой сокращения спама.

Обратите внимание, что я подозреваю, что №3 происходит из-за того, что почтовый ящик переполнен, но принимающая система считает, что в конечном итоге он может оказаться достаточно пустым для приема почты. Вероятно, он отправляет обратно ошибку 4xx (временный сбой), и отправляющая система продолжает попытки в течение 5 дней, а затем отправляет отскок пользователю.

Кроме того, в качестве дополнительного комментария к превосходному резюме Рускала, приведенному выше, существует сложность с получением почты, из-за которой вы не можете отправить этот код ответа в середине сеанса DATA. Вам нужно дождаться конца маркера данных (\ r \ n. \ R \ n), прежде чем вы сможете его отправить. Это означает, что некоторые системы МОГУТ просто отключиться (после попытки отправить ответ 522 в любом случае) в точке слишком большого размера почты, чтобы предотвратить DoS-атаки с размером DATA. Это нечасто, но это досадная слабость (старой) системы SMTP.

Если, однако, обе системы используют ESMTP и поддержка RFC 1653, то это может быть уменьшено до передачи ДАННЫХ.