451 Could not complete sender verify callout или война RBL и Callback verification.

Сегодня возникла проблема. Пользователь отправляет письмо и получает в ответ «451 Could not complete sender verify callout». Оказывается, есть такой метод проверки Callback verification. Суть очень проста, проверить существование отправителя на сервере отправителя. Защищает этот способ от поддельных адресов. Недостатков – множество. Скажем если спаммер подставит любой существующий адрес , например e-mail из любого глянцевого журнала, то эта проверка подвоха не заметит. Мало того, что это очень ресурсоемкая ситуация и ее не используют.

Я же подумал, почему тот сервер не может проверить e-mail нашего пользователя. А вот почему – проверка RBL на нашем сервере. Сеть, где находится сервер получателя попала в RBL целиком и теперь они находятся в незавидном положении.

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

Ситуация дурацкая, т.к. из-за технических штучек пострадали пользователи. Эдакие шпионские войны в Инете J Но как всегда есть белые списки, которые спасут мир.

p.s.: Кстати, в последнее время спам стал очень редким явлением. RBL, SenderID и Kaspersky antispam хорошая связка. Раньше было по 30 - 40 сообщений приходило в мой Inbox ежедневно, теперь одно – два в день, а бывает и совсем нет.

Настройка SMTP лога.

Напишу сейчас про один .

Одним из обязательных навыков любого администратора является умение анализировать логи серверов. В Exchange 2003 это Application log в EventViewer, Tracking log в ESM и SMTP log. Я затрону только проблему SMTP лога. Это текстовый лог файл отражающий работу SMTP сервера, т.е. уровень SMTP протокола. Мне не нравится то, что в логе много лишней информации, поэтому я рекомендую настроить только лог следующих полей:

Date Дата транзакции
Time Время транзакции.
Client IP address c-ip IP-адрес клиента.
User Name cs-username Имя пользователя, используемое клиентом
для подключения к серверу; анонимные
пользователи обозначаются дефисом ("-").
Method cs-method Метод, используемый клиентом для доступа к
серверу (например, HTTP GET).
URI Query cs-uri-query Запрос URI, отправленный клиентом серверу
(если таковой имеется).
Protocol Status sc-status Сообщение о состоянии протокола (например,
"404: HTTP не найден").

На мой взгляд все остальные поля – лишние для анализа SMTP

Дополнительная информация о настройке логов и описание полей.
XCON: How to Configure a SMTP Virtual Server Part 1
Logging the SMTP Service

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

SMTP,SSL и «любимая» компания россиян МТС.

Microsoft предлагает для чтения почты OWA, Outlook RPC over HTTPS и ActiveSync. Вполне достаточно. Но для тех, кто не готов переломить себя и любит летучих мышей, админы настраивают POP3/IMAP4+отправку по SMTP. Хорошим тоном является, когда данные идут шифрованные. Мало ли.
Сегодня звонит пользователь – подрядчик и жалуется, что не может отправить почту. Принять может, а отправить нет. Подсоединяется мышью(The Bat) с лаптопа используя GPRS(MTS), отправляет по SMTP+SSL. При отправке возникает проблема. Говорит, что если использовать другого провайдера GPRS, например Beeline, то все работает. В чем проблема? Я ему и отвечаю, что если работает с другого провайдера, то проблема в провайдере. Проверил, действительно так. Проблема известная – файервол с их стороны блокирует SMTP команды.
Что такое писать письма большим компаниям знает каждый. Отправил и тишина.....

