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

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

[Sergey]

Приветствую.

Что-то не смог у Postfx найти багтрекер. То ли лыжи не едут, то ли...
Хочу попробовать повесить баг, в чём-то прикольный... 

-- 
С уважением, Сергей
a_s_y@sama.ru

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

[Aleksey Novodvorsky]

2011/2/20 Sergey <a_s_y@sama.ru>:
> Приветствую.
>
> Что-то не смог у Postfx найти багтрекер. То ли лыжи не едут, то ли...
> Хочу попробовать повесить баг, в чём-то прикольный...

Спросите у ldv@. Или повесьте у нас, ldv@ перевесит куда надо.

Rgrds, Алексей

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

[Sergey]

On Sunday 20 February 2011, you wrote:

> > Что-то не смог у Postfx найти багтрекер. То ли лыжи не едут, то ли...
> > Хочу попробовать повесить баг, в чём-то прикольный...
> 
> Спросите у ldv@. Или повесьте у нас, ldv@ перевесит куда надо.
 
Баг - прикольный. Вы (ООО ALT Linux) тут тоже где-то замешаны, если я
Черепанова правильно понял. ;-)

Собственно, это напрямую касается ресурса gosuslugi.ru. Я вот только,
пока, не могу понять, как именно я хочу разрешить эту ситуацию...

Имеет место быть следующая ситуация. Ряд MTA, в том числе и Postfix,
игнорируют требование RFC 1652 в плане обработки параметра body=7bit
в mail from. Уж не знаю, это у них так по жизни, или где-то есть ручка.
Это позволяет почте от "Госуслуг" доходить до пользователей этих 
почтовых систем. Пользователи систем, где MTA работают в соответствии
с RFC 1652, в частности Sendmail, лишены этой "счастливой" возможности.
Вcё бы ничего, ситуация рабочая, бывает, но вот техподдержка, что
называется, доставляет. Это вот дословные цитаты:

***
*"Рекомендуем при регистрации на Портале ГУ не использовать корпоративный
*e-mail. Используйте известные общественные e-mail службы (gmail.com,
*mail.ru и.т.д)"
***

***
*"При работе с общедоступными доменами не возникает проблем с кодировкой
*писем."
***

Причём вторая была получена уже после того, как я описал, где проблема.
Там, правда, некоторая путаница с номерами тикетов вылезла, но нужную
информацию я в понедельник ещё отправил, можно было бы и разобраться
c за это время, где грабли.

И вот думаю, с какой стороны проблему решать. С одной стороны, надо бы
так, чтобы наши клиенты (да интернет-провайдер, и да, тут уже как-то 
антирекламой попахивает на госуровне) могли как можно быстрее перестать
испытывать проблемы, а, с другой, уже как-то техподдержку хочется
уму-разуму поучить.

Одна вот из идей - баги развесить по поводу соблюдения RFC 1652. И вот 
весь вечер по сайту Postfix лазию - тишина. В рассылках, что ли, пишут...

-- 
С уважением, Сергей
a_s_y@sama.ru

PS: кстати, потому и smoke-room@

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

[Sergey]

On Sunday 20 February 2011, Sergey wrote:

>  Пользователи систем, где MTA работают в соответствии с RFC 1652,
>  в частности Sendmail, лишены этой "счастливой" возможности. 

Если быть точным, они лишены возможности читать часть сообщений,
получать-то они получают...

-- 
С уважением, Сергей
a_s_y@sama.ru

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

[Aleksey Novodvorsky]

2011/2/20 Sergey <a_s_y@sama.ru>:
> On Sunday 20 February 2011, you wrote:
>
>> > Что-то не смог у Postfx найти багтрекер. То ли лыжи не едут, то ли...
>> > Хочу попробовать повесить баг, в чём-то прикольный...
>>
>> Спросите у ldv@. Или повесьте у нас, ldv@ перевесит куда надо.
>
> Баг - прикольный. Вы (ООО ALT Linux) тут тоже где-то замешаны, если я
> Черепанова правильно понял. ;-)
>
> Собственно, это напрямую касается ресурса gosuslugi.ru. Я вот только,
> пока, не могу понять, как именно я хочу разрешить эту ситуацию...
>
> Имеет место быть следующая ситуация. Ряд MTA, в том числе и Postfix,
> игнорируют требование RFC 1652 в плане обработки параметра body=7bit
> в mail from. Уж не знаю, это у них так по жизни, или где-то есть ручка.
> Это позволяет почте от "Госуслуг" доходить до пользователей этих
> почтовых систем. Пользователи систем, где MTA работают в соответствии
> с RFC 1652, в частности Sendmail, лишены этой "счастливой" возможности.
> Вcё бы ничего, ситуация рабочая, бывает, но вот техподдержка, что
> называется, доставляет. Это вот дословные цитаты:
>
> ***
> *"Рекомендуем при регистрации на Портале ГУ не использовать корпоративный
> *e-mail. Используйте известные общественные e-mail службы (gmail.com,
> *mail.ru и.т.д)"
> ***
>
> ***
> *"При работе с общедоступными доменами не возникает проблем с кодировкой
> *писем."
> ***
>
> Причём вторая была получена уже после того, как я описал, где проблема.
> Там, правда, некоторая путаница с номерами тикетов вылезла, но нужную
> информацию я в понедельник ещё отправил, можно было бы и разобраться
> c за это время, где грабли.
>
> И вот думаю, с какой стороны проблему решать. С одной стороны, надо бы
> так, чтобы наши клиенты (да интернет-провайдер, и да, тут уже как-то
> антирекламой попахивает на госуровне) могли как можно быстрее перестать
> испытывать проблемы, а, с другой, уже как-то техподдержку хочется
> уму-разуму поучить.
>
> Одна вот из идей - баги развесить по поводу соблюдения RFC 1652. И вот
> весь вечер по сайту Postfix лазию - тишина. В рассылках, что ли, пишут...
>

