Есть проблема, вот только не пойму баг это или фича, кто-нибудь с этим сталкивался?Есть заголовок оформленный по rfc 2045:
=?windows-1251?B?x+Dj7uvu4u7qIO/o8fzs4Cwg7vTu8Ozr5e3t++kg7+4gUkNGIDIwNA==?=
=?windows-1251?B?NSDoIPDg4e7y4P756Okg7eUg7/Dg4ujr/O3u?=Строка разбивается на две следующей последовательностью символов:
\r\n\t
qmail-pop3d при разборе строки делает следующее:
void blast(ssfrom,limit)
substdio *ssfrom;
unsigned long limit;
{
int match;
int inheaders = 1;for (;;) {
if (getln(ssfrom,&line,&match,'\n') != 0) die();
if (!match && !line.len) break;
if (match) --line.len; /* no way to pass this info over POP */
if (limit) if (!inheaders) if (!--limit) break;
if (!line.len)
inheaders = 0;
else
if (line.s[0] == '.')
put(".",1);
put(line.s,line.len);
put("\r\n",2);
if (!match) break;
}
put("\r\n.\r\n",5);
flush();
}То есть доходит до '\n', удаляет его и вставляет '\r\n'.
В конце концов получается следующая абракадабра:'\r\r\n\t' - что сносит голову почтовым клиентам.
Кто-нибудь лечил подобное поведение qmail-pop3d?
>Есть заголовок оформленный по rfc 2045:
В смысле rfc2047 ?>
>=?windows-1251?B?x+Dj7uvu4u7qIO/o8fzs4Cwg7vTu8Ozr5e3t++kg7+4gUkNGIDIwNA==?=
> =?windows-1251?B?NSDoIPDg4e7y4P756Okg7eUg7/Dg4ujr/O3u?=
>
>Строка разбивается на две следующей последовательностью символов:
>
>\r\n\t
>
>qmail-pop3d при разборе строки делает следующее:
>
>То есть доходит до '\n', удаляет его и вставляет '\r\n'.
>В конце концов получается следующая абракадабра:
>
>'\r\r\n\t' - что сносит голову почтовым клиентам.Может быть дело в том, что
An 'encoded-word' may not be more than 75 characters long, including
'charset', 'encoding', 'encoded-text', and delimiters. If it is
desirable to encode more text than will fit in an 'encoded-word' of
75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may
be used.
While there is no limit to the length of a multiple-line header
field, each line of a header field that contains one or more
'encoded-word's is limited to 76 characters.
?
>>Есть заголовок оформленный по rfc 2045:
>В смысле rfc2047 ?Ну они в одной куче.
>>
>>=?windows-1251?B?x+Dj7uvu4u7qIO/o8fzs4Cwg7vTu8Ozr5e3t++kg7+4gUkNGIDIwNA==?=
>> =?windows-1251?B?NSDoIPDg4e7y4P756Okg7eUg7/Dg4ujr/O3u?=
>>
>>Строка разбивается на две следующей последовательностью символов:
>>
>>\r\n\t
>>
>>qmail-pop3d при разборе строки делает следующее:
>>
>>То есть доходит до '\n', удаляет его и вставляет '\r\n'.
>>В конце концов получается следующая абракадабра:
>>
>>'\r\r\n\t' - что сносит голову почтовым клиентам.
>
>Может быть дело в том, что
> An 'encoded-word' may not be more than 75 characters
>long, including
> 'charset', 'encoding', 'encoded-text', and delimiters. If it is
>
> desirable to encode more text than will fit in
>an 'encoded-word' of
> 75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may
>
> be used.
> While there is no limit to the length of
>a multiple-line header
> field, each line of a header field that contains
>one or more
> 'encoded-word's is limited to 76 characters.
>?Тут у меня возникли труднсоти перевода: separated by CRLF SPACE - разделеный CRLF или все же CRLF и SPACE ( пробел, табуляция )...
>Тут у меня возникли труднсоти перевода: separated by CRLF SPACE - разделеный
>CRLF или все же CRLF и SPACE ( пробел, табуляция )...
>
Похоже, что имеется ввиду CRLF И SPACE
Потому что ниже по тексту есть ещё
6.1. Recognition of 'encoded-word's in message headers
A mail reader must parse the message and body part headers according
to the rules in RFC 822 to correctly recognize 'encoded-word's.'encoded-word's are to be recognized as follows:
(1) Any message or body part header field defined as '*text', or any
user-defined header field, should be parsed as follows: Beginning
at the start of the field-body and immediately following each
occurrence of 'linear-white-space', ...Я посмотрел - разные клиенты используют разные разделители:
mozilla - OA 20, bat - 0A 09,
то есть только LF без CR с последующим пробелом или табуляцией.
Тогда, даже если в словах по 75 символов, всё работает.
Хотя, по смыслу RFC, должно бы работать и с CRLF.
>>Тут у меня возникли труднсоти перевода: separated by CRLF SPACE - разделеный
>>CRLF или все же CRLF и SPACE ( пробел, табуляция )...
>>
>Похоже, что имеется ввиду CRLF И SPACE
>Потому что ниже по тексту есть ещё
>6.1. Recognition of 'encoded-word's in message headers
> A mail reader must parse the message and body
>part headers according
> to the rules in RFC 822 to correctly recognize
>'encoded-word's.
>
> 'encoded-word's are to be recognized as follows:
> (1) Any message or body part header field defined
>as '*text', or any
> user-defined header field, should be
>parsed as follows: Beginning
> at the start of the
>field-body and immediately following each
> occurrence of 'linear-white-space', ...
>
>Я посмотрел - разные клиенты используют разные разделители:
>mozilla - OA 20, bat - 0A 09,
>то есть только LF без CR с последующим пробелом или табуляцией.
>Тогда, даже если в словах по 75 символов, всё работает.
>Хотя, по смыслу RFC, должно бы работать и с CRLF.Да, все в принципе верно, но qmail-pop3d убирает \n и добавляет \r\n - зачем он это делает - не ясно :-)