Странно, вроде вошёл под своим логином... писАл долго, что ли...

http://www.protocols.ru/files/RFC/RFC-2821.pdf

[quote=lithium]http://www.protocols.ru/files/RFC/RFC-2821.pdf[/quote]
Я этот RFC и смотрел.

А с каким кодом отвергались твои входящие? По идее ты прав. на основе полей Receved отвергаться не должно. Проверку нужно проводить либо на валидность helo, либо на валидность mail from и их сочетании.

to vovan:
ну а в чем тогда проблема? "угадал все буквы, но не смог назвать слово"?

to Vitls:
а где в RFC написано, что значение HELO _должно_ соответствовать каким-то требованиям?

[quote=vovan]to Vitls: 554 5.7.1 Header Error
[/quote]
Читаем RFC-2821:
554 Transaction failed No SMTP service here
Админом код ошибки используется не по назначению.

Я например, 554 использую при отказе в приеме почты, проверив отправителя по черным спискаи, и даю отлуп в виде:
554 Service unavaiable: address blocked by dsbl.org
[ Редактирование Fri Apr 15 2005, 04:39PM ]

[quote=lithium]to vovan:
to Vitls:
а где в RFC написано, что значение HELO _должно_ соответствовать каким-то требованиям?[/quote]
Принимаюший сервер имеет право отвергнуть helo, если он не соответствует внутренним требованиям принимающей стороны.
Это один из методов отлова спам-сообщений, посылатели которых генерят кривой helo.

to Vitls:
Еще раз внимательно перечитал RFC и не нашел там таких слов... значение HELO / EHLO _должно_ присутствовать, все остальные случаи приравниваются к "я просто не захотел, чтобы пользователи моего домена получали от вас почту". Как ты думаешь, что скажет пользователь, не получивший нужное письмо?
Я знаю единственный случай, когда такое поведение оправданно -- когда сервер представляется твоим же собственным hostname. Все остальное -- под большим вопросом.
<span class='smallblacktext'>[ Редактирование Fri Apr 15 2005, 04:31PM ]</span>

[quote=lithium]to Vitls:
Еще раз внимательно перечитал RFC и не нашел там таких слов... значение HELO / EHLO _должно_ присутствовать
[/quote]

Вы не внимательно прочли тред. Речь идет о том, что если принимающая сторона отвергает почту. то отвергать должна не по полю Received, а например по helo.

to Vitls:
Да, действительно, перечитал RFC, помимо того, что немотивированно отвергают почту, ещё и код ошибки не соответствующий.
to lithium:
В принципе, по HELO отвергнуть можно:
If the HELO command argument is not acceptable a 501 failure reply must be returned and the SMTP must stay in the same state. (RFC821).

to Vitls:
Я внимательно все читаю. Если в качестве основания для "должна" вы пытаетесь использовать RFC, то там нет упоминания про это, HELO принимается в любом случае, если оно есть в наличии, вернее, строка после него? и если оно не нарушает других пунктов (см. ниже).

to vovan:
А ты не заметил, в каком параграфе идут эти слова? "Порядок команд". HELO может быть отвергнуто, если оно нарушает этот самый порядок.

Что касается фильтрации по доменному имени в HELO, то для тех, кто так и не потрудился почитать RFC, хотя упорно тут что-то доказывает:

An SMTP server MAY verify that the domain name parameter in the EHLO command actually corresponds to the IP address of the client. However, the server MUST NOT refuse to accept a message for this reason if the verification fails: the information about verification failure is for logging and tracing only.

Сами переведете?
<span class='smallblacktext'>[ Редактирование Fri Apr 15 2005, 11:58PM ]</span>

to Vitls: 554 5.7.1 Header Error

to lithium: Просто хотел убедиться в своей правоте

Если никаких мнений больше нет, я думаю, можго закрыть тему. Всем спасибо.

[quote=lithium]to Vitls:
Я внимательно все читаю. Если в качестве основания для "должна" вы пытаетесь использовать RFC, то там нет упоминания про это, HELO принимается в любом случае, если оно есть в наличии, вернее, строка после него? и если оно не нарушает других пунктов (см. ниже).
[/quote]
Вы неисправимы.
Речь шла о том, что письма отвергались принимающей стороной по полю Received. И уже сказали, что так нельзя. И нужно использовать другите методы. Разговор про helo был затронут в качестве примера.
P.s. в MTA postfix в управляющей директиве smtps_helo_restrictions есть параметры reject_invalid_hostname, reject_non_fqdn_hostname, reject_unknown_hostname к чему бы это?

