Print an email from your mail client and look at the result: usually a "From / To / Date / Subject" summary at best. The routing history, Message-ID, original timezone and delivery chain are gone — which is fine for a recipe, and not fine for a record that has to prove what was sent, when, and from where.
This converter renders the complete header block on every PDF: sender, every recipient by role, the raw Date with its original timezone offset, and the Message-ID that ties the message to the rest of the mail system.
Every PDF opens with the header table: From (name + address), To, CC, Date exactly as written in the message (including the original UTC offset — no silent normalisation to your local time), Subject, and Message-ID. Batch exports repeat the same fields in index.csv, one row per message.
The fields that usually vanish elsewhere are the ones that matter for authentication: Message-ID links a message to its server-side trail; the timezone offset pins the send time to the sender's location; the To and CC lines show who else saw what. A PDF without them is a weaker record than the email it came from.
Internet email headers are defined by RFC 5322 (successor to RFC 822). "Full headers" as rendered here means the standard fields those RFCs define for origin, routing and content description — the same fields mail servers log and forensic examiners ask about. The parser reads them from the raw source, preserving original formatting and offsets rather than re-expressing them.
No — deliberately. The original Date header with its source timezone offset is preserved; normalising it would discard information.
The rendered header table covers the identity and content fields (From/To/CC/Date/Subject/Message-ID). Full transport traces are a natural extension for the legal tier.
Yes — MSG stores the same information as properties; the converter renders it in the identical header block, so EML and MSG PDFs are structurally uniform.