Релейный доступ запрещен при использовании SMTP для внешних получателей СНАБЖАЕТ ПОСТФИКСОМ FreeBSD

mynetworks = 127.0.0.0/8 [::1]/128

Отменить. #Количество овец в строке #mynetworks = 127.0.0.0/8 [::1]/128

У меня было похожее сообщение об ошибке, когда я настраивал sendmailкак в этой теме . Для меня проблема заключалась в том, что я выполнял аутентификацию через порт 465, который является SMTP с TLS, но протокол требует запуска TLS после аутентификации, например, через порт 25, который является SMTP без TLS.

Решение состояло в том, чтобы изменить порт в ~/.authinfoна

machine server.domain.tld login username@domain.com port 25 password XYZ

Обновление:Я не эксперт по SMTP. Мой ответ основан на моем опыте и на этой ветке , где в комментарии упоминалось это опровержение моего использования порта 25 для аутентификации:

That's not the way SMTP AUTH works: you authenticate and send using the same port, in this case 587.

У меня тоже была такая проблема... Прежде всего, обратите внимание, что есть два номера ошибки:

1. ошибка на стороне сервера (554)

554 4.7.1 user@example.com: Relay access denied

вы должны проверить настройки своего постфикса (или любого почтового сервера ). проверьте свой /etc/postfix/main.cfили/etc/postfix/master.cf

2. ошибка на стороне клиента (454)(Это была моя проблема, которую я решил.)

454 4.7.1 user@example.com: Relay access denied

Основная проблема заключалась в том, что я не входил в систему с помощью AUTH LOGIN.

важно:Если используется SSL на стороне сервера (, если SSL включен в конфигурации ), ВЫ НАИБОЛЕЕ ВВОДИТЕ ИМЯ ПОЛЬЗОВАТЕЛЯ И ПАРОЛЬ КАК BASE64 ... Итак,вы можете использовать любой инструмент для преобразования вашего пользователя и перехода к базе 64... Я использовал perlв командной строке..

преобразовать имя пользователя в пример base64 с использованиемperl:

perl -MMIME::Base64 -e 'print encode_base64("your_username");' // Without @example.com

вне :eW91cl91c2VybmFtZQ++

и пароль base64:

perl -MMIME::Base64 -e 'print encode_base64("your_password");'

выход :eW91cl9wYXNzd29yZA==

и, наконец, используйте преобразованные имя пользователя и пароль base64 для входа в систему... См. мой успешный вывод:

myUser@hostname:~$ telnet mail.example.com 25
Trying 2.177.253.173...
Connected to mail.example.com.
Escape character is '^]'.
220 mail.example.com ESMTP Postfix
AUTH LOGIN
334 DXFlvmthuWP0
eW91cl91c2VybmFtZQ++  -----------------> Enter username as Base64
334 UGFzc32voiG7
eW91cl9wYXNzd29yZA==  -----------------> Enter password as Base64
235 2.7.0 Authentication successful
mail from:your_username@example.com
250 2.1.0 Ok
rcpt to:example@gmail.com
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
this mail sent by telnet               
.
250 2.0.0 Ok: queued as FFAD62D5D3
quit
221 2.0.0 Bye
Connection closed by foreign host.

мое преобразованное имя пользователя в Base64 было eW91cl91c2VybmFtZQ++, а мой пароль для Base64 былeW91cl9wYXNzd29yZA==

Исторически SMTP-подключения к порту 25/TCP использовались почтовыми клиентами (MUA )для отправки исходящей почты на их локальный почтовый сервер или почтовыми серверами (MTA )для передачи электронной почты от одного почтового сервера на другой. Аутентификация не была включена в стандартную комплектацию. Это оказалось очень плохой идеей.

Чтобы устранить проблемы, вызванные этим, современные почтовые серверы обычно настраивают на прием входящей электронной почты от клиентов, использующих порт 587. При использовании этого порта аутентификация обычно является обязательной, а шифрование TLS (с использованием STARTTLS )настоятельно рекомендуется.

Порт 25 все чаще используется для трафика только между «действительными» почтовыми серверами, а действительность конкретного почтового сервера в основном определяется различными записями DNS.

