ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Maxim Timofeyev                      2:5030/1763.1  09 Jan 2003  14:17:03
 To : Artem Chuprina
 Subject : Re: GPG/PGP & KMail, Sylpheed, mutt, The Bat!
 -------------------------------------------------------------------------------- 
 

 AC> Правильнее - те, кто соответствует стандарту. То есть Sylpheed и mutt.
 
 Hо KMail и TheBat! также соответствуют стандарту. Какой из стандартов
 более правилен или какой -- новее? Можно ли научить Sylpheed & mutt
 поддеживать проверку подписи для обоих стандартов? Hапример в багтраке
 примерно поровну писем подписанных по обоим стандартам.
 
 AC> То, как поступают bat и kmail, не имеет отношения к стандарту на подпись
 AC> писем - это просто вложение файла, состоящего из тела сообщения и
 AC> plaintext подписи, как письма.
 
 Hу мне приводили стандарты и для того и для другого варианта.
 Сейчас попробую выдать:
 
 From: Alexey I. Froloff <Alexey_I._Froloff@p4.f1437.n5020.z2.fidonet.net>
 Subject: GPG/PGP & KMail, Sylpheed, mutt, The Bat!
 Newsgroups: fido7.spb.linux
 
 [ ... skip ... ]
 
  MT> Кто поступает правильнее?
 
     Sylpheed/mutt работают по RFC-1847 (это кстати не аттач, а multipart/signed 
 MIME message), The Bat!/Kmail -
 RFC-2440 (ascii armored, IDEA кстати там тоже упоминается). Sylpheed/mutt
 однозначно правы, в случае The Bat!/Kmail
 надо смотреть на content-type, потому как согласно RFC-3156:
 
    Multipart/signed and multipart/encrypted are to be treated by agents
    as opaque, meaning that the data is not to be altered in any way [2],
    [7]. --skipped--
 
    [2]   Galvin, J., Murphy, G., Crocker, S. and N. Freed, "Security
          Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
          RFC 1847, October 1995.
 
    [7]   Freed, N., "Gateways and MIME Security Multiparts", RFC 2480,
          January 1999.
 
 [ ... skip ... ]
 AC> Вообще говоря, там возможно, хотя и малореальны, засады с тем, что для
 AC> 8bit возможны (допустимы MIME-стандартами) транзитные перекодировки или,
 AC> что более реально, автоматическое заворачивание в QP/Base64, с потерей
 AC> информации об оригинальном кодировании, и подпись этого не переживет.
 
 Я об этом тоже подумал, но не проверить.
 
 -- 
 0BDE AC68 5418 B40A 0C85 C081 037A 6542 55F6 ADEC
 [2:5030/1763@fidonet.org][tmahome@tma.spb.ru][http://tma.spb.ru]
 --- tin/1.5.10-20011117 ("Darkcell") (UNIX) (Linux/2.4.18-alt6master-up (i686))
  * Origin: TMA at HOME (2:5030/1763.1)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор