none
Exchange 2016 перестали приходить письма с icloud RRS feed

  • Вопрос

  • Добрый день. Перестали приходить(отправка работает) письма с почты icloud (пробовал разные адреса в Icloud). С остальных доменов всё ок. 

    Насколько помню, настройки не менял. В логах Default FronEnd-а:

    2017-02-15T13:51:25.662Z,EX1-MIL-01\Default Frontend EX1-MIL-01,,0,172.20.0.3:25,172.20.0.30:24587,+,,
    2017-02-15T13:51:25.662Z,EX1-MIL-01\Default Frontend EX1-MIL-01,,1,172.20.0.3:25,172.20.0.30:24587,>,"220 mail.xxx.ru Microsoft ESMTP MAIL Service ready at Wed, 15 Feb 2017 16:51:25 +0300",
    2017-02-15T13:51:25.975Z,EX1-MIL-01\Default Frontend EX1-MIL-01,,2,172.20.0.3:25,172.20.0.30:24587,<,HELO mail.xxx..ru,
    2017-02-15T13:51:25.975Z,EX1-MIL-01\Default Frontend EX1-MIL-01,,3,172.20.0.3:25,172.20.0.30:24587,>,250 mail.xxx.ru Hello [172.20.0.30],
    2017-02-15T13:51:26.272Z,EX1-MIL-01\Default Frontend EX1-MIL-01,,4,172.20.0.3:25,172.20.0.30:24587,<,AUTH LOGIN,
    2017-02-15T13:51:26.272Z,EX1-MIL-01\Default Frontend EX1-MIL-01,,5,172.20.0.3:25,172.20.0.30:24587,*,Tarpit for '0.00:00:05' due to '504 5.7.4 Unrecognized authentication type',
    2017-02-15T13:51:31.287Z,EX1-MIL-01\Default Frontend EX1-MIL-01,,6,172.20.0.3:25,172.20.0.30:24587,>,504 5.7.4 Unrecognized authentication type,
    2017-02-15T13:51:31.287Z,EX1-MIL-01\Default Frontend EX1-MIL-01,,7,172.20.0.3:25,172.20.0.30:24587,<,QUIT,
    2017-02-15T13:51:31.287Z,EX1-MIL-01\Default Frontend EX1-MIL-01,,8,172.20.0.3:25,172.20.0.30:24587,>,221 2.0.0 Service closing transmission channel,
    2017-02-15T13:51:31.287Z,EX1-MIL-01\Default Frontend EX1-MIL-01,,9,172.20.0.3:25,172.20.0.30:24587,-,,Local

    Что примечательно: icloud.com здоровается через HELO, остальные отправители через EHLO.

    Ещё пара моментов: сертификат частный, выпущенный DC; helo и ehlo у меня отличаются от mx записи. MX  у меня mail.xxx.ru, а HELO EHLO - mail.corp.xxx.ru

    Буду благодарен за помощь

    15 февраля 2017 г. 15:02

Ответы

  • Да, могу :) 

    Попробуйте выполнить:

    telnet externalip 25
    HELO Localhost
    


    Будет примерно такой результат: 

    250-ex.domain.net Hello [18.6.13.1]
    250-SIZE 52428800
    250-PIPELINING
    250-DSN
    250-ENHANCEDSTATUSCODES
    250-STARTTLS
    250-AUTH GSSAPI NTLM
    250-8BITMIME
    250-BINARYMIME
    250 CHUNKING

    Как видим, AUTH LOGIN отсутствует - и это очень хорошо. Plaintext разрешать нельзя - пароль будет очень просто перехватить. 

    Вывод - кто-то пытается залогиниться используя неподдерживаемый тип аутентификации. Вероятнее всего это некорректно настроенный клиент. Можете попробовать его отловить, но как это сделать - большой вопрос. Только если вычислить по IP :) Или временно разрешить plaintext и посмотреть логин, с которым логинятся. 

    Ну и собственно получить такую ошибку с помощью телнета для наглядности:

    telnet externalip 25
    HELO Localhost
    AUTH LOGIN

    17 февраля 2017 г. 14:09
  • SPF запись проверяет получатель сообщения чтобы убедиться, что письмо отправлено с валидного IP адреса. В вашем случае именно Exchange (или промежуточный сервер) может проверять SPF для домена ICLOUD, но никак не наоборот. Вот когда вы отправляете письмо НА icloud, тогда да, идет проверка записей для вашего домена со стороны icloud.
    20 февраля 2017 г. 9:55
  • А вот последнее замечание интересное. В общем проверяйте, доходит ли письмо вам на Receive Connector. Определить оно это или нет можно по HELO/EHLO. Вполне может быть, что icloud забанил получателя (например, создал правило, что если в получателях есть домен DOMAIN то Reject).

    Как вариант - добавить на ваш сервер дополнительный внешний домен, настроить МХ, привязать любому пользователю дополнительный адрес test@newdomain.ru и отправить на него письмо с ICLOUD. Хотя тоже не показатель - может блокироваться IP получателя. Как оно работает, могут сказать только админы icloud.

    17 февраля 2017 г. 13:42

