Обработка MTA слишком больших электронных писем
допустите ошибку 41, "из памяти" ошибка (не может делать с этим много, кроме удаления некоторых данных).
допустите ошибку 8062, ошибка доступа запрещен.
Выполните Дисковую утилиту и нажмите на кнопку "Repair Permissions", которая должна зафиксировать 8062.
RFC 1860 Раздел 6.1 (2) гласит, что при получении почтового сообщения, размер которого превышает максимально допустимый размер, принимающий сервер может ответить отправляющему серверу со статусом SMTP. of " 552 размер сообщения превышает фиксированный максимальный размер сообщения "
MTA не требуется отвечать на отклонение с помощью 522, но это предпочтительный метод (и ожидается большинством других MTA и почты администраторов).
Уведомление об отказе отправителю обрабатывается MTA отправителя и не должно быть фактором вашего MTA. Ваш сервер, отправляющий отчеты о недоставке, является потенциальной проблемой для спама (я создаю SMTP-сообщения с помощью MAIL FROM: you@your.com и вы получаете все мои отказы, потому что чей-то другой MTA неправильно отправил вам NDR)
Но прямо отвечу на ваш вопрос. №1 - единственный метод, который следует со всеми RFC, относящимися к SMTP, а также с общепринятой практикой и практикой сокращения спама.
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.