The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"postfix&exchange- конфликт админов"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение [Проследить за развитием треда]

"postfix&exchange- конфликт админов"  
Сообщение от SiN (ok) on 05-Дек-07, 10:55 
С одной организации до меня не доходила, почта, стал разбираться в причине.
Кусок моего лога:
Dec  5 10:46:59 mail postfix/smtpd[11604]: connect from domain.ru[xxx.xxx.xxx.xxx]
Dec  5 10:46:59 mail postfix/smtpd[11604]: NOQUEUE: reject: RCPT from domain.ru[xxx.xxx.xxx.xxx]: 450 4.7.1 <host.domain.ru>: Helo command rejected: Host not found; from=<user@domain.ru> to=<main@domain1.ru> proto=ESMTP helo=<host.domain.ru>
Dec  5 10:46:59 mail postfix/smtpd[11604]: disconnect from domain.ru[xxx.xxx.xxx.xxx]

В кратце причина:
host.domain.ru Имя хоста в заголовках
domain.ru реальное имя домена

в соответсвии с RFC821 в HELO должно быть имя домена. а у тут не имя домена, а имя хоста в этом домене.

У меня в постфиксе стоит проверка заголовков, в том числе имен и соответствия ип адресам, естественно получаемое письмо эту проверку не проходит.

Админы противоположной компании, говорят, что проблемы только со мной, что со всеми остальными у них все ходит, и работает  и ДАЖЕ с ПИТЕРОМ ;), мои мольбы и просьбы изучить  RFC821 ни к чему не привели. Исправлять у себя ни чего не хотят, почтой обмениваться надо, я же в свою очередь, проверку тоже отключать не хочу, т.к. она ооочень отшибает спам более 90%.

Соответсвенно вопрос, можно ли мой постфикс заставить как нибудь не проверять почтовый трафик с домена противоположной компании?

Высказать мнение | Ответить | Правка | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "postfix&exchange- конфликт админов"  
Сообщение от U email(??) on 05-Дек-07, 11:03 
>[оверквотинг удален]
>
>Админы противоположной компании, говорят, что проблемы только со мной, что со всеми
>остальными у них все ходит, и работает  и ДАЖЕ с
>ПИТЕРОМ ;), мои мольбы и просьбы изучить  RFC821 ни к
>чему не привели. Исправлять у себя ни чего не хотят, почтой
>обмениваться надо, я же в свою очередь, проверку тоже отключать не
>хочу, т.к. она ооочень отшибает спам более 90%.
>
>Соответсвенно вопрос, можно ли мой постфикс заставить как нибудь не проверять почтовый
>трафик с домена противоположной компании?

Если коротко, то смотреть в сторону check_sender_access

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "postfix&exchange- конфликт админов"  
Сообщение от Sam (??) on 05-Дек-07, 11:22 
Из RFC821

The argument field contains the host name of the sender-SMTP.
Так что еще вопрос кто прав.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "postfix&exchange- конфликт админов"  
Сообщение от Redduck (??) on 05-Дек-07, 12:02 
У меня часто встречается такая ситуация, когда в HELO посылают все что угодно, даже localhost. Бороться с такими трудно. А в HELO наверника должна стоять запись компа (сервера) имеющего запись в прямой и обратной зоне на DNS сервере. :) (Плохо знаю английский, читал только перевод rfc)
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "postfix&exchange- конфликт админов"  
Сообщение от SiN (ok) on 05-Дек-07, 13:13 
>должна стоять запись компа (сервера) имеющего запись в прямой и обратной
>зоне на DNS сервере. :) (Плохо знаю английский, читал только перевод
>rfc)

Абсолютно точно, и на нормальных серверах (с нормальными прокладками между стулом и клавой) оно приведено в соотвествие...

