inline-attachments tag

Volker Krause volker at
Wed May 9 16:44:43 CEST 2007

On Thursday 26 October 2006 22:38:23 Bernhard Reiter wrote:
> On Tuesday 24 October 2006 20:41, Till Adam wrote:
> > I thought it would serve to distingiush "real" attachments, things the
> > user has associated explicitely with the object, from "internal" ones,
> I think that Joon proposes another MIME part header
> that indicates, if the attachment should be hidden.
> When peeking in RFC 2045 today I saw that there is already
> a designated field for the purpose of mime-parts refering to each other:
> > 7.  Content-ID Header Field
> >
> >    In constructing a high-level user agent, it may be desirable to allow
> >    one body to make reference to another.  Accordingly, bodies may be
> >    labelled using the "Content-ID" header field, which is syntactically
> >    identical to the "Message-ID" header field:
> >
> >      id := "Content-ID" ":" msg-id
> >
> >    Like the Message-ID values, Content-ID values must be generated to be
> >    world-unique.
> One alternative would be to make the Content-ID mandatory for our Kolab
> format emails and have <attachment> use the Content-ID for referal.

Was there any decision about this problem?

Kontact recently implemented inline attachments using the inline-attachments 
tag to distinguish "real" attachments from internal ones. Since this isn't 
done by toltec, we obviously run into interoperability problems here, see for the details.

So, how should inline attachments be handled correctly?


Volker Krause -- volker at, vkrause at
Klarälvdalens Datakonsult AB, Platform-independent software solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the format mailing list