AS2 filenames - incoming and outgoing

Files that arrive over AS2 sometimes carry a name that looks nothing like a file - a long random identifier such as 4765443f-dae5-4ab6-9547-48f29bb3a61f, with no extension. That name then follows the file through the channel and onto whatever the channel delivers to: an SFTP folder, an email attachment, a bucket. This guide explains where the name comes from, and what DocEvent does with filenames in both directions.

AS2 has no filename of its own

An AS2 transfer is a message, not a file transfer. The protocol (RFC 4130) wraps the business document in a MIME body, signs and encrypts it, and identifies the message by its Message-ID. Nothing in the protocol requires the sender to name the document.

The only place a name can travel is an optional MIME header on the payload:

Content-Disposition: attachment; filename="INVOICE-2026-09-27.edi"

Whether that header is present, and what it contains, is entirely up to the sending software. In practice partners fall into three groups:

• They send a real filename. Most gateways configured to send a file from a folder put the file's name in the header. This is the case that "just works".
• They send a generated identifier. Many EDI platforms treat the payload as a message rather than a file and fill the header with an internal id - typically a UUID, sometimes a message number. This is where the 4765443f-… style name comes from. It is the partner's id for the message, not anything DocEvent created.
• They send no name at all. Some senders omit the header entirely and expect the receiver to identify the document from its content (for EDI, from the interchange envelope).

If you see identifier-style names on files from a partner, it is not a fault on either side - it is how their gateway is configured. Only the partner can change it.

Incoming: what DocEvent names a received file

When a message arrives at your AS2 receive endpoint, DocEvent decides the filename in this order:

1. The partner's Content-Disposition filename, if there is one. DocEvent keeps it as sent, apart from the safety clean-up below.
2. Otherwise, the message's Message-ID, with .dat appended. Letters, digits, -, _ and . are kept and every other character (including the @) becomes _ - so <12345678-abcd@partner.example> is stored as 12345678-abcd_partner.example.dat. This keeps every message uniquely and traceably named even when the partner sends nothing.

The clean-up applied to a partner-supplied name:

• Only the base name is kept. Any directory part (/ or \) is removed, so a partner can never steer a file into a different folder at your destination.
• Control characters are stripped, and the name is capped at 255 characters.
• Nothing else is changed - the extension, case and spacing are preserved exactly, and DocEvent never renames a file to its own identifier.

The routing log for the file shows this filename on the receive stage, and every destination in the channel receives the file under that name: an SFTP or FTP push writes <directory>/<filename>, an email destination attaches the file under that name, a bucket destination uses it as the object name.

The filename is not the file's DocEvent id. Every routed file also has a DocEvent guid, shown in the routing log and used to track the file through the pipeline. For AS2 the guid is derived from the receive endpoint and the partner's Message-ID, so the same message always maps to the same guid. The guid and the filename are different values, even when the partner's name happens to look like a UUID too.

Outgoing: what your partner sees when DocEvent sends

When a channel delivers a file to an AS2 send endpoint, DocEvent always sets the filename header:

Content-Disposition: attachment; filename="<the routed file's name>"

The name is the file's name as it entered the channel - the name it was uploaded with, or the name DocEvent assigned on receipt as described above. A partner whose gateway honours Content-Disposition therefore receives the file under the same name you sent it.

Two related headers are also set on every outbound message:

• Subject - the Message subject configured on the send endpoint, or, when that is left blank, DocEvent file <filename>.
• Message-ID - a DocEvent-generated id that is fixed per file per endpoint. A retry of the same file (a redelivery, or a reprocess from Stuck files) carries the same Message-ID, so a partner that implements AS2 duplicate detection ignores the repeat instead of ingesting the document twice. The Message-ID is not derived from the filename and does not change if the file is renamed upstream.

Whether the partner uses the filename is up to their software. Some gateways ignore the header and store every message under their own id, in which case the name you sent is visible only in the message headers.

Common questions

A partner's files all arrive as UUIDs. Can DocEvent rename them? Not today - channels deliver files under the name they were received with. Ask the partner to send the document's real name in the Content-Disposition header; every mainstream AS2 gateway has a setting for this. The document itself is unaffected: an EDI interchange is fully identified by its own envelope regardless of the filename.

A file arrived as <something>.dat. What happened? The partner sent no Content-Disposition filename, so DocEvent named the file after the message's Message-ID. The content is intact.

Two files from a partner have the same name. Are they the same file? Not necessarily - a filename is not an identifier in AS2. Compare the Message-ID and the DocEvent guid in the routing log. If the partner reuses a Message-ID for a different document, DocEvent records that on the routing log ("The same Message-ID was first used by …") so you can raise it with them.

Does the filename affect signing, encryption or the MDN? No. The MIC (the integrity hash the receipt confirms) is computed over the payload part including its headers, so changing the name changes the MIC of that message, but the name plays no part in verification, encryption or duplicate detection.

Related guides

• Channel static IP addresses - the addresses a partner must allow for outbound AS2 messages and MDNs
• AS2 channels - product overview