Ошибка Почты

[Defensor2011]

Привет уважаемые форумчане! :KillMe:

В последнее время такая вот ошибка завелась в нашей среде предприятия, при отправке почты именно на этот GLOBALAIR-KZ.COM почтовый домен , на все остальные проходит нормально.
Если меняю шлюз с 254 на 253 то почта на домен GLOBALAIR-KZ.COM уходит нормально без ошибок, оставил бы так но проблема возникает у нас, что другие пользователи не могут нам отправить почту, к ним приходит возврат с похожим логом. Скажите в чем может быть проблема? :angry:

25.01.2013 17:10:43 Router: Transferring mail to domain GLOBALAIR-KZ.COM (host mail.GLOBALAIR-KZ.COM [212.154.133.34]) via SMTP
25.01.2013 17:10:43 Router: No messages transferred to GLOBALAIR-KZ.COM (host mail.GLOBALAIR-KZ.COM) via SMTP
25.01.2013 17:10:43 Router: Error transferring message 003D62DC via SMTP to mail.GLOBALAIR-KZ.COM;mail2.GLOBALAIR-KZ.COM SMTP Protocol Returned a Permanent Error

Спасибо!

 

[puks]

Надо увеличить smtp log level, чтобы видеть больше информации. Не помню навскидку параметы. Погугли - сразу найдешь. Причины могут быть разные: от настройки до битой карты.

 

[ToxaRat]

в конфиге сервера на закладке роутера включи для SMTP все наборы команд

 

[vitalid74]

25.01.2013 17:10:43 Router: Error transferring message 003D62DC via SMTP to mail.GLOBALAIR-KZ.COM;mail2.GLOBALAIR-KZ.COM SMTP Protocol Returned a Permanent Error

Я в таких случаях проверяю вручную
заходишь на RDP сервера и запускаешь
nslookup -q=mx <почтовый домен>

C:\>nslookup -q=mx GLOBALAIR-KZ.COM

Non-authoritative answer:
GLOBALAIR-KZ.COM MX preference = 10, mail exchanger = mail.GLOBALAIR-KZ.COM
GLOBALAIR-KZ.COM MX preference = 20, mail exchanger = mail2.GLOBALAIR-KZ.COM

mail.GLOBALAIR-KZ.COM internet address = 212.154.133.34
mail2.GLOBALAIR-KZ.COM internet address = 95.56.233.242

telnet <mx сервер> 25

C:\>telnet mail2.GLOBALAIR-KZ.COM 25
Connecting To mail2.GLOBALAIR-KZ.COM...Could not open connection to the host, on port 25: Connect failed

C:\>telnet mail.GLOBALAIR-KZ.COM 25
220-***************************************************************************
220 *******************************
help
500 What? I don't understand that.

Со мной тоже общаться не хочет, у них хоть работает почта то?

Долбишь админов получателя на предмет работы сервера

C:\>nslookup -type=soa mail.GLOBALAIR-KZ.COM
GLOBALAIR-KZ.COM
primary name server = vns25.hoster.kz
responsible mail addr = support.hoster.kz
serial = 2010092315
refresh = 10800 (3 hours)
retry = 3600 (1 hour)
expire = 604800 (7 days)
default TTL = 86400 (1 day)

не удивлюсь что непроплатили поддержку почты на hoster.kz

как-то так

 

[lmike]

нинада долбить одминов не разобравшись в своём ДНС:
-присутствие корректных A и PTR для мэйлера
-присутствие мэйлера в MX

 

[vitalid74]

нинада долбить одминов не разобравшись в своём ДНС:
-присутствие корректных A и PTR для мэйлера
-присутствие мэйлера в MX

если под мэйлером скрывается MTA(Mail Transfer Agent) отправителя,
то почему этот сервер должен быть MX сервером домена отправителя???

Если говорим о SPF (sender policy framework), то необходимо указать MTA в SPF (или TXT) записи в DNS

При чём здесь DNS отправителя, если получатель не указал куда ему отправлять письма???

проблема в DNS на стороне получателя/хостера получателя

 

[lmike]

если под мэйлером скрывается MTA(Mail Transfer Agent) отправителя,
то почему этот сервер должен быть MX сервером домена отправителя???

