Summary

  • RFC 5259 requires the message-store original to remain unaltered while a server returns a requested or server-selected derivative; usability of that derivative does not prove byte fidelity, signature authenticity or durable replacement.
  • A tagged OK can accompany partial conversion failures, and a default conversion can remove detail or replace unrepresentable characters, so evidence must be kept per item and per output rather than inferred from command completion.

The document looked right after its proof stopped applying

A director opened a contract attachment on a phone. The mail server had converted the source into a format the device could display, reduced the image detail and returned a clean, readable result. The director saw the familiar layout and the signature mark and approved the next step.

The original document may have been properly signed. The converted output was not thereby authenticated. RFC 5259 says this explicitly: after server-side conversion of a signed body part, the client has no way to verify that the converted content is authentic using that signature. A client that does not trust the server must download the signed object, verify it and perform the conversion itself.

That is not a complaint about conversion. It is the boundary that makes conversion safe to use honestly. A derivative can solve a display problem without inheriting every property of its source. When an organization collapses those layers, convenience quietly becomes authority.

The stored message and the returned representation are different objects

RFC 5259 requires conversions to affect only what is sent to the client. The original data in the message store must not be altered. This preserves access for other clients, original material for replies and forwards, the stored BODYSTRUCTURE and the source needed for signature verification.

The rule creates two parallel realities. One is the stored body part, identified by its mailbox context, UID and original bytes. The other is an execution result produced for a request. The second may have a different MIME type, structure, encoding, dimensions, character repertoire and size.

An archive that saves only the derivative has not proved that the original changed. A client that displays only the derivative has not proved that the source was unusable. A workflow that calls the derivative “the attachment” erases the most important noun in the transaction: conversion.

Capability discovery is not an execution receipt

A server advertises CONVERT together with BINARY. The CONVERSIONS command can ask which source and target MIME pairs are supported and which parameters are available. AVAILABLECONVERSIONS can inspect target types for a particular body part.

Those answers describe a capability surface. They do not prove that a later operation used the same transcoder revision, had enough resources, honored every parameter or returned content that the client could render. An advertised route from one format to another is not a hash of the resulting bytes.

The server may return no matching CONVERSION response for a requested pair. A concrete request may later fail temporarily because a transcoding service is down, or permanently because the format or parameters cannot be handled. Inventory and execution need separate timestamps and receipts.

Default conversion delegates a policy decision

A client can name the target media type or pass NIL and ask the server to choose. Default conversion is required, but the RFC does not fully specify how a server selects the result. It may rely on device characteristics, user preferences, administrator preferences, server configuration or its view of widely deployed formats.

The server may also remove detail that exceeds device capabilities unless a parameter says otherwise. Scaling an image to a screen is an obvious example. In the absence of reliable capability information, it should minimize quality loss, but “should minimize” is not a lossless-output guarantee.

The client is warned not to use default conversion casually because the server may guess its capabilities incorrectly. This is an agency transfer: the client delegates not merely computation, but selection of the representation that the human will see. The receipt must therefore name the chosen target and the policy inputs that chose it.

Successful transcoding can contain deliberate loss

Text conversion needs a target charset. When a source contains characters that charset cannot represent, the unknown-character-replacement parameter can supply replacement text. The resulting body may be valid and useful while specific information has been replaced.

Encoded words in headers and MIME parameters add further representation boundaries. A decoded and re-encoded header can preserve intended text without preserving its source octets. Conversely, a visually plausible replacement can conceal that a name, amount, symbol or identifier was not carried through exactly.

The same caution applies to partial retrieval. Byte ranges in partial CONVERT BINARY refer to transcoded and decoded section data, not offsets in the original stored part. A derivative offset cannot be cited as an original-byte coordinate.

Fidelity is therefore not a single checkbox. Operators should distinguish exact bytes, decoded meaning, layout, dimensions, omitted detail, replacement events and application behavior.

Command completion can hide item failure

RFC 5259 returns structured CONVERTED responses. Requested data items can carry errors such as TEMPFAIL, BADPARAMETERS or MISSINGPARAMETERS. The protocol also permits a command to contain several parts or response items.

If at least one conversion succeeds, the tagged result must be OK. If every conversion fails, the server may still return either OK or NO. The command status is therefore not a complete success count. The specification's own example ends with an OK that says some conversions failed.

A green command badge that ignores the untagged item results changes the meaning of the exchange. One body part may have converted while another did not; structure may be available while bytes are not. The consumer must reconcile every requested item with every returned item and error.

BODYPARTSTRUCTURE usually reveals whether the request was honored exactly, although the client may not know every reason. That makes it evidence, not an assurance label. Store it with the selected target, parameters and output hash.

Retrieval does not create read state or canonical state

Unlike FETCH behavior that may affect message flags in other circumstances, CONVERT never sets \Seen. A client wishing to mark the message as seen needs a separate STORE. The existence of converted bytes proves neither that a reader viewed them nor that mailbox read state changed.

Servers may cache converted body parts for efficiency, and the RFC recommends limits to reduce denial-of-service exposure. Such a cache is execution state. It is not a canonical alternate attachment, an archival commitment or a guarantee that a later identical request will yield identical bytes.

Reproducibility requires more than repeating the syntax. The transcoder version, server policy, external service, fonts, codecs, parameters and capability knowledge can change. If institutional action depends on the derivative, preserve the actual output and its execution context.

The transcoder is a security principal

Conversion expands the attack surface. A crafted APPEND followed by CONVERT can target a vulnerable parser or codec. An extreme resize request can consume server resources. A dangerous conversion could produce executable content. RFC 5259 recommends avoiding dangerous or CPU-expensive conversions, checking output where possible, logging authenticated identities and isolating conversion code from the privileged mailstore.

An external transcoding server adds another custody hop. Keeping it within the same trusted domain reduces exposure but does not make the hop disappear. The organization should record which service received the source, what it returned and which security boundary contained it.

Trusting the IMAP server's identity over SASL or TLS is necessary transport hygiene. It does not make a transformed signed document verifiable under the source signature. Server authentication and content authenticity answer different questions.

Preserve a source-to-derivative receipt

For a consequential conversion, retain mailbox, UIDVALIDITY and UID; source body-part identifier, MIME structure, size and hash; requested source and target types; every parameter; whether the target was explicit or default; declared device capabilities; user, administrator and server policy inputs; server and transcoder revision; and the time and security domain of execution.

Then retain every CONVERTED item, error and tagged result; output MIME structure, size and hash; removed detail and replacement characters; cache disposition; source-signature verification and the derivative's lack of inherited verification; parser/display result; \Seen state; and the downstream action that consumed the output.

Describe the claim narrowly. “This server returned these derivative bytes for this request” is testable. “This is the signed attachment” is not, unless a new authentication mechanism covers the derivative. “The conversion succeeded” is incomplete until each requested item has a result.

RFC 5259 gave constrained clients a valuable adaptation layer. Leadership preserves that value by refusing to let an accessible representation impersonate the authenticated source from which it was made.

Sources