Но я все же подготовил вот такое письмо в МТС, хоть и не верил, что они что-то изменят.
Уважаемые господа,
В нашей компании обнаружена проблема отправки почты по протоколу SMTP+SSL при использовании подключения к Интернет через GPRS MTS. Ниже приводится кусок лога TheBat котором видно, что ответы SMTP сервера заменяются на XXX.
2007.04.04 21:09:28 : Negotiations for smtp (client side) started
2007.04.04 21:09:28 : 220 ****************************************.
2007.04.04 21:09:28 : 220 ****************************************.
2007.04.04 21:09:28 : EHLO localhost
2007.04.04 21:09:29 : 250-myserver.mydomain.ru Hello [217.74.245.67].
2007.04.04 21:09:29 : 250-XXXA.
2007.04.04 21:09:29 : 250-SIZE.
2007.04.04 21:09:29 : 250-ETRN.
2007.04.04 21:09:29 : 250-PIPELINING.
2007.04.04 21:09:29 : 250-DSN.
2007.04.04 21:09:29 : 250-ENHANCEDSTATUSCODES.
2007.04.04 21:09:29 : 250-8bitmime.
2007.04.04 21:09:29 : 250-BINARYMIME.
2007.04.04 21:09:29 : 250-XXXXXXXB.
2007.04.04 21:09:29 : 250-VRFY.
2007.04.04 21:09:29 : 250-XXC.
2007.04.04 21:09:29 : 250-XXXXXXXD.
2007.04.04 21:09:29 : 250-XXXXXXXXXXXXXXXXXXXXXXXE.
2007.04.04 21:09:29 : 250-XXXXXXXXXXXF.
2007.04.04 21:09:29 : 250-AUTH GSSAPI NTLM LOGIN.
2007.04.04 21:09:29 : 250-AUTH=LOGIN.
2007.04.04 21:09:29 : 250-XXXXXXXXXXXG.
2007.04.04 21:09:29 : 250-XXXXXXH.
2007.04.04 21:09:29 : 250 XI.2007.04.04 21:09:29 : STARTTLS
2007.04.04 21:09:30 : 530 5.7.0 Must issue a STARTTLS command first.2007.04.04 21:09:30 : Remote server is not RFC 2487 compliant
2007.04.04 21:09:30 : Protocol negotiation failed
2007.04.04 21:09:30 : Protocol negotiations failed
2007.04.04 21:09:30 : smtps finished (0 left)
Соединение через других провайдеров Интернет выглядит так:
2007.04.04 21:29:30 : Negotiations for smtp (client side) started
2007.04.04 21:29:31 : 220 myserver.mydomain.ru Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at Wed, 4 Apr 2007 21:30:03 +0400 .
2007.04.04 21:29:31 : 220 myserver.mydomain.ru Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at Wed, 4 Apr 2007 21:30:03 +0400 .2007.04.04 21:29:31 : EHLO localhost
2007.04.04 21:29:31 : 250-myserver.mydomain.ru Hello [85.195.160.40].
2007.04.04 21:29:31 : 250-TURN.
2007.04.04 21:29:31 : 250-SIZE.
2007.04.04 21:29:31 : 250-ETRN.
2007.04.04 21:29:31 : 250-PIPELINING.
2007.04.04 21:29:31 : 250-DSN.
2007.04.04 21:29:31 : 250-ENHANCEDSTATUSCODES.
2007.04.04 21:29:31 : 250-8bitmime.
2007.04.04 21:29:31 : 250-BINARYMIME.
2007.04.04 21:29:31 : 250-CHUNKING.
2007.04.04 21:29:31 : 250-VRFY.
2007.04.04 21:29:31 : 250-TLS.
2007.04.04 21:29:31 : 250-STARTTLS.
2007.04.04 21:29:31 : 250-X-EXPS GSSAPI NTLM LOGIN.
2007.04.04 21:29:31 : 250-X-EXPS=LOGIN.
2007.04.04 21:29:31 : 250-AUTH GSSAPI NTLM LOGIN.
2007.04.04 21:29:31 : 250-AUTH=LOGIN.
2007.04.04 21:29:31 : 250-X-LINK2STATE.
2007.04.04 21:29:31 : 250-XEXCH50.
2007.04.04 21:29:31 : 250 OK.2007.04.04 21:29:31 : STARTTLS
2007.04.04 21:29:32 : 220 2.0.0 SMTP server ready.
2007.04.04 21:29:32 : Protocol negotiation succeded
Продиагностировать проблему можно очень просто.Нужно набрать в командной строке: telnet server.mydomain.ru 25

