Re: [room] Postfix и багтрекер

[Sergey Vlasov <vsu@altlinux.ru>]

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 тоже разрешено.