А то, что у части народа в заголовках содержиться хлам тык это и способствует спамерству в инете, и администраторы должны понимать это и приводить в норму, просто есть админы, которые спасибо скажут за найденную ошибку, а некоторые и пальцем не пошевелят...
Кстати процент серверов с кривыми HELLO на самом деле не очень то и велик, за мой последний год работы это второй случай (не ISP, но почты ходит много), при первом у меня стоял qmail тоже с проверкой, но там админы адекватные были, и все поправили.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "postfix&exchange- конфликт админов"  
Сообщение от SiN (ok) on 05-Дек-07, 13:00 
>Из RFC821
>
>The argument field contains the host name of the sender-SMTP.
>Так что еще вопрос кто прав.

Я не совсем точно исказил информацию ( :) ) :
Выглядит так:
есть провайдер: provider.ru
есть клиент: org.provider.ru
На нем (клиенте, стоит почтовый сервер) и он то как раз и является хостовой машиной для провайдера и доменом для себя (своей организации), а в hello приходит comp1.org.provider.ru

И вы считаете это верным?!


А что такое тогда вот это и для чего или кого?

----------
       The sender-SMTP MUST ensure that the <domain> parameter in a
        HELO command is a valid principal host domain name for the
        client host.  As a result, the receiver-SMTP will not have to
        perform MX resolution on this name in order to validate the
        HELO parameter.

        The HELO receiver MAY verify that the HELO parameter really

RFC1123                  MAIL -- SMTP & RFC-822             October 1989

        corresponds to the IP address of the sender.  However, the
        receiver MUST NOT refuse to accept a message, even if the
        sender's HELO command fails verification.
----------

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "postfix&exchange- конфликт админов"  
Сообщение от A Clockwork Orange on 05-Дек-07, 13:28 
>[оверквотинг удален]
>          
> October 1989
>
>        corresponds to the IP
>address of the sender.  However, the
>        receiver MUST NOT refuse
>to accept a message, even if the
>        sender's HELO command fails
>verification.
>----------

Так вот же английским по зеленому написано

However, the receiver MUST NOT refuse to accept a message, even if the
sender's HELO command fails verification.

Однако, получатель НЕ ДОЛЖЕН отказывать принимать сообщение, даже если отправительская команда HELO не проходит проверку.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "postfix&exchange- конфликт админов"  
Сообщение от SiN (ok) on 05-Дек-07, 13:35 
>[оверквотинг удален]
>>----------
>
>Так вот же английским по зеленому написано
>
>However, the receiver MUST NOT refuse to accept a message, even if
>the
>sender's HELO command fails verification.
>
>Однако, получатель НЕ ДОЛЖЕН отказывать принимать сообщение, даже если отправительская команда HELO
>не проходит проверку.

Да дело то не только в HELO, он и на тест обратной зоны проверку не проходит, т.к. ну нет там соответсвия ip и имени которое пришло в заголовке!!!


Ну млин....

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "postfix&exchange- конфликт админов"  
Сообщение от Sam (??) on 05-Дек-07, 13:31 
А такой helo [ip address] - тоже неправильный?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "postfix&exchange- конфликт админов"  
Сообщение от SiN (ok) on 05-Дек-07, 14:42 
>А такой helo [ip address] - тоже неправильный?

Цетирую из: http://www.yekt.info/postfix_antyspam.html
-----
файл /etc/postfix/helo_regexp:

/([0-9]{1,3}(\.|-)){3}[0-9]{1,3}/i      REJECT IP-able helo SPAM

запрещаем ИП-адрес в качестве HELO.
Это явное нарушение RFC, но практика показала, что это работает без сбоев.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "postfix&exchange- конфликт админов"  
Сообщение от psn1982 email(??) on 05-Дек-07, 15:02 
>[оверквотинг удален]
>>The argument field contains the host name of the sender-SMTP.
>>Так что еще вопрос кто прав.
>
>Я не совсем точно исказил информацию ( :) ) :
>Выглядит так:
>есть провайдер: provider.ru
>есть клиент: org.provider.ru
>На нем (клиенте, стоит почтовый сервер) и он то как раз и
>является хостовой машиной для провайдера и доменом для себя (своей организации),
>а в hello приходит comp1.org.provider.ru

