не думаю, что имеет смысл его развивать в сторону обсуждения применимых RFC
RFC - это тот же закон, но только для сети Internet. Кроме того, это STD0010. А это уже стандарт. И посмотрите в разделе Examples какой ДОЛЖЕН БЫТЬ ОТВЕТ сервера в приведенном мной примере. Если он не соответствует ожидаемому, то это свидетельствует о том, что либо мы столкнулись с неверной реализацией RFC, либо нет отсева по обратной зоне. Ну так как это тогда называется? Хорошо, пусть не ламерство. Назовем тогда это "новым мЫшлением".
Давно тут не был, только что долго пароль восстанавливал (дяденьки не бейте, не ломал я тутошний сервак :-) )
Всем привет.
Приведу замечательный пример невозможности следовать "законам для сети Интернет", в частности этим достаточно тупым переработкам вечного и незабвенного РФЦ 822.
Итак топология: 2 канала в инет, основной и резервный. Пров, на которого резервный канал, держит наш домен и вторичный почтовик (первичный наш собственный). Основной канал на то и основной, чтобы все шло через него. Т.е. у меня есть законный МХ на ИП от резервного прова. Но почтовик как и прочий сетевой софт гоняет трафик через основной канал - уж больно дешевше там да и канал жирнее. Т.е. идет с ИП основного прова. Теперь по этому замечательному РФЦ целевой почтовик делает реверс-обзор хоста и отстреливает меня как чумного, т.к. ИП основного прова не имеет ничего общего с МХ от резервного прова. Однако у меня ЗАКОННЫЙ МХ, я не отсылаю спам, я не подделываю служебную информацию в заголовках. И хочу заметить, что это не персональная кривизна построения топологии, а у других есть точно такие же проблемы, когда МХ на одном ИП, а исходящий трафик с другого ИП. Посему если нет желания лишить народ ну не половины, но очень приличной части почты - надо это самое РФЦ делить на 12.