Если говорим о SPF (sender policy framework), то необходимо указать MTA в SPF (или TXT) записи в DNS

При чём здесь DNS отправителя, если получатель не указал куда ему отправлять письма???

проблема в DNS на стороне получателя/хостера получателя

потому что принимающая строна проверяет ДНС отправителя (и правильно делает) и нек. проверяют МХ (что тоже правильно)
ибо отправлять должен только "официальный" мэйлер, а не кто попало

 

[vitalid74]

нек. проверяют МХ (что тоже правильно)
ибо отправлять должен только "официальный" мэйлер, а не кто попало

и что они проверять то будут???

сервер smtp.a.org только отправляет почту в инет от домена c.org
сервер smtp.b.org только принимает почту из инета для домена с.org (указан как mx запись в домене c.org)

принимающий сервер проверяет SPF запись домена c.org (в ней должен быть указан сервер smtp.a.org как валидный отправитель почты из домена c.org)

А что даст проверка mx записи домена с.org я не понимаю, объясните уж??

Указывать smtp.a.org как MX сервер, imho, бред ещё тот
вот PTR запись smtp.a.org - необходима для прохождения проверки rDNS (но это уже DNS другого домена по идее)

 

[lmike]

Указывать smtp.a.org как MX сервер, imho, бред ещё тот
вот PTR запись smtp.a.org - необходима для прохождения проверки rDNS (но это уже DNS другого домена по идее)

-домина как принимает так и отправляет почту - и почему же она не д.б. в МХ?
-какого другого домена, по какой идее?

я не пойму - что вы пытаетесь доказать:
-что не нужно настраивать домен отправителя!?
-что PTR запись не проверяется?! (проверяется часто)
-что сервер для отправки не должен быть сервером для приема (т.е. записан в МХ)!? и да - не во всех доменах прописан SPF и контролируя его можно заблочить получение почты

ЗЫЖ пустой разговор получается или или уже обсуждаются проблемы специфичные Казахстанским провайдерам?

 

[Мыш]

Сервер-отправитель заносить в МХ, ИМХО, не обязательно. У меня работает на отправку - ни MX не является, ни в SPF не указан. И ничего, работает. Отсутствие SPF, ИМХО, не настолько уж суровая вещь. Бывает, грейлистят, но чтоб вообще блокировали отправку - такого давно не видел...
ЗЫ. Хотя параноиков хватает, все, наверное, может быть

 

[lmike]

Сервер-отправитель заносить в МХ, ИМХО, не обязательно. У меня работает на отправку - ни MX не является, ни в SPF не указан. И ничего, работает. Отсутствие SPF, ИМХО, не настолько уж суровая вещь. Бывает, грейлистят, но чтоб вообще блокировали отправку - такого давно не видел...
ЗЫ. Хотя параноиков хватает, все, наверное, может быть

о том и речь что бывают такие ограничения
ещё, более частое - при source NAT когда соединение выходит со внешним адресов, а хост присут. в HELO, не соответ. записям во внешнем ДНС

 

[ToxaRat]

Сервер-отправитель заносить в МХ, ИМХО, не обязательно. У меня работает на отправку - ни MX не является, ни в SPF не указан. И ничего, работает. Отсутствие SPF, ИМХО, не настолько уж суровая вещь. Бывает, грейлистят, но чтоб вообще блокировали отправку - такого давно не видел...
ЗЫ. Хотя параноиков хватает, все, наверное, может быть

должен с тобой кардинально не согласиться
да без SPF принимает и гугля и многие другие популярные почтовики, европа тоже принимает, но вот Украина и Россия как сговорились, каждый 2й почтовик требует, иначе получаем сообщение про хост не найден чего-то там - и это прекрасно, ибо подделываться отправителя научилось большинство

 

[Мыш]

и это прекрасно

Ссылка скрыта от гостей

 

[vitalid74]

-домина как принимает так и отправляет почту - и почему же она не д.б. в МХ?

немного поправлю, Domino МОЖЕТ как принимать SMTP, почту так и отправлять
ЕСЛИ сервер должен принимает почту из инета, то его адрес должен быть указан в MX записи домена чью почту он должен принимать

-какого другого домена, по какой идее?