«Отказано в доступе к ретрансляции» означает, что в настоящее время вы не авторизованы для отправки электронной почты через внешний сервер на любой другой почтовый сервер, т. е. для ретрансляции почты, например

YOURSERVER -> EXTERNALSERVER -> THIRD-PARTY-SERVER

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

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

• При подключении подключающийся хост должен указать имя хоста, за которое он себя выдает.Принимающий хост выполнит обратный поиск DNS для исходного IP-адреса :Соответствует ли имя, сообщаемое DNS, имени, заявленному подключающимся хостом? Также выполняется обычный прямой поиск DNS :Соответствует ли IP-адрес, сообщаемый DNS для этого имени, исходному IP-адресу, с которого на самом деле идет соединение? Это один из старейших тестов на спам -. Если вы не пройдете этот тест и не пройдете аутентификацию, вам будет разрешено отправлять электронную почту только на адреса электронной почты, за которые непосредственно отвечает целевой хост, а не третьим лицам.

• Существуют также записи DNS SPF, которые могут (опционально )указывать, какие узлы в конкретном домене DNS должны отправлять электронную почту в Интернет. Если у вашего домена есть запись SPF (, попробуйте dig domain.name TXT, чтобы увидеть)и , эта запись указывает, что ваш хост не должен быть почтовым сервером, и вы не проходите аутентификацию, внешний сервер может полностью отклонить вашу попытку подключения.

• Записи DNS MX являются еще одной важной частью доставки электронной почты. :они указывают фактическое имя хоста почтового сервера (с ), обслуживающего определенный домен. Чтобы определить, куда должна быть доставлена ​​электронная почта, адресованная Joe.User@domain.example, почтовые серверы сначала ищут запись MX для domain.example. Вы можете сделать это самостоятельно с помощью команды типа dig domain.example MX. Если для определенного DNS-домена нет записей MX, существует правило отката -назад :, если существует простая старая DNS-запись A для domain.exampleи хост с IP-адресом, идентифицированным этой записью A, слушает на порту 25/TCP, тогда любые электронные письма, адресованные этому домену, будут отправляться на этот IP-адрес. Для проверки на спам -может быть проверена запись MX отправляющего хоста :. отправь его тоже». Из-за большого разнообразия наборов почтовых серверов -это не может быть жестким и быстрым правилом,но иногда это используется как небольшой положительный / отрицательный фактор в вопросе «спам или нет?» решения.

Если вы являетесь домашним пользователем или даже представителем малого бизнеса и не имеете статического общедоступного IP-адреса, интернет-провайдер может рассматривать вас как простой почтовый клиент и разрешать вам отправлять исходящие SMTP-соединения только на электронную почту провайдера. только сервера. В этот момент им может потребоваться аутентификация, или они могут разрешить подключение без аутентификации в зависимости от физической структуры их сети. В этой ситуации вы все равно можете иметь свой собственный почтовый сервер; ему просто нужно отправлять всю исходящую электронную почту через почтовые серверы провайдера, как это делает обычный почтовый клиент. Это иногда называют конфигурацией «smarthost» в соответствии с названием параметра конфигурации для него в классическом Sendmail. В наше время обычно требуется использование порта 587 и аутентификация вместо классического порта 25 без аутентификации.

Получение входящей электронной почты на вашем собственном сервере также зависит от того, что разрешено вашим интернет-провайдером. Если ваше соединение использует NAT (, так как домашние и малые -интернет-соединения все чаще используют ), получение входящих соединений без открытия фиксированного туннеля для порта 25 через NAT будет невозможным. Если ваш IP-адрес время от времени меняется, постоянное обновление соответствующих DNS-записей электронной почты -будет иметь решающее значение для надежности доставки вашей электронной почты.

Когда у вас есть общедоступный статический IP-адрес и собственный DNS-домен, вы, как правило, считается «достаточно большим», чтобы иметь «настоящий» почтовый сервер в глазах Интернета в целом. При настройке почтового сервера вы должны уделять очень пристальное внимание различным типам записей DNS, имеющих отношение к доставке электронной почты, и убедиться, что ваш сервер представляет себя (сообщением HELO/EHLO в соединениях SNMP ), используя точные имя, зарегистрированное для него в DNS.Также убедитесь, что обратная запись DNS (PTR для IP-адреса -> сопоставление имени домена )верна.