From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 21 Feb 2011 00:25:37 +0300 From: Sergey Vlasov To: smoke-room@lists.altlinux.org Message-ID: <20110221002537.26817c28@atlas.home> In-Reply-To: <201102202243.50829.a_s_y@sama.ru> References: <201102202009.38611.a_s_y@sama.ru> <201102202132.49569.a_s_y@sama.ru> <201102202243.50829.a_s_y@sama.ru> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.24.0; x86_64-alt-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Subject: Re: [room] =?koi8-r?b?UG9zdGZpeCDJIMLBx9TSxcvF0g==?= X-BeenThere: smoke-room@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: =?koi8-r?b?69XM2NTV0s7ZyiDPxtTP0MnL?= List-Id: =?koi8-r?b?69XM2NTV0s7ZyiDPxtTP0MnL?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 21:25:36 -0000 Archived-At: List-Archive: On Sun, 20 Feb 2011 22:43:49 +0300 Sergey wrote: > On Sunday 20 February 2011, you wrote: > > > > Одна вот из идей - баги развесить по поводу соблюдения RFC 1652. И вот > > > весь вечер по сайту Postfix лазию - тишина. В рассылках, что ли, пишут... > > > > Это бага разработчиков портала госуслуг. > > Не только. Допустить эту багу им позволила именно плохая поддержка RFC 1652 > рядом MTA. Иначе они на неё бы сразу наступили. В RFC 1652 написано конкретно: > > (4) one optional parameter using the keyword BODY is added to > the MAIL FROM command. The value associated with this > parameter is a keyword indicating whether a 7bit message > (in strict compliance with [1]) or a MIME message (in > strict compliance with [3]) with arbitrary octet content > is being sent. > > [1] - это > > [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, > USC/Information Sciences Institute, August 1982. > > А там написано не менее конкретно: > > The mail data may contain any of the 128 ASCII characters. All > characters are to be delivered to the recipient's mailbox > including format effectors and other control characters. If > the transmission channel provides an 8-bit byte (octets) data > stream, the 7-bit ASCII codes are transmitted right justified > in the octets with the high order bits cleared to zero. На самом деле это требование относится к передающей стороне, где и находится настоящая ошибка. Про поведение принимающей стороны в старом RFC 821 ничего явно не сказано; а вот в RFC 2821 уже написано: Commands and replies are composed of characters from the ASCII character set [1]. When the transport service provides an 8-bit byte (octet) transmission channel, each 7-bit character is transmitted right justified in an octet with the high order bit cleared to zero. More specifically, the unextended SMTP service provides seven bit transport only. An originating SMTP client which has not successfully negotiated an appropriate extension with a particular server MUST NOT transmit messages with information in the high-order bit of octets. If such messages are transmitted in violation of this rule, receiving SMTP servers MAY clear the high-order bit or reject the message as invalid. In general, a relay SMTP SHOULD assume that the message content it has received is valid and, assuming that the envelope permits doing so, relay it without inspecting that content. Of course, if the content is mislabeled and the data path cannot accept the actual content, this may result in ultimate delivery of a severely garbled message to the recipient. Delivery SMTP systems MAY reject ("bounce") such messages rather than deliver them. No sending SMTP system is permitted to send envelope commands in any character set other than US-ASCII; receiving systems SHOULD reject such commands, normally using "500 syntax error - invalid character" replies. > Postfix же бит в ноль не сбрасывает, что есть ошибка. Так что, в теории, > надо чинить. :-) По букве RFC - не ошибка, поскольку написано MAY; более того, в качестве предпочтительного (SHOULD) предлагается как раз поведение Postfix - принимать и обрабатывать сообщение в том виде, в котором его передали, не обращая внимания на нарушение 7-битности. Объявлять такое поведение багом, скорее всего, бесполезно - вряд ли кто-то будет делать изменения, ухудшающие совместимость Postfix с реально встречающимися серверами. Впрочем, текущее поведение Sendmail (принудительный сброс старшего бита) этим MAY тоже разрешено.