Re: Проблема с проверкой домена отправителя, IPv6.

Здравствуйте,

Sergey Chumakov wrote:
> На Tue, 27 Jan 2009 10:47:38 +0300
> "Dmitry Akindinov" <CGatePro@mx.ru> записано:
>

>> Здравствуйте,
>>
>> Sergey Chumakov wrote:
>>> Добрый день.
>>>
>>> FreeBSD 6.2/7.1, CGP 5.2.9/5.2.10.
>>>
>>> Иногда не удается отправить письмо с адреса в почтовом домене, MX-ы
>>> которого содержат IPv6 адреса.
>>>
>>> 23:10:33.246 4 SMTPI-495989([1.1.1.1]) checking MX-record for freebsd.org
>>> 23:10:33.246 5 SMTPI-495989([1.1.1.1]) reverse-connecting to [2001:4f8:fff6::34]:25
>>> 23:10:33.246 1 SMTPI-495989([1.1.1.1]) Return-Path 'mav@FreeBSD.org' rejected: no relay available
>>>
>>> Похожая проблема (номер 2) была описана в этом письме:
>>> http://mx.ru/Lists/CGatePro/Message/17240.html?Skin=Russian
>>>
>>> Дело вот в чем:
>>>
>>> $  host mx1.freebsd.org
>>> mx1.freebsd.org has address 69.147.83.52
>>> mx1.freebsd.org has IPv6 address 2001:4f8:fff6::34
>>>
>>> CGP делает запрос MX, и если в дополнительной секции ответа содержатся
>>> записи, то запрос А-записи уже не производится:
>>>
>>> 22:29:39.812 5 DNR-029241(freebsd.org) MX-request
>>> 22:29:39.812 4 DNR-029241(freebsd.org) MX-request -> udp:[195.248.191.67]:53
>>> 22:29:39.812 5 DNR-029241(freebsd.org) got 195 bytes from [195.248.191.67]:53: 72 39 81 80 00 01 00 01 00 02 00 04 07 66 72 65 65 62 73 64 03 6F 72 67 00 00 0F 00 01 C0 0C 00 0F 00 01 00 00 00 D1 00 08 00 0A 03 6D 78 31 C0 0C C0 0C 00 02 00 01 00 00 09 F2 00 11 03 6E 73 32 07 69 73 63 2D 73 6E 73
>>> 22:29:39.812 5 DNR-029241(freebsd.org) MX:OK 22:29:39.812 4 DNR-029241(freebsd.org) MX[0]: freebsd.org(pty 10) = mx1.freebsd.org
>>> 22:29:39.812 4 DNR-029241(freebsd.org) suppl[0]: mx1.freebsd.org=[2001:4f8:fff6::34]
>>>
>>> Такая ситуация получается, когда в кэше сервера имен А-записи
>>> mx1.freebsd.org уже нет (TTL закончился), а АААА-запись еще есть,
>>> соответственно он и выдает только ее в дополнительной секции.
>> Сщмнительно, что такое поведение DNS сервера можносчитать нормальным. 
>> Если уж выдавать записи, то все?

А смысл выдавать не все записи? Тогда их лучше не выдавать вообще - раз надежным способом использовать их не удается. Тогда бы сервер пошел за записями A сам.

>>> Если вычистить все записи из кэша DNS, CGP делает все честно, т.е.
>>> запрашивает А-запись тоже, и все работает как надо:
>>>
>>> 23:17:28.740 5 DNR-019703(freebsd.org) MX-request
>>> 23:17:28.740 4 DNR-019703(freebsd.org) MX-request -> udp:[195.248.191.67]:53
>>> 23:17:28.740 5 DNR-019703(freebsd.org) got 167 bytes from [195.248.191.67]:53: 4C F7 81 80 00 01 00 01 00 02 00 03 07 66 72 65 65 62 73 64 03 6F 72 67 00 00 0F 00 01 C0 0C 00 0F 00 01 00 00 00 A5 00 08 00 0A 03 6D 78 31 C0 0C C0 0C 00 02 00 01 00 00 0C 5D 00 11 03 6E 73 32 07 69 73 63 2D 73 6E 73
>>> 23:17:28.740 5 DNR-019703(freebsd.org) MX:OK
>>> 23:17:28.740 4 DNR-019703(freebsd.org) MX[0]: freebsd.org(pty 10) = mx1.freebsd.org
>>> 23:17:28.740 5 DNR-019704(mx1.freebsd.org) A-request
>>> 23:17:28.740 4 DNR-019704(mx1.freebsd.org) A-request -> udp:[195.248.191.67]:53
>>> 23:17:28.800 5 DNR-019704(mx1.freebsd.org) got 167 bytes from [195.248.191.67]:53: 4C F8 81 80 00 01 00 01 00 02 00 03 03 6D 78 31 07 66 72 65 65 62 73 64 03 6F 72 67 00 00 01 00 01 C0 0C 00 01 00 01 00 00 0E 10 00 04 45 93 53 34 C0 10 00 02 00 01 00 00 0C 5D 00 11 03 6E 73 32 07 69 73 63 2D 73 6E
>>> 23:17:28.800 5 DNR-019704(mx1.freebsd.org) A:OK
>>> 23:17:28.800 4 DNR-019704(mx1.freebsd.org) A[0]: mx1.freebsd.org=[69.147.83.52]
>>>
>>> Ключик --IPv6 NO проблему не решает, а должен бы, по логике.
>> Там попытки соединения по IPv6 в этом случае не происходит. Но проблемы 
>> это не решает: от DNS была получена одна MX запись, да и та - нерабочая.
>>

Да, я неправильно сформулировал. DNS сервер оказал "услугу" и заранее разрезолвил MX запись, которую ку него попросили. Но выдал не все записи. Вопрос - какой в этом смысл?

> Отсюда FR: если указан ключ --IPv6 NO - игнорировать АААА-записи DNS.
> Это будет логичным.

Ну было бы там две IPv4 записи. Одна из них - на 127.0.0.1, как это сейчас модно "для борьбы со спамом". И вот из двух вернулась только одна, эта, нерабочая.

Проблема в том, что записи были получнеы не все, а не в том, что одна из них - IPv6.

-- 
Best regards,
Dmitry Akindinov -- Stalker Labs.