Вся проблема в том, что в зоне прямого просмотра нету A записи comp1.org.provider.ru, и нельзя определить IP адрес. Такого хоста просто не существует для внешнего мира. Нужно в зоне прямого просмотра просто добавить A запись comp1.org.provider.ru которая будет соответствовать IP почтовика.
В зоне обратного просмотра должна быть PTR запись для IP адреса почтовика, соответствующая  comp1.org.provider.ru, то что вываливает HELO.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "postfix&exchange- конфликт админов"  
Сообщение от SiN (ok) on 05-Дек-07, 15:12 
>[оверквотинг удален]
>>На нем (клиенте, стоит почтовый сервер) и он то как раз и
>>является хостовой машиной для провайдера и доменом для себя (своей организации),
>>а в hello приходит comp1.org.provider.ru
>
>Вся проблема в том, что в зоне прямого просмотра нету A записи
>comp1.org.provider.ru, и нельзя определить IP адрес. Такого хоста просто не существует
>для внешнего мира. Нужно в зоне прямого просмотра просто добавить A
>запись comp1.org.provider.ru которая будет соответствовать IP почтовика.
>В зоне обратного просмотра должна быть PTR запись для IP адреса почтовика,
>соответствующая  comp1.org.provider.ru, то что вываливает HELO.

Ну я предлогал им более демократичный способ, почтовому серверу присвоить имя org.provider.ru, т.к. хозяин (провайдер) зоны provider.ru не будет добавлять в файл зоны доменов 4 го уровня :) Иначе затолбают его с такими просбами, да и порядка не будет ;)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

14. "postfix&exchange- конфликт админов"  
Сообщение от psn1982 email(??) on 05-Дек-07, 15:16 
>[оверквотинг удален]
>>comp1.org.provider.ru, и нельзя определить IP адрес. Такого хоста просто не существует
>>для внешнего мира. Нужно в зоне прямого просмотра просто добавить A
>>запись comp1.org.provider.ru которая будет соответствовать IP почтовика.
>>В зоне обратного просмотра должна быть PTR запись для IP адреса почтовика,
>>соответствующая  comp1.org.provider.ru, то что вываливает HELO.
>
>Ну я предлогал им более демократичный способ, почтовому серверу присвоить имя org.provider.ru,
>т.к. хозяин (провайдер) зоны provider.ru не будет добавлять в файл зоны
>доменов 4 го уровня :) Иначе затолбают его с такими просбами,
>да и порядка не будет ;)

Нормальный провайдер зону может делегировать....

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "postfix&exchange- конфликт админов"  
Сообщение от SiN (ok) on 05-Дек-07, 14:37 
>[оверквотинг удален]
>>остальными у них все ходит, и работает  и ДАЖЕ с
>>ПИТЕРОМ ;), мои мольбы и просьбы изучить  RFC821 ни к
>>чему не привели. Исправлять у себя ни чего не хотят, почтой
>>обмениваться надо, я же в свою очередь, проверку тоже отключать не
>>хочу, т.к. она ооочень отшибает спам более 90%.
>>
>>Соответсвенно вопрос, можно ли мой постфикс заставить как нибудь не проверять почтовый
>>трафик с домена противоположной компании?
>
>Если коротко, то смотреть в сторону check_sender_access

Вы про это:

smtpd_sender_restrictions =    permit_mynetworks,
                check_sender_access hash:$base/sender_access,
                reject_authenticated_sender_login_mismatch,
                reject_unknown_sender_domain,
                reject_unlisted_sender,
                reject_unverified_sender

