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

конфигурация exim: команда 503 AUTH используется, когда не объявлена

Я запускаю программное обеспечение на сервере Windows, которое отправляет уведомления по электронной почте через удаленный SMTP-сервер. Он имеет очень мало параметров конфигурации и поддерживает только базовую аутентификацию SMTP без SSL / TLS. У меня exim4 запущен на сервере Debian, который будет SMTP-сервером для этой программы Windows. Он настроен с конфигурацией по умолчанию, плюс разрешены незашифрованные соединения AUTH PLAIN и AUTH LOGIN. Я успешно отправил электронное письмо через telnet:

telnet servername 25
ehlo test
250-AUTH PLAIN LOGIN
...
auth plain XXX
235 Authentication succeeded
mail from: ...
...

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

C: HELO hostname
S: 250 Hello hostname
C: AUTH LOGIN XXX | XXX
S: 503 AUTH command used when not advertised | 500 unrecognized command
C: QUIT
S: 221 closing connection

Я недостаточно знаком с протоколом SMTP, чтобы понимать, что здесь происходит. Что мне нужно изменить на моем SMTP-сервере exim4, чтобы разрешить это соединение?

В 503 AUTH command used when not advertised по сути объясняет себя, он не предлагал клиенту возможность использовать AUTH команда. Скорее всего, это связано с тем, что клиент использовал HELO скорее, чем EHLO (который, я хотел бы отметить, вы использовали при выполнении теста telnet).

Аутентификация SMTP является частью расширенного SMTP, который инициируется EHLO команда; "Старый добрый" SMTP не поддерживает аутентификацию, поэтому технически это недопустимая команда, хотя некоторые SMTP-серверы все еще могут ее разрешать.

Лучшее возможное решение - указать вашей программе использовать расширенный SMTP (EHLO), если возможно, иначе может быть команда exim, которая заставит его разрешить AUTH на HELO тип соединения.

** ОБНОВИТЬ **

Согласно этому сообщению здесь: http://www.exim.org/lurker/message/20040901.063858.126f66ac.en.html

EHLO (не HELO) должен быть предоставлен клиентом до AUTH.

То есть, команда AUTH не может использоваться, если не объявлено (через EHLO, согласно auth_advertise и т. Д.). Это поведение было усилено в Exim 4.20 и не является вариантом.

Похоже, вам нужен другой MTA, если ваше приложение не может EHLO. Или ты требовать аутентификации, можете ли вы сделать то же самое, используя ACL на основе IP?

ОКОНЧАТЕЛЬНОЕ РЕШЕНИЕ

У Exim есть обходной путь, используя allow_auth_unadvertised как описано Вот, вы можете сделать что-то вроде этого:

hosts   = *
control = allow_auth_unadvertised

У меня была похожая проблема. Это сообщение может появиться, даже если используется EHLO, когда на сервере работает Exim.

В WHM> Домашняя страница> Конфигурация службы> Менеджер конфигурации Exim, опция "Требовать от клиентов подключения с помощью SSL или ввести команду STARTTLS, прежде чем им будет разрешена аутентификация на сервере."был установлен по умолчанию (Вкл.). Я не уверен, сделал ли я это или нет, и обычно это отличная идея для безопасности, но заставляет почтовый сервер включать (рекламировать) только команду STARTTLS, а не AUTH. Итак когда мой скрипт отправляет AUTH, сервер отправляет правильное сообщение об ошибке. Дополнительная информация находится на http://blog.networkpresence.co/?p=8923 . Когда-нибудь, когда у меня будет время, я узнаю, как изменить свой сценарий для использования TLS, чтобы я мог включить эту опцию Exim в целях безопасности.

ДОБАВЛЕНО 19.11.19:

Я нашел, как изменить мой локальный сценарий «отправки электронной почты» для использования TLS, и я снова изменил свой сервер на использование TLS или STARTTLS.

Зачем я это сделал?

Потому что несколько веб-сайтов, которые я использую, требуют защищенных почтовых серверов при отправке уведомлений по электронной почте. У меня было дьявольское время, чтобы понять, почему они продолжали жаловаться на мой адрес электронной почты: это было потому, что мой почтовый сервер принимал небезопасные соединения!

Подумав об этом дальше, я понял, что все веб-операции должны быть безопасными (это основная идея проекта Let's Encrypt, который первым предоставил бесплатные сертификаты безопасности, которые обновляются автоматически).

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

Измените аргумент порта fsockopen с 25 на 465.
Измените схему аргументов хоста fsockopen с (пусто) на ssl: //. Итак, если хост был «mail.example.com», измените его на «ssl: //mail.example.com».

Также может потребоваться включить строку «LoadModule ssl_module modules / mod_ssl.so» в файле httpd.conf (для локальных серверов Apache) или внести какие-либо другие локальные изменения, чтобы заставить работать интернет-транспорт PHP. Я не уверен в этом. Как раз эти два изменения сразу подействовали на меня.