We now send our S/MIME encypted messages as Content-Disposition 'inline'.



I have convinced myself that it does make a lot of sense to view 
received S/MIME encrypted messages with dispositon 'attachment' 
inline.  However, this would require a bit of an API change in 
MIME_Viewer and MIME_Contents (basically allowing an individual 
MIME_Viewer to override a given Content-Disposition) and since we are 
in a featrure freeze, this will have to wait until after we release 
the stable versions.  I have put this into the horde/docs/TODO file.

No.  RFC 2183 allows the user agent to choose what the default should 
be if no Content-Disposition is defined - We have chosen 'attachment' 
for a variety of reasons.  *Never* honoring the Content-Disposition 
header, as your patch suggests, is incompatible with RFC 2183.  If the 
user wants us to display a MIME part as an attachment, there is no 
reason we should go against their wishes.



A correct fix may be to look at our S/MIME implementation and 
determine if it is desirable to send as 'inline' instead of 
'attachment'.

As generated by Outlook and IMP, an S/MIME message's 
Content-Disposition is attachment. As such, 
framework/MIME/MIME/Contents.php::canDisplayInline() currently 
disallows any possibility of such a message being displayed inline.



Content-Disposition is advisory anyway. Suggest not relying on it to 
determine inline-ability, e.g.:



Index: framework/MIME/MIME/Contents.php

===================================================================

RCS file: /repository/framework/MIME/MIME/Contents.php,v

retrieving revision 1.128

diff -r1.128 Contents.php

415,421c415

<         /* First check: The MIME headers allow the part to be inlined. */

<         if ($mime_part->getDisposition() != 'inline') {

<             return false;

<         }

<

<         /* Second check (save the most expensive for last):

<          * Check to see if the driver is set to inline. */

---