добавил я в файл sender_access домен, пересобрал .db, перестартовал postfix, но почта с хоста так и не принемается все по той же причине :(

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "postfix&exchange- конфликт админов"  
Сообщение от Sam (??) on 05-Дек-07, 14:39 
smtpd_client_restrictions

>smtpd_sender_restrictions = permit_mynetworks,
>    check_sender_access hash:$base/sender_access,
>    reject_authenticated_sender_login_mismatch,
>    reject_unknown_sender_domain,
>    reject_unlisted_sender,
>    reject_unverified_sender

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

15. "postfix&exchange- конфликт админов"  
Сообщение от SiN (ok) on 05-Дек-07, 15:18 
>smtpd_client_restrictions
>
>>smtpd_sender_restrictions = permit_mynetworks,
>>    check_sender_access hash:$base/sender_access,
>>    reject_authenticated_sender_login_mismatch,
>>    reject_unknown_sender_domain,
>>    reject_unlisted_sender,
>>    reject_unverified_sender

И его опробовал не помогает:

Может: smtpd_helo_restrictions поможет?

Где бы поподробней инфу почитать о smtpd_*_restrictions

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

16. "postfix&exchange- конфликт админов"  
Сообщение от Sam (??) on 05-Дек-07, 15:21 
http://www.postfix.org/spam.html
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

17. "postfix&exchange- конфликт админов"  
Сообщение от SiN (ok) on 05-Дек-07, 16:16 
>http://www.postfix.org/spam.html

Вот нашел на русском, может кому еще пригодиться (очень хороший док):
http://www.freesource.info/wiki/Dokumentacija/Postfix/antisp...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

18. "postfix&exchange- конфликт админов"  
Сообщение от SiN (ok) on 05-Дек-07, 16:47 
>>http://www.postfix.org/spam.html
>
>Вот нашел на русском, может кому еще пригодиться (очень хороший док):
>http://www.freesource.info/wiki/Dokumentacija/Postfix/antisp...

Вопрос снимаю с повестки дня
Проблема решена добавлением кривого адреса приходящего ко мне в helo в бд smtpd_helo_restrictions

УРА!!!

Особая благодарность за помощь Sam ;)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

19. "postfix&exchange- конфликт админов"  
Сообщение от CSX email(ok) on 06-Дек-07, 07:01 

>Админы противоположной компании, говорят, что проблемы только со мной, что со всеми
>остальными у них все ходит, и работает  и ДАЖЕ с
>ПИТЕРОМ ;), мои мольбы и просьбы изучить  RFC821 ни к
>чему не привели. Исправлять у себя ни чего не хотят, почтой
>обмениваться надо, я же в свою очередь, проверку тоже отключать не
>хочу, т.к. она ооочень отшибает спам более 90%.

А теперь представь себе хостинговый сервер hosting.ru
На котором куча доменов domain.ru, domain2.ru, domain3.ru, domain4.ru, domain5.ru
И куча IP 1.1.1.1, 1.1.1.2, 1.1.1.3, причем IP меньше чем доменов.

Как по твоему это все должно работать? ;)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

20. "postfix&exchange- конфликт админов"  
Сообщение от SiN (??) on 06-Дек-07, 07:26 
>[оверквотинг удален]
>>ПИТЕРОМ ;), мои мольбы и просьбы изучить  RFC821 ни к
>>чему не привели. Исправлять у себя ни чего не хотят, почтой
>>обмениваться надо, я же в свою очередь, проверку тоже отключать не
>>хочу, т.к. она ооочень отшибает спам более 90%.
>
>А теперь представь себе хостинговый сервер hosting.ru
>На котором куча доменов domain.ru, domain2.ru, domain3.ru, domain4.ru, domain5.ru
>И куча IP 1.1.1.1, 1.1.1.2, 1.1.1.3, причем IP меньше чем доменов.
>
>Как по твоему это все должно работать? ;)

Работает же, и народ нежалуется qmail+vpopmail ;)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