[quote=lithium]
to vovan:
А ты не заметил, в каком параграфе идут эти слова? "Порядок команд". HELO может быть отвергнуто, если оно нарушает этот самый порядок.
[/quote]
Не, это в 4.1.1. COMMAND SEMANTICS
А ещё есть 4.3. SEQUENCING OF COMMANDS AND REPLIES, а там:

CONNECTION ESTABLISHMENT
S: 220
F: 421
HELO
S: 250
E: 500, 501, 504, 421

to Vitls:
> Речь шла о том, что письма отвергались принимающей стороной
> по полю Received. И уже сказали, что так нельзя. И нужно
> использовать другите методы. Разговор про helo был затронут
> в качестве примера.

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

to vovan:
я только сейчакс заметил, что Вы ссылаетесь на RFC821. Позволю себе обратить Ваше внимание, что этот документ датируется 1982 годом, а современная версия под номером 2821 -- 2001 годом. Может давайте будем обсуждать вопрос по современному состоянию стандарта, а не 23-х летней давности?..
И я еще раз повторяю, что HELO может быть отвергнуто только при нарушении RFC (порядока команд, синтаксис и пр.), но никак не по решению админа. Если он настраивает так свой MTA -- это исключительно его прихоть, и не надо ссылаться при этом на RFC.

Э... Алло, гараж! ГДЕ я ссылался на RFC? В каком месте? Не путайте мягкое с теплым.
Если уж ВЫ пошли на принцип, то ловите.
1. Ваша ссылка на пункт 4.1.4 просто не в тему. Там говорится о том, что сервер "может проверять соответствие доменного имени реальному IP-адресу, но недопустино отвергать сообщение по этой причине". Но мы-то говорили совсем о другом.
2. Вот теперь ссылаюсь я. Пункт 3.6: "доменное имя в команде ehlo должно быть первичным именем хоста либо дословным адресов в соответствии с п.4.1.11." Соответственно, если в команде ehlo это правило не выполянется, у меня есть все основания отвергнуть сообщение и выдать 504.

Хм... Я что-то упустил? Вроде эта тема была про RFC?
> Вот теперь ссылаюсь я. Пункт 3.6
Видите ли, Уважаемый, RFC -- это такая штука, которую нужно воспринимать буквально. Тут не подходят выдергивания фраз из контекста и произвольное трактование.
Вы, например, читали пункт 4.1.1.1, ссылку на который так неосторожно процитировали (да еще и с ошибочным номером)?
Там написано:

In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help to identify the client system.

А фразы "соответственно", "само собой разумется" не катят. Если написано "сервер ДОЛЖЕН отвергать HELO без FQDN, или с FQDN, котрое не может быть разрешено в MX, A, [...] запись", тогда да, отвергать можно, а предпринимать некие действия, основываясь на своих выводах на основе вырванных из контекста фраз и с произвольной трактовкой....

Да, уважаемый, Вы что-то пропустили.
1. Данный топик был поднял по вопросу (сюрприз-сюрприз!) отвергания сообщений по полю Received. И НЕ НАДО переводить стрелы на предмет HELO.
2. По существу этого вопроса (про поле Received) было дано исчерпывающее разъяснение, которое всех устроило и про которое все благополучно забыли.
3. Если Вы поняли о чем гласит пункт 4.1.1.1 говорит о том, то Вам должно быть ясно то, что внеи говорится о том, что сервер должен поддерживать командв HELO/EHLO а также формат запросов откликов. Пункт 3.6 даёт четкое определение доменных имен, передаваемых серверу, также в случае использования команды HELO, но НИГДЕ нет ответа на вопрос "что делать серверу, если в ему в HELO были переданы неверные данные"? Ответ очевиден - отреагировать ошибкой.
4. В любимом Вами пункте 4.1.4 говорится о том, что сервер должен в любом случае принять HELO/EHLO, а клиент в свою очередь должен передать серверу в этой коменде первичное имя или дословны адрес. Но опять же не рассмотрена ситуация, когда клиент в HELO/EHLO передаёт недопустимые значения.
4. RFC (Request For Comments) - это рекомендации как решить проблемные моменты, но это НЕ СТАНДАРТ уровня ISO.
Тема закрыта.