«Отправка SMTP отклонена 452 4.5.3 Слишком много получателей» на Exchange, хотя, очевидно, это не так

С большим количеством журналов и небольшой помощью службы поддержки Miscrofot мы поняли это и узнали кое-что о JavaMail в процессе.

1. включить журналы отладки SMTP низкого уровня. В большинстве java-приложений это будет что-то вроде

  mail:
    default-encoding: UTF-8
    host: ${MAIL_HOST}
    port: ${MAIL_PORT}
    properties:
      mail:
        transport:
          protocol: smtp
        debug: true
        smtp:
          debug: true
          auth: false
          starttls: true

при запуске приложения мы получили что-то вроде этого (осторожно, это, скорее всего, будет выводиться в стандартном выходе, а не в вашем обычном лог-файле приложения):

DEBUG SMTP: Found extension "STARTTLS", arg ""
DEBUG SMTP: Found extension "8BITMIME", arg ""
DEBUG SMTP: Found extension "BINARYMIME", arg ""
DEBUG SMTP: Found extension "CHUNKING", arg ""
DEBUG SMTP: Found extension "SMTPUTF8", arg ""
DEBUG SMTP: use8bit false
MAIL FROM:<[email protected]>
250 2.1.0 Sender OK
RCPT TO:<[email protected]>
250 2.1.5 Recipient OK
RCPT TO:<[email protected]>
550 5.4.1 Recipient address rejected: Access denied. AS(201806281) [XXXXXXXXXXXXXXXXX.protection.outlook.com 2023-03-15T09:46:28.930Z 08DB25286CBA473D]
RCPT TO:<[email protected]>
452 4.5.3 Too many recipients ATTR49 [XXXXXXXXXXXXXXXXXXX.protection.outlook.com 2023-03-15T09:46:28.930Z 08DB25286CBA473D]
DEBUG SMTP: Valid Unsent Addresses
DEBUG SMTP:   [email protected]
DEBUG SMTP:   [email protected]
DEBUG SMTP: Invalid Addresses
DEBUG SMTP:   [email protected]
DEBUG SMTP: Sending failed because of invalid destination addresses
RSET
250 2.0.0 Resetting
DEBUG SMTP: MessagingException while sending, THROW: 
javax.mail.SendFailedException: Invalid Addresses;
  nested exception is:
com.sun.mail.smtp.SMTPAddressFailedException: 550 5.4.1 Recipient address rejected: Access denied. AS(201806281) [XXXXXXXXXXXXXXXXX.prod.protection.outlook.com 2023-03-15T09:46
:28.930Z 08DB25286CBA473D]
;
  nested exception is:
com.sun.mail.smtp.SMTPAddressFailedException: 452 4.5.3 Too many recipients ATTR49 [XXXXXXXXXXXXXXXXX.protection.outlook.com 2023-03-15T09:46:28.930Z 08DB25286CBA473D]

У нас тут 2 проблемы:

• почтовый шлюз принимает только отправителя из настроенного домена — это нормально, чтобы избежать проблем с открытой ретрансляцией, когда спамеры используют ваш почтовый сервер. Здесь для наших тестов мы не обращали внимания и использовали случайный отправитель вместо адреса с my-domain.com (т.е. нашего домена)

• поскольку шлюз управляет нашим доменом, он знает, какие адреса существуют или нет в нашем домене. и действительно, [email protected] — это тестовое значение, которого на самом деле не существует в Exchange:

    DEBUG SMTP: Invalid Addresses
    DEBUG SMTP:   [email protected]

Шлюз настроен так, чтобы сообщать SMTP-клиенту, что некоторые адреса, на которые мы отправляем, не существуют. это пограничная блокировка на основе каталогов, описанная здесь.

Мы обнаружили, что на самом деле есть параметр клиента javamail, который тем не менее заставляет отправлять электронные письма: установка свойства mail.smtp.sendpartial на true будет отправлять электронные письма существующим получателям и вызывать исключение в коде, чтобы мы знали, что электронное письмо не может быть отправлено некоторым получатели, и мы рассматриваем этот случай соответствующим образом.

см. в https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-summary.html

Если установлено значение true, и в сообщении есть несколько действительных и несколько недопустимых адреса, все равно отправить сообщение, сообщив о частичном сбое с помощью исключение SendFailedException. Если установлено значение false (по умолчанию), сообщение не отправляется ни одному из получателей, если есть недействительный получатель адрес.

Вывод: исходное сообщение, которое мы получили в исключении, явно вводит в заблуждение (я бы назвал это ошибкой). Я понятия не имею, почему он говорит «Слишком много получателей», хотя это явно не так, но с правильными журналами отладки и конфигурацией на стороне клиента мы смогли понять, что не так, и исправить это.