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

Тот же SMTP-сервер, Microsoft Exchange достигает получателя, но sendmail нет

Некоторое время я обсуждал название вопроса, но думаю, это объясняет вопрос. Не стесняйтесь редактировать его, если у кого-то есть заголовок получше.

Окружающая среда:

Microsoft Exchange 2010 и sendmail.

Проблема

Все пользователи отправляют электронную почту через наш сервер Microsoft Exchange 2010, который, в свою очередь, отправляет электронную почту через SMTP через нашего интернет-провайдера. smtp.our-isp.co.uk.

Все приложения отправляют свои автоматические электронные письма (счета-фактуры и т. Д.) Через sendmail на сервере Linux, который, в свою очередь, отправляет электронную почту через SMTP через нашего интернет-провайдера. smtp.our-isp.co.uk.

Конфигурация:

# "Smart" relay host (may be null)
DSsmtp.our-isp.co.uk

Однако, если пользователь отправляет электронное письмо (Microsoft Exchange 2010 -> ISP SMTP), оно достигает получателя нормально, но если приложение отправляет электронное письмо (sendmail -> ISP SMTP), оно вообще не достигает получателя ( т.е. он фильтруется даже до того, как попадает в собственный почтовый ящик кажется).

Это происходит с конкретными получателями, но я никогда не могу понять, почему, если электронные письма отправляются одним и тем же методом.

Есть ли у кого-то здесь предложения по поводу того, что может быть причиной?

Я согласен с mfinni, вам нужно отслеживать сообщения немного дальше, чтобы определить точку отказа.

Первое предположение заключается в том, что вы не получаете никаких отчетов о недоставке (NDR) из писем, которые никогда не доходят до места назначения, верно?

Проверьте журнал почты на вашем сервере Linux и посмотрите, не отображаются ли в нем ошибки связи. Это всегда первый шаг в попытке определить, является ли это конфигурацией вашего сервера, вызывающей проблему, или что-то возвращается с принимающего сервера. Кроме того, вы можете вручную протестировать smtp с вашего сервера Linux на сервер ретрансляции smtp, чтобы проверить правильность связи. Пример ручного сеанса smtp (<обозначает ответы от сервера)

telnet smtp.our-isp.co.uk 25

<220 Здесь будет отображаться приветствие сервера

ehlo servername

<250 может принимать несколько 250 строк в зависимости от доступных опций

почта от: senduser @ domain

<250 нормально

rcpt to: получатель @ домен

<250 нормально

данные

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

От: отправка пользователя @ домен
Кому: получатель @ домен
Тема: Какой бы предмет вы ни хотели

Тело письма идет сюда, введите сколько душе угодно.
.

Предполагая, что сервер принял сообщение, вы должны получить ответ 250 с некоторым типом подтверждения (например, «поставлен в очередь на доставку» и т. Д.).

Если все это удастся, то сообщение может зависать у провайдера или автоматически сбрасываться вашим провайдером (настроен ли IP-адрес вашего Linux-сервера для передачи через вашего провайдера?) Или отклонено сайтом получателя и т. Д., и т.п.

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

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

Если это так, то свяжитесь с ними, чтобы получить логи на их стороне, т. Е. Мы не сможем вам помочь.

Если это не так, исправьте все, что не так с вашим сервером Sendmail.

Я думаю, это может быть связано с каким-то механизмом защиты от спама.

Есть ли у вас в домене SPF или DKIM?

Чтобы проверить запись SPF в Linux:

$ dig +short example.com txt

Вам также следует взглянуть на свои журналы sendmail. Обычно это что-то вроде /var/log/maillog:

less /var/log/maillog

Наконец, в почтовом ящике sendmail вы можете попытаться подключиться по telnet к SMTP-серверу вашего провайдера и посмотреть, какой ответ вы получите. Пример:

$ telnet.exe smtp.example.com 25
Trying 192.168.1.1...
Connected to smtp.example.com (192.168.1.1).
Escape character is '^]'.
220 smtp.example.com ESMTP service ready
> EHLO me.example.com
250 smtp.example.com  Hello
> MAIL FROM: me@example.com
250 ok
> MAIL TO: you@other.example.com
250 ok
> DATA
354 Start mail input; end with .
> From: me@example.com
> To: you@other.example.com
> Subject: Test message now
> 
> Test message.
> .
250 2.6.0  queued mail for delivery

> quit

Электронная почта может быть очень сложной. Интернет-провайдер может сбросить сообщение без объяснения причин. Если все эти шаги по сужению проблемы не увенчаются успехом, вашим последним средством будет связаться с ними напрямую.