И в приглашении набрать ehlo, затем starttls. Если соединение прошло успешно, то Вы увидите 220 2.0.0 SMTP server readyЭто будет выглядеть так:
220 myserver.mydomain.ru Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at Fri, 13 Apr 2007 08:24:30 +0400ehlo250-myserver.mydomain.ru Hello [80.74.81.70]
250-TURN
250-SIZE
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-TLS
250-STARTTLS
250-X-EXPS GSSAPI NTLM LOGIN
250-X-EXPS=LOGIN
250-AUTH GSSAPI NTLM LOGIN
250-AUTH=LOGIN
250-X-LINK2STATE
250-XEXCH50
250 OKstarttls220 2.0.0 SMTP server ready
Через Интернет это работает номально, если использовать GPRS MTS, то нет.
Через GPRS MTS это выглядит так:
220 **********************************************ehlo530 5.7.0 Must issue a STARTTLS command firststarttls530 5.7.0 Must issue a STARTTLS command first
Такая проблема возникает, когда в качестве firewall установлен Cisco PIX Firewall и на нем включена функция fixup. Об этом написано в статье http://support.microsoft.com/kb/295725/en-us.
Для нормального функционирования e-mail с мобильных устройств нашей компании, необходимо разрешить эту проблему.
Вы знаете и они ответили, через время, но МТС прислал такое письмо:По информации, полученной от наших тех. специалистов : "Сейчас и в ближайшее время произведена/и ещё произведётся перенастройка оборудования МТС, которая позволит использовать GPRS -Internet для доступа к их серверу".

Сообщите, произошли ли у Вас какие-либо изменения.

С уважением,
специалист ОРКК
Краснодар, МР "ЮГ", блок ПАО
ОАО "МТС"
___________________________
Сейчас все нормально работает. Вот такая вот история.

Exchange и 451+4.7.1+Greylisting+in+action,+please+come+back+in+00:05:00

В форуме TechNet есть тема о том, что отправляемые сообщения пропадают или приходят с задержкой... 2 недели. Причина – некорректная обработка SMTP сервером ошибок 4XX, которые говорят о временной недоступности сервиса. (возможно, что только на серверах, где стоит Symantec Mail Security 5)

Как правило ошибки 4XX возникают редко, но в последнее время этот код используется антиспамовыми системами с технологей Graylisting. Например на серверах ozon.ru, gacworld.com, edunet.ru.

В SMTP логах это выглядит так:

451+4.7.1+Greylisting+in+action,+please+come+back+in+00:05:00

Проверил свои SMTP логи и обнаружил, что эта ошибка возникает довольно часто, но по «непонятным» J причинам проблем с доставкой на моих серверах не возникает. Природа отправки писем на подобные серверы такова.

Если Exchange при отправке по SMTP получает статус ошибки 4XX, то следующая попытка отправки будет предпринята не через 10 минут, как определено в First retry interval, а три раза через каждые 60 секунд. Эти 60 сек называются Glitch retry. Если в эти попытки отправка не произойдет, то след. попытка будет предпринята через First retry interval.

Это хорошо видно по логам SMTP сервера(я их немного порезал J).

Попытка 1. (Glitch retry)
07:37:21 MAIL - FROM:<Pavel.Nagaev@mydomain.ru>+SIZE=10761 0
07:37:21 - - 250+Ok 0 0 6 0 141 - - - -
07:37:21 RCPT - TO:<admin@edunet.ru> 0 0 4 0 2453 - - - -
07:37:21 450+<admin@edunet.ru>:+Recipient+address+rejected:+Greylisted+for+300+seconds
07:37:21 RSET - - 0 0 4 0 2500 - - - -

Попытка 2. (Glitch retry)
07:38:22 MAIL - FROM:<Pavel.Nagaev@mydomain.ru>+SIZE=10761 0
07:38:22 - - 250+Ok 0 0 6 0 141 - - - -
07:38:22 RCPT - TO:<admin@edunet.ru> 0 0 4 0 141 - - - -
07:38:22 - - 450+<admin@edunet.ru>:+Recipient+address+rejected:+Greylisted+for+239+seconds
07:38:22 RSET - - 0 0 4 0 188 - - - -