Это бага разработчиков портала госуслуг. Мы им передали.

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

[Sergey]

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.

Postfix же бит в ноль не сбрасывает, что есть ошибка. Так что, в теории,
надо чинить. :-)

> Мы им передали. 

За это - отдельное спасибо, но это не решает проблему с непробиваемостю
техподдержки "Госуслуг", это раз, а два, возможно и не разработчики
портала крайние. Если бы на mail.gosuslugi.ru стоял, например, Sendmail,
всё бы было хорошо, но там стоит Microsoft ESMTP MAIL Service, который,
в нарушение тех же RFC, предеёт принимающему серверу и BODY=7BIT, и
некодированный текст в utf8. Если я Черепанова правильно понял, то за
портал и за почтовый сервер отвечают разные люди, как бы там футбор не
начался между Ростелекомом и разработчиками портала...

И исправление бага в Postfix - это как стимул партию завершить быстрее.
Хотя это совсем долговременное решение - это же ещё и апдейта надо 
дождаться у тех, кто его использует. Плюс я ещё не уверен, что у тех же
mail.ru и Google именно Postfix.

-- 
С уважением, Сергей
a_s_y@sama.ru

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

[Aleksey Novodvorsky]

2011/2/20 Sergey <a_s_y@sama.ru>:
> 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.
>
> Postfix же бит в ноль не сбрасывает, что есть ошибка. Так что, в теории,
> надо чинить. :-)
>
>> Мы им передали.
>
> За это - отдельное спасибо, но это не решает проблему с непробиваемостю
> техподдержки "Госуслуг", это раз, а два, возможно и не разработчики
> портала крайние. Если бы на mail.gosuslugi.ru стоял, например, Sendmail,
> всё бы было хорошо, но там стоит Microsoft ESMTP MAIL Service, который,
> в нарушение тех же RFC, предеёт принимающему серверу и BODY=7BIT, и
> некодированный текст в utf8. Если я Черепанова правильно понял, то за
> портал и за почтовый сервер отвечают разные люди,

Да.
А за площадку, на которой размещен портал, -- третьи.

> как бы там футбор не
> начался между Ростелекомом и разработчиками портала...

Он не прекращался.

Rgrds, Алексей

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

[Sergey]

On Sunday 20 February 2011, Sergey wrote:

> футбор

"футбол" то есть... 

-- 
С уважением, Сергей
a_s_y@sama.ru

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

[Sergey]

On Sunday 20 February 2011, you wrote:

> > как бы там футбол не начался между Ростелекомом и разработчиками
> > портала... 
> 
> Он не прекращался.
 
Тогда лучше Postfix чинить, на всякий случай. :-)

-- 
С уважением, Сергей
a_s_y@sama.ru

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

[Sergey Vlasov]

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

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

[Sergey]

On Monday 21 February 2011, Sergey Vlasov wrote:

> >          stream, the 7-bit ASCII codes are transmitted right justified
> >          in the octets with the high order bits cleared to zero.
> 
> На самом деле это требование относится к передающей стороне, где и
> находится настоящая ошибка. Про поведение принимающей стороны в старом
> RFC 821 ничего явно не сказано;

Вообще да, про передающую сторону сказано. Что-то я на transmitted внимания
не обратил.

> а вот в RFC 2821 уже написано: 

RFC 1652 на 2821 не ссылается, а обновления для 1652 нет вроде как.
Жаль, весёлый мог бы вариант получиться в перспективе...

-- 
С уважением, Сергей
a_s_y@sama.ru

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

[Sergey]

On Monday 21 February 2011, Sergey Vlasov wrote:

> >          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 ничего явно не сказано;

Стоп. В 821 есть другое место. В первый раз мне оно попалось, а не то,
что я тут процетировал ранее:

   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.

То есть, не важно где, он просто сбрасывается. Тут не говорится ни про
передающую, ни про принимающую сторону. Так что, всё же, ошибка, с учётом
того, что 1652 ссылается только на 821. :-)

Хотя, конечно и скорее всего, при попытке повесить баг будет та ссылка на
2821 или 5321 (там то же самое).

-- 
С уважением, Сергей
a_s_y@sama.ru