|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 12 Jul 2004 22:28:03
To : Valery Lutoshkin
Subject : Re: О борьбе со спамом.
--------------------------------------------------------------------------------
>>> Valery Lutoshkin wrote:
VN>>>>>> Hепонятно. Чтобы проверить что proxy.some.domain показывает на этот
VN>>>>>> адрес, никому нафиг не нужно чтобы этот адрес имел PTR на
VN>>>>>> proxy.some.domain. Достаточно прямого резолвинга (IN A).
VL>>>>> Однако, возвращаясь к, антиспамовые системы требуют наличия PTR, а не
VL>>>>> пользуются прямым ресолвингом.
VN>>>> Да, но их в подавляющем большинстве случаев интересует факт
VN>>>> существования корректного резолвинга, а не конкретные значения.
VL>>> Вот видимо кое-где сие все-таки не так. Иначе бы и проблемы с
VL>>> несколькими ptr не было, правильно? При нескольких ptr факт существования
VL>>> корректного ресолвинга адреса в какое-нибудь из имен будет иметь место в
VL>>> любом случае.
VN>> OK, уточнение: их интересует факт существования корректного резолвинга
VN>> (ip -> name -> тот же ip) при том, что реализация берёт только одно имя
VN>> из нескольких возможно полученных.
VL> Эка блин квотить сколько приходится. Hо иначе мысль теряется :(
VL> Так твое уточнение, опять же, не подразумевает проблему с несколькими PTR.
Оно подразумевает, что эта проблема тупо игнорируется.
VL> Вообще, проблема с несколькими PTR возможна в одном случае - если имя,
VL> которое должно ресолвиться в IP, берется не из dns, а какими-либо другими
VL> путями (зашито в софт, берется из HELO и прочая). Hу или еще - если в
VL> цепочке ресолвинга имя из dns берется больше одного раза.
Hет, она возникает именно из проверки IP адреса на резолвинг.
Зачем было бы проверять обратный резолвинг для адреса, полученного из имени?
В принципе такой случай я знаю - когда требуется канонизация однокомпонентного
имени до уровня FQDN - но даже в этом случае этот механизм используется
почти в последнюю очередь.
VL>>> Конечно, решение проблемы может быть произведено ценой бОльших или
VL>>> меньших усилий, но я все-таки сначала попытаюсь запинать криво работающих
VL>>> антиспамеров :)
VN>> Боюсь, что их слишком много, чтобы можно было всех запинать.
VL> Мне достаточно запинать только одного. В случае которого моя контора сама
VL> заинтересована, чтобы почта к нему уходила.
bind9 + views
VL> Для всех остальных - пусть
VL> получатели почты сами разбираются, потому что это нужно им, а не мне. Если
VL> каждый заинтересованный пнет своего провайдера - все получится само собой :)
-netch-
--- ifmail v.2.15dev5.3
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
