Victor Ustugov wrote:
> Alexander Shikoff wrote:
>> On Fri, Nov 02, 2007 at 03:10:30PM +0200, Victor Ustugov wrote:
>>>> This is perhaps the most important of the MIME variables. It contains a
>>>> proposed filename for an attachment, if one was found in either the
>>>> Content-Type: or Content-Disposition: headers. The filename will be RFC2047
>>>> decoded, but no additional sanity checks are done. If no filename was found,
>>>> this variable contains the empty string.
>>>>>>>> Последняя фраза в этой цитате должна быть дополнена. Если не установлена
>>>> в false глобальная переменная check_rfc2047_length, то преобразование не
>>>> всегда будет работать.
>>> у меня работает декодирование при любом значении check_rfc2047_length
>>> а можно показать закодированное имя файла, при декодировании которого
>>> возникают проблемы?
>>> мне нужен именно фрагмент письма с именем аттача, закодированным
>>> согласно RFC 2231
>> Если убираю check_rfc2047_length, то в логе:
>> Nov 2 15:13:21 iota exim[52626]: 2007-11-02 15:13:21 1InwKu-000Dgo-MP H=(dragon.tsua.net) [212.40.34.13] Warning: This message contains attachment: =?koi8-u?Q?=F4=C5=D3=D4=20RFC2231=20=D7=20Exim=2E=20=C2=CC=C1-=C2=CC=C1-=C2=CC=C1=2Etar=2Egz?=
>> при ошибках декодирования надо будет оставлять недекодированный вариант.
> а тут получился преобразованный в quoted-printables
>>> С установленным в false check_rfc2047_length:
>> Nov 2 15:14:11 iota exim[52651]: 2007-11-02 15:14:11 1InwLi-000DhD-Bm H=(dragon.tsua.net) [212.40.34.13] Warning: This message contains attachment: Тест RFC2231 в Exim. бла-бла-бла.tar.gz
>>>> В хидерах оригинального письма:
>>>> Content-Type: application/octet-stream
>> Content-Disposition: attachment; filename*=koi8-u''%F4%C5%D3%D4%20RFC2231%20%D7%20Exim%2E%20%C2%CC%C1-%C2%CC%C1-%C2%CC%C1%2Etar%2Egz
>> Content-Transfer-Encoding: base64
>> я сегодня-завтра протестирую декодирование такого имени аттача и выложу
> исправленный вариант патча. как минимум можно игнорировать в нашем
> случае check_rfc2047_length, заменив использование
> expand_string(string_sprintf("${rfc2047d:%s}"... на выполнение
> rfc2047_decode с передачей ему в качестве второго параметра не значения
> check_rfc2047_length, а в явном виде false.
так и сделал. протестировать новый патч с этими заголовками:
Content-Type: application/octet-stream
Content-Disposition: attachment;
filename*=koi8-u''%F4%C5%D3%D4%20RFC2231%20%D7%20Exim%2E%20%C2%CC%C1-%C2%CC%C1-%C2%CC%C1%2Etar%2Egz
Content-Transfer-Encoding: base64
имя файла было корректно декодировано при обоих значениях
check_rfc2047_length - как true, так и false.
патч лежит на старом месте:
http://mta.org.ua/exim-4.67-conf/patches/exim-4.68-rfc2231/patch-src::rfc2231.patch
старый патч я пелеложил в соседний каталог
можно тестировать
--
Best wishes Victor Ustugov mailto:victor на corvax.kiev.ua
public GnuPG/PGP key: http://victor.corvax.kiev.ua/corvax.asc
ICQ: 77186900, 32418694 CRV2-RIPE, CRV-UANIC