Все ответы

  • Сделал запись FQDN аналогичную MX записи через настройки FrontEnd-а

    С Icloud всё равно не приходят письма

    15 февраля 2017 г. 15:16
  • Похоже, что это не лог письма от ICloud... Это, вероятно, просто чьи-то попытки отправить письмо с моего почтовика, верно? Получается, что icloud даже не стучится ко мне?
    16 февраля 2017 г. 7:59
  • 2 мини-совета.

    1) отключите временно антиспам проверки, возможно Вы где-то срезаете эти письма

    2) отправьте себе на внешнюю почту письмо с ICloud и пронанализируйте заголовки писем на предмет отправляющих серверов (адресов)

    16 февраля 2017 г. 8:02
  • Дмитрий, спасибо за Ваш ответ.

    Антиспам от exchange для меня действительно работает не совсем предсказуемо. Но!

    Проблема была и до того, как я включил эту службу. Вначале стоял Eset Mail security (пробный) - всё было ок. Потом перестали письма приходить от ICLOUD. Отключал проверку антиспама от ESET. Не помогало. Удалил его - всё равно письма не приходили. Недавно настроил антиспам от Exchange - в логах нет Reject-ов. Отключать пробовал. Добавил icloud в bypassed контент фильтра - не помогает. Антиспам я исключаю.

    По поводу Вашего второго совета:

    Что мне может дать анализ заголовков писем? На что обратить внимание?

    Так же заметил, что очень много критических ошибок в евент логе, связанных с TLS. В логах коннектора так же много ошибок типа:

    '504 5.7.4 Unrecognized authentication type'

    16 февраля 2017 г. 9:22
  • Похоже, что это не лог письма от ICloud... Это, вероятно, просто чьи-то попытки отправить письмо с моего почтовика, верно? Получается, что icloud даже не стучится ко мне?

    Get-MessageTrackingLog -Server EX1-MIL-01 -Start "02/16/2017 09:00:00" -End "02/16/2017 17:00:0
    0" -sender "icloud" отправителя и дату надо поменять и можно так посмотреть полученные от icloud письма.

    http://blog.bissquit.com/mail-servers/exchange-server/get-messagetrackinglog-exchange-2013/

    нашла вот такую ссылку. может какие то команды помогут вам докопаться до истины))

    например посмотреть через какие соединители проходит сообщение

    Get-MessageTrackingLog -MessageSubject «test_153504072016» | Format-Table Timestamp,ConnectorID,EventID,Source -AutoSize

    сравнить сообщение от  icloud  и от других доменов. 

    16 февраля 2017 г. 11:19
  • Покажите вывод:

    Get-ReceiveConnector  -Identity "CAS1301\Default Frontend EX1-MIL-01" | fl AuthMechanism, PermissionGroups, RequireEHLODomain, RequireTLS

    Вот немного информации по различиям EHLO\HELO. 

    http://en.redinskala.com/what-is-the-difference-between-the-heloehlo-commands/

    16 февраля 2017 г. 13:39
  • Светлана, здравствуйте. Трекинг логом уже искал. Не находит сообщения от ICloud вообще. Ни одной записи. Коннекторов получения у меня 5:

    Client Frontend

    Client Proxy

    Default

    Default Frontend

    Outbound Proxy

    Приходить по идее всё должно на Default Frontend. В логах писем от Icloud не вижу. С остальными ок

    17 февраля 2017 г. 12:29
  • Все верно, в трекинге этих сообщений не будет. Вы же сами прислали лог коннектора где мы четко видим, что он отбивает соединение. Покажите вывод команды, которую я прислал ранее. Возможно кто-то перемудрил с настройками.

    Еще попробуйте выполнить отправку почты себе через telnet:

    1.

    telnet EXTERNALIP 25 HELO localhost MAIL FROM:<myuser@mydom.ru> RCPT TO: <myuser@mydom.ru> DATA SUBJECT: Test HELO test . QUIT 2. telnet EXTERNALIP 25 EHLO localhost MAIL FROM:<myuser@mydom.ru> RCPT TO: <myuser@mydom.ru> DATA SUBJECT: Test EHLO test . QUIT


    17 февраля 2017 г. 12:40
  • Покажите вывод:

    Get-ReceiveConnector  -Identity "CAS1301\Default Frontend EX1-MIL-01" | fl AuthMechanism, PermissionGroups, RequireEHLODomain, RequireTLS


    Get-ReceiveConnector  -Identity "Default Frontend EX1-MIL-01" | fl AuthMechanism, PermissionGroups, RequireEHLODomain, RequireTLS


    AuthMechanism     : Tls, Integrated, BasicAuth, BasicAuthRequireTLS
    PermissionGroups  : AnonymousUsers, ExchangeServers, ExchangeLegacyServers
    RequireEHLODomain : False
    RequireTLS        : False

    Смущают последние две строки. Нужно в True их перевести?
    17 февраля 2017 г. 13:02
  • Вот все смотрю еще на это:

    2017-02-15T13:51:26.272Z,EX1-MIL-01\Default Frontend EX1-MIL-01,,4,172.20.0.3:25,172.20.0.30:24587,<,AUTH LOGIN,

    Это точно лог того письма, которое пытается придти с icloud? От этих клиентов письма на gmail доходят корректно?

    17 февраля 2017 г. 13:18
  • Артём, нет, не точно. У меня много таких ошибок. Смотрел в Event Viewer во вкладке System. Там тоже много ошибок связанных с TLS (судя по коду - не нравится центр сертификации. У меня сертификат выпущен Домен Контроллером). Я не знаю, как выяснить, что лог точно от этого письма. Судя по времени, похоже, что именно оно. Небольшая задержка с момента отправки.

    Как отмониторить момент "стука" icloud на сервер?

    172.20.0.3:25,172.20.0.30:24587 - это внутренний адрес Exchange Server 2016 и шлюз. Сервер спрятан за dst-nat и резолвится через маршрутизатор во внутренний адрес 172.20.0.3 (открытые порты: 25, 443, 587).

    В гугл туда и обратно ходит. В icloud я нормально отправляю - письма доходят.

    Есть ещё одна особенность: если отправлять с icloud  нескольким адресатам, то, если в получателях мой домен, то письмо не приходит никому



    17 февраля 2017 г. 13:33
  • А вот последнее замечание интересное. В общем проверяйте, доходит ли письмо вам на Receive Connector. Определить оно это или нет можно по HELO/EHLO. Вполне может быть, что icloud забанил получателя (например, создал правило, что если в получателях есть домен DOMAIN то Reject).

    Как вариант - добавить на ваш сервер дополнительный внешний домен, настроить МХ, привязать любому пользователю дополнительный адрес test@newdomain.ru и отправить на него письмо с ICLOUD. Хотя тоже не показатель - может блокироваться IP получателя. Как оно работает, могут сказать только админы icloud.

    17 февраля 2017 г. 13:42
  • На коннекторе получения нет писем от Icloud. Всеми вышеозвученными способами icloud в поиске не находится. Только, если я отправляю письмо туда.

    Я уже пробовал писать в apple через форму на сайте - ничего не ответили.

    По поводу ошибок в EVENT Viewer (TLS) и в логах ('504 5.7.4 Unrecognized authentication type') можете что-то прокомментировать?

    Телнетом письма ходят.

    17 февраля 2017 г. 13:49
  • Да, могу :) 

    Попробуйте выполнить:

    telnet externalip 25
    HELO Localhost
    


    Будет примерно такой результат: 

    250-ex.domain.net Hello [18.6.13.1]
    250-SIZE 52428800
    250-PIPELINING
    250-DSN
    250-ENHANCEDSTATUSCODES
    250-STARTTLS
    250-AUTH GSSAPI NTLM
    250-8BITMIME
    250-BINARYMIME
    250 CHUNKING

    Как видим, AUTH LOGIN отсутствует - и это очень хорошо. Plaintext разрешать нельзя - пароль будет очень просто перехватить. 

    Вывод - кто-то пытается залогиниться используя неподдерживаемый тип аутентификации. Вероятнее всего это некорректно настроенный клиент. Можете попробовать его отловить, но как это сделать - большой вопрос. Только если вычислить по IP :) Или временно разрешить plaintext и посмотреть логин, с которым логинятся. 

    Ну и собственно получить такую ошибку с помощью телнета для наглядности:

    telnet externalip 25
    HELO Localhost
    AUTH LOGIN

    17 февраля 2017 г. 14:09
  • Артём, спасибо за помощь. Может ли быть моя SPF запись причиной того, что почта не доставляется от ICLOUD. Я не совсем понимаю, кто её проверяет. Сначала думал, что сервер получения смотрит, откуда пришло письмо и совпадают ли эти данные с данными, занесенным в SPF запись
    20 февраля 2017 г. 9:49
  • SPF запись проверяет получатель сообщения чтобы убедиться, что письмо отправлено с валидного IP адреса. В вашем случае именно Exchange (или промежуточный сервер) может проверять SPF для домена ICLOUD, но никак не наоборот. Вот когда вы отправляете письмо НА icloud, тогда да, идет проверка записей для вашего домена со стороны icloud.
    20 февраля 2017 г. 9:55
  • Действительно, оказалось, что это проблема была на стороне icloud. Дальнейшее тестирование показало, что даже, если в теле письма оказывался мой домен, то письмо не доходило НИКУДА (даже на mail, gmail и прочее). Что это за вид блокировки, на каком основании её поставили, выяснить у техподдержки ICloud не удалось, зато они блокировку сняли, и письма ходят в нормальном режиме.

    Спасибо за помощь


    19 апреля 2017 г. 8:27