21. "postfix&exchange- конфликт админов"  
Сообщение от CSX email(ok) on 06-Дек-07, 07:28 
>[оверквотинг удален]
>>>обмениваться надо, я же в свою очередь, проверку тоже отключать не
>>>хочу, т.к. она ооочень отшибает спам более 90%.
>>
>>А теперь представь себе хостинговый сервер hosting.ru
>>На котором куча доменов domain.ru, domain2.ru, domain3.ru, domain4.ru, domain5.ru
>>И куча IP 1.1.1.1, 1.1.1.2, 1.1.1.3, причем IP меньше чем доменов.
>>
>>Как по твоему это все должно работать? ;)
>
>Работает же, и народ нежалуется qmail+vpopmail ;)

Что значит работает же? Что должен говорить сервер в HELO? с какого IP должен слать почту? Какой должен быть обратный резолвинг у этого IP?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

22. "postfix&exchange- конфликт админов"  
Сообщение от SiN (??) on 06-Дек-07, 08:55 
>[оверквотинг удален]
>>>На котором куча доменов domain.ru, domain2.ru, domain3.ru, domain4.ru, domain5.ru
>>>И куча IP 1.1.1.1, 1.1.1.2, 1.1.1.3, причем IP меньше чем доменов.
>>>
>>>Как по твоему это все должно работать? ;)
>>
>>Работает же, и народ нежалуется qmail+vpopmail ;)
>
>Что значит работает же? Что должен говорить сервер в HELO? с какого
>IP должен слать почту? Какой должен быть обратный резолвинг у этого
>IP?

ИП, резолвинг этогоИП,и имя указывется основного сервера (Например mail.provider.ru)
HELO тоже соответственно имя основного сервера
Имена доменов подменяются только в поле from.
А при проверке существования виртуальных ящиков сервером проверяется наличие домена в списках, наличие ящика и затем в случае успешных проверок отдается true...
Или я не прав?


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

23. "postfix&exchange- конфликт админов"  
Сообщение от CSX email(ok) on 06-Дек-07, 09:11 
>[оверквотинг удален]
>>Что значит работает же? Что должен говорить сервер в HELO? с какого
>>IP должен слать почту? Какой должен быть обратный резолвинг у этого
>>IP?
>
>ИП, резолвинг этогоИП,и имя указывется основного сервера (Например mail.provider.ru)
>HELO тоже соответственно имя основного сервера
>Имена доменов подменяются только в поле from.
>А при проверке существования виртуальных ящиков сервером проверяется наличие домена в списках,
>наличие ящика и затем в случае успешных проверок отдается true...
>Или я не прав?

И в один прекрасный день IP попадает в пару популярных спам-листов, и даже не IP а вся подсеть. И со всех хостинговых серверов перестает доходить почта, каждые пять минут звонят клиенты и жалуются. Почту нужно слать с IP из другой подсети, который можно оперативно заменить и начать выносить предыдущий из спамлистов.
Еще одна причина -- отдельный канал и сетевой интерфейс специально для почты (т.е. не основной IP сервера), не занятый вообще больше ничем.
Это не RFC, это жизнь.

Кроме того, есть куча "любителей RFC" плохо, к сожалению, знакомых с английским которые делают проверки типа:
1. соответствие HELO и From
2. Соответствие PTR IP с которого пришел коннект и A записи домена из FROM и/или HELO
3. Соответствие IP A записи домена в PTR записи IP с которого пришел коннект и IP с которого пришел коннект (башку можно сломать да?)
Ну и всякие другие "гениальные вещи".

А вот Вам ещё примерчик:

[root@freebsd ~]# dig mx gmail.com

;; ANSWER SECTION:
gmail.com.              1273    IN      MX      10 alt1.gmail-smtp-in.l.google.com.
gmail.com.              1273    IN      MX      10 alt2.gmail-smtp-in.l.google.com.
gmail.com.              1273    IN      MX      50 gsmtp163.google.com.
gmail.com.              1273    IN      MX      50 gsmtp183.google.com.
gmail.com.              1273    IN      MX      5 gmail-smtp-in.l.google.com.


[root@freebsd ~]# dig gmail-smtp-in.l.google.com

;; ANSWER SECTION:
gmail-smtp-in.l.google.com. 284 IN      A       64.233.183.114
gmail-smtp-in.l.google.com. 284 IN      A       64.233.183.27

[root@freebsd ~]# dig -x 64.233.183.114

;; ANSWER SECTION:
114.183.233.64.in-addr.arpa. 86400 IN   PTR     gsmtp183-2.google.com.

[root@freebsd ~]#

Гмыло не соответствует RFC ? :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

25. "postfix&exchange- конфликт админов"  
Сообщение от SiN (??) on 06-Дек-07, 09:28 
>И в один прекрасный день IP попадает в пару популярных спам-листов, и
>даже не IP а вся подсеть. И со всех хостинговых серверов
>перестает доходить почта, каждые пять минут звонят клиенты и жалуются. Почту
>нужно слать с IP из другой подсети, который можно оперативно заменить
>и начать выносить предыдущий из спамлистов.
>Еще одна причина -- отдельный канал и сетевой интерфейс специально для почты
>(т.е. не основной IP сервера), не занятый вообще больше ничем.
>Это не RFC, это жизнь.

Вчера, когда искал доку по постфиксу, нашел одну статейку, адрес к сожалению не сохранил, так вот написано, что защищаться надо не только от внешних воздействий но и от своих клиентов :)
И проблемы тогда с попаданием в spam листы врядли будут

Только что, не поленился и завел ящик на gmail.com отправил тестовое письмо на свой почтовый сервер (с постфиксом, который оттопыривал сообщения, и стал причиной создания этого трейда) и как ты думаешь? Письмо дошло...

Хотя согласно твоим мыслям такое работать не должно :)

>Отдельный канал и сетевой интерфейс специально для почты (т.е. не основной IP сервера), >не занятый вообще больше ничем

В этом проблем вобще ни каких не вижу, в большинстве своем оно всегда так.

>Кроме того, есть куча "любителей RFC" плохо, к сожалению, знакомых с английским которые >делают проверки типа:
>1. соответствие HELO и From
>2. Соответствие PTR IP с которого пришел коннект и A записи домена из FROM и/или HELO
>3. Соответствие IP A записи домена в PTR записи IP с которого пришел коннект и IP с >которого пришел коннект (башку можно сломать да?)

Это как рассматривать, я вот смотрю на это со стороны борьбы со спамом, и если бы все грамотно подходили к настройке почтового сервера, и ставили подобные фишки, то спамерам стало бы жить ооочень худо


Так что еще раз -  все зависит от прокладки между клавой и креслом ;)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

26. "postfix&exchange- конфликт админов"  
Сообщение от Golub Mikhail (ok) on 06-Дек-07, 11:23 
>[оверквотинг удален]
>   64.233.183.27
>
>[root@freebsd ~]# dig -x 64.233.183.114
>
>;; ANSWER SECTION:
>114.183.233.64.in-addr.arpa. 86400 IN   PTR     gsmtp183-2.google.com.
>
>[root@freebsd ~]#
>
>Гмыло не соответствует RFC ? :)

Соответсвует.
gmail-smtp-in.l.google.com используется у них для приема почты.
Отправка идет с других хостов. С того же, например, gsmtp183.google.com, а с ним все ОК.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

27. "postfix&exchange- конфликт админов"  
Сообщение от CSX email(??) on 06-Дек-07, 16:29 
>Соответсвует.
>gmail-smtp-in.l.google.com используется у них для приема почты.
>Отправка идет с других хостов. С того же, например, gsmtp183.google.com, а с
>ним все ОК.

Именно! Я про то и говорю :)

2 SiN

Возможно, я Вас неправильно понимаю.

"Да дело то не только в HELO, он и на тест обратной зоны проверку не проходит, т.к. ну нет там соответсвия ip и имени которое пришло в заголовке!!!"

Берем тот же гугл. Письмо приходит с хоста gsmtp183.google.com, который ну никак не похож на то что в заголовке (gmail.com)

Либо Вы не до конца понимаете как работает Ваша система, либо чего-то не догоняю я...