Попытка 3. (Glitch retry)
07:39:23 MAIL - FROM:<Pavel.Nagaev@mydomain.ru>+SIZE=10761 0
07:39:23 - - 250+Ok 0 0 6 0 141 - - - -
07:39:23 RCPT - TO:<admin@edunet.ru> 0 0 4 0 141 - - - -
07:39:23 - - 450+<admin@edunet.ru>:+Recipient+address+rejected:+Greylisted+for+178+seconds
07:39:23 RSET - - 0 0 4 0 250 - - - -

Попытка 4. (First retry interval) Обратите внимание на время. Прошло ровно 10 минут после последней отправки.
07:49:24 MAIL - FROM:<Pavel.Nagaev@mydomain.ru>+SIZE=10761 0
07:49:24 - - 250+Ok 0 0 6 0 156 - - - -
07:49:24 RCPT - TO:<admin@edunet.ru> 0 0 4 0 156 - - - -
07:49:24 - - 250+Ok 0 0 6 0 203 - - - -
07:49:24 DATA - - 0 0 4 0 203 - - - -
07:49:24 - - 354+End+data+with+<CR><LF>.<CR><LF> 0 0 35 0 250 - - - -
07:49:24 - - 250+Ok:+queued+as+2992F5829E 0 0 28 0 406 - - - -
07:49:24 QUIT - - 0 0 4 0 515 - - - -
07:49:24 - - 221+Bye 0 0 7 0 547 - - - -

Exchange нормально отрабатывает. В чем же могут быть проблемы? Проблема может быть, если Greylisting настроен на reject больше 3 минут и время жизни записи 10 минут. Тогда с настройками по умолчанию на SMTP сервере письмо не сможет быть доставлено. Glitch retry в 60 сек. можно настраивать вручную согласно статьи: How to Configure Glitch Retry Interval in Exchange Server 2003
Дополнительно можно почитать отличную статью о том, как SMTP сервер доставляет сообщения : Explaining the Mysterious SMTP Advanced Queuing Engine

Пост из NEWS конференции

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

Про Аленушку, которая ждет письмо и MAIL FROM:<> SIZE=

Пятница, время для написания постов в блог :-)

Сегодня получил от наших безопасников ссылку http://security.nnov.ru/Hnews133.html
Возможно придется запретить получение doc файлов извне, пока не выйдет заплатка.

Вчера был день магнитных бурь наверное. Пользователи завалили запросами о том, что у них не ходит почта. Во всех случаях виноваты угадайте кто?

Так вот. В паре случаев меня поставили в тупик вот каким вопросом: "Нам позвонили и сказали, что отправили письмо. Получили подтверждение от нашего сервера, что оно доставлено. А я как Аленушка сижу и жду письма."

Я смотрю в логи ORF и попыток отправки там не вижу. Обычное дело, пользователи врут. Но что за ответ они получили? Потом выяснилось, что это был отбой о превышении лимита принимаемых сообщений. Я это определить не смог по ORF. Стал смотреть логи SMTP. Итак, что происходит.

Если файл отправляется по ESMTP, то формат команды from может быть такой:

MAIL FROM:<> SIZE=размер письма

И если "размер письма" больше разрешенного лимита, то SMTP сервер выдаст ошибку

552 5.3.4 Message size exceeds fixed maximum message size

В логах сервера получателя будут лишь такие строчки:

2007-02-02 09:38:24 10.4.1.60 myserver EHLO +myserver
2007-02-02 09:38:37 10.4.1.60 myserver MAIL +from:user@domain.com 552
2007-02-02 09:38:45 10.4.1.60 myserver QUIT myserver 240

При этом письмо о недоставке будет генерить сервер отправителя. Вы же никак об этом не узнаете. А если у отправителя ума не хватит прочитать об ошибке, то так и будут считать, что письмо отправлена, а Аленушка, так и будет сидеть у корытца :-)

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

Удачных всем выходных.


SMTP Service Extension for Message Size Declaration