There is one overview page with one entry per month (currently the
longest thread, could also be an abbreviated list of threads, but not
all of the threads (or we are back where we started).The entries link to
the monthly pages which contain links to all threads with at least one
mail in that month.
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.
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