A detached signature doesn't make much sense in an email, but may happen
because of improper quoting. Or somebody might really want to send a
signature separate from the signed file.
A structure like this is quite common:
─><no description> [multipa/related, 7bit, 12K]
├─><no description> [multipa/alternativ, 7bit, 9.0K]
│ ├─><no description> [text/plain, quoted, iso-8859-1, 3.7K]
│ └─><no description> [text/html, quoted, iso-8859-1, 4.9K]
└─>2b0063.jpg [image/jpeg, base64, 3.3K]
Here the main content of multipart/related isn't the html part, but a
multipart/alternative containing the html part and a text part. The html
part still needs access to the onther content of the multipart/related
part, so we need to pass this through.
For multipart related we need to be able to reference the other parts
from the root part by content-id, so we need to pass an argument with
the necessary information (imaginatively called "extra") to the render
function. Of course since this is called indirectly, every render
function needs to accept an extra argument, even if only
render_text_html uses it.
Not sure whether providing a download link for attached images is the
right thing to do - we should probably just display them like inline
images. But we can always change that by a simple change of the
template.
60em is a bit more than 100 characters in the fixed-width font I use so
that should be an acceptable compromise between readability and avoiding
unintended line breaks.
The RFC says that output should use "the maximum available margins", but
that was clearly before large monitors became common.
Nofill and param are handled specially by the parser. The parser now
also tolerates missing end tags.
Handle quite a few tags on output including some (like color and
fontfamily) that use a param.
Inline images are very similar to attachments: We just want to store
them somewhere and refer to them. But we want to use a different element
(<img> instead of <a>) or more generally, a different template. So we
pass the disposition as an additional argument to save_part and use it
to construct the template name - which gives as a flurry of new
templates.
Strange combination, but the first message with multipart/alternative
also contained a .scp file and not as an attachment.
The template for multipart/alternative allows switching between the
alternatives.
For now we just save them unmodified and give them an extension that
will cause the web server to provide the correct content-type. This is
probably *not safe*: A user could send malicious html as an attachment
and the browser will interpret it when another user clicks on the link.
We might try to sanitize attachments (but you would normally expect an
attachment to be preserved) or to preserve the content-dispostion header
(but I don't think this is possible with just a static archive).
Peter J. Holzer