Да по простой идее
у меня порядка 30 почтовых smtp доменов (@a.org, b.org, c.org итп/итд) (это всё в одном лотусовом домене)
две железки (отказоустойчивость и балансировка нагрузки) - спамфильтра для приёма почты (это не сервера Domino), они указаны в MX записях всех 30 доменов (srv1.a.org и srv2.b.org)
отправкой занимаются два Доминошных сервера (они указаны в SPF опять же всех 30 доменов) (srv3.a.org и srv4.b.org)

я не пойму - что вы пытаетесь доказать:
-что не нужно настраивать домен отправителя!?

нужно конечно,
PTR записи SMTP серверов + SPF записи в доменах от которых отправляется почта
а вот вносить сервера которые НЕ ПРИНИМАЮТ smtp почту в MX записи - бред

-что PTR запись не проверяется?! (проверяется часто)

да, это стандартная проверка rDNS (Reverse DNS lookup)

-что сервер для отправки не должен быть сервером для приема (т.е. записан в МХ)!? и да - не во всех доменах прописан SPF и контролируя его можно заблочить получение почты

сервер отправки МОЖЕТ НЕ БЫТЬ сервером для приема, поэтому не обязательно будет в MX записи, и это будет ПРАВИЛЬНО

ЗЫЖ пустой разговор получается или или уже обсуждаются проблемы специфичные Казахстанским провайдерам?

я часто вижу советы добавить сервер отправителя в MX запись домена,
что абсолютно не логично и не правильно
а заморочки провайдеров - интернациональны, у всех бывают

 

[aameno2]

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

 

[lmike]

сервер отправки МОЖЕТ НЕ БЫТЬ сервером для приема, поэтому не обязательно будет в MX записи, и это будет ПРАВИЛЬНО

так зачем он отправляет напрямую? внутренний трафик экономит ?
в каждой точке инфраструктуры д.б. отправляющий сервер и принимающий сервер и никаких препятствий для назначения трафика (исходящего) от имени сервера в МХ я не вижу, а вот потенциальные фэйлы - вижу
нет слова ПРАВИЛЬНО если возникают проблемы, не нужно "учить жить" окружающих в случае когда компромиссы легко достижимы
в идеальном мире нет спама, и не нужны всякие ухищрения, а вот в реальном...

 

[Мыш]

lmike, проблема в том, что МХ, вообще говоря, обязан принимать почту.
А если я не хочу? Пример из жизни - у нас есть сервер рассылки уведомлений (из СЭД и пр.). Отправляет, в том числе, и по SMTP внешним корреспондентам. И на хрена, спрашивается, его назначать МХ-ом, если он никогда и ничего не принимает? Зачем делать фэйковый МХ?

 

[lmike]

Отправляет, в том числе, и по SMTP внешним корреспондентам.

что мешает сделать через релей?

 

[Мыш]

что мешает сделать через релей?

1. В моем варианте - если релей умрет (DDOS-атака,скажем), то уведомления будут по-прежнему работать. Это как бы пресловутая fault tolerance.
2. Уведомлений (у нас) бывает по неск. тысяч в час. Понятно, что письма маленькие - тем не менее, зачем же создавать излишнюю нагрузку на релей? Мы ведь, пардон, не на Крэях работаем, и наши клиенты - тоже.
3. Системы контроля контента. Тов. Майору (как показывает моя практика) намного интересней исходящий трафик. И тут уже вступают в силу ограничения контролирующего софта - скажем, нет версии под *nix, на котором работает MX. Сообразно, переводим исходящий трафик под Винду... Увы, но это реальность.

 

[lmike]

1 - если никсовый кластер - не умрет
2 - никса вполне себе переварят и больше, а на домину нагрузка таже.
3 - если рассмотреть предыдущий пункт - то какбе уже релей
мне кажется всё это надуманным... ("сложности" с релеем)
и вряд ли послужит оправданием утерянных писем
и если есть возможность отправить через валидный МХ - так и нужно делать
в конце-концов - большинство:
- не явл. провайдерами с большим трафиком писем (большим - тыщи в секунду)
- занести домину в МХ - плёвая тема
- или перенаправить почту через цепочку релеев, оконечный из кот. в МХ - тоже не задача из ранга трудных

ЗЫЖ опять нас сносит в сторону почему "не так" вместо просто "подстраховки" от проверки МХ (принимающей стороной)