Re: [room] Postfix и багтрекер
2011/2/20 Sergey a_...@sama.ru: Приветствую. Что-то не смог у Postfx найти багтрекер. То ли лыжи не едут, то ли... Хочу попробовать повесить баг, в чём-то прикольный... Спросите у ldv@. Или повесьте у нас, ldv@ перевесит куда надо. Rgrds, Алексей ___ smoke-room mailing list smoke-room@lists.altlinux.org https://lists.altlinux.org/mailman/listinfo/smoke-room
Re: [room] Postfix и багтрекер
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_...@sama.ru PS: кстати, потому и smoke-room@ ___ smoke-room mailing list smoke-room@lists.altlinux.org https://lists.altlinux.org/mailman/listinfo/smoke-room
Re: [room] Postfix и багтрекер
On Sunday 20 February 2011, Sergey wrote: Пользователи систем, где MTA работают в соответствии с RFC 1652, в частности Sendmail, лишены этой счастливой возможности. Если быть точным, они лишены возможности читать часть сообщений, получать-то они получают... -- С уважением, Сергей a_...@sama.ru ___ smoke-room mailing list smoke-room@lists.altlinux.org https://lists.altlinux.org/mailman/listinfo/smoke-room
Re: [room] Postfix и багтрекер
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_...@sama.ru ___ smoke-room mailing list smoke-room@lists.altlinux.org https://lists.altlinux.org/mailman/listinfo/smoke-room
Re: [room] Postfix и багтрекер
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_...@sama.ru ___ smoke-room mailing list smoke-room@lists.altlinux.org https://lists.altlinux.org/mailman/listinfo/smoke-room