На самом деле решение всей этой загадки уже было в обсуждении, вот оно

"Вся проблема в том, что в зоне прямого просмотра нету A записи comp1.org.provider.ru, и нельзя определить IP адрес. Такого хоста просто не существует для внешнего мира. Нужно в зоне прямого просмотра просто добавить A запись comp1.org.provider.ru которая будет соответствовать IP почтовика. В зоне обратного просмотра должна быть PTR запись для IP адреса почтовика, соответствующая  comp1.org.provider.ru, то что вываливает HELO."

Однако и это ЖЕЛАТЕЛЬНО но не обязательно
Ибо как кто-то верно заметил:
The HELO receiver MAY verify that the HELO parameter really corresponds to the IP address of the sender.  However, the receiver MUST NOT refuse to accept a message, even if the sender's HELO command fails verification.

В общем читаем тут, тут даже табличка есть интересная на эту тему (кто что может и  должен)
http://www.faqs.org/rfcs/rfc1123.html

Почему так сделано? Да просто хотя бы потому что на Ваших ДНС серверах может быть устаревшая информация в кеше.

Я понимаю, что все это делается в целях борьбы со спамом, но "свинья грязь найдет" и спам будет, а вот нормальным людям, в особенности хостинг-провайдерам, это порой доставляет немало хлопот.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

28. "postfix&exchange- конфликт админов"  
Сообщение от pOint email(ok) on 13-Дек-07, 18:00 
>Почему так сделано? Да просто хотя бы потому что на Ваших ДНС
>серверах может быть устаревшая информация в кеше.
>Я понимаю, что все это делается в целях борьбы со спамом, но
>"свинья грязь найдет" и спам будет, а вот нормальным людям, в
>особенности хостинг-провайдерам, это порой доставляет немало хлопот.

В таком случае можно сделать open relay, сложить руки и через некоторое время выковыривать свой хост из блек листов, ругая на чем свет стоит RBL и тому подобное, говоря, что
"..."свинья грязь найдет" и спам будет, а вот нормальным людям, в особенности хостинг-провайдерам, это порой доставляет немало хлопот..."
RBL многим не нравится, проверка соответствия тоже не устраивает - spamassissin тогда вообще ф топку??? Купить трафа побольше (чтоб на спам хватало) и гуд???

Ничего личного. Мое субъективное мнение.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

29. "postfix&exchange- конфликт админов"  
Сообщение от CSX email(ok) on 13-Дек-07, 18:04 
А может быть стоит не зацикливаться на субъективном мнении а попытаться все же понять, почему в объективных RFC написано именно так, а не иначе?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

30. "postfix&exchange- конфликт админов"  
Сообщение от pOint email(ok) on 13-Дек-07, 18:11 
>А может быть стоит не зацикливаться на субъективном мнении а попытаться все
>же понять, почему в объективных RFC написано именно так, а не
>иначе?

RFC - рекомендации, но не правила.
А может привести все записи DNS в соответствие с реальностью?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

24. "postfix&exchange- конфликт админов"  
Сообщение от SiN (??) on 06-Дек-07, 09:12 
>[оверквотинг удален]
>>>На котором куча доменов domain.ru, domain2.ru, domain3.ru, domain4.ru, domain5.ru
>>>И куча IP 1.1.1.1, 1.1.1.2, 1.1.1.3, причем IP меньше чем доменов.
>>>
>>>Как по твоему это все должно работать? ;)
>>
>>Работает же, и народ нежалуется qmail+vpopmail ;)
>
>Что значит работает же? Что должен говорить сервер в HELO? с какого
>IP должен слать почту? Какой должен быть обратный резолвинг у этого
>IP?

А несколько имен на 1 ип нормальное явление при хостинге, просто несколько записей А или CNAME в днс, только вот какая из них правильнее не помню, надо смотреть, и на них уже MX, в случае если это одна зона, а с разными зонами, указваем один и тот же ИП в каждой зоне...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру