Batch-download Email Attachments and Unpack Them Locally with UnpackFlow

Use this workflow only after the attachment safety checklist says the files are expected and appropriate to handle. Once Email receives attachment bytes and provides downloads, but it does not preview or unpack files, inspect archive contents, upload them to an online unpacking service, execute included programs or certify them as malware-free.

UnpackFlow 2.1.2 performs the archive work on your own Windows, macOS or Linux device. Its public source is available, but there is currently no tagged GitHub Release with downloadable platform assets. Do not follow an unofficial “latest release” link; use the installation path that the current official source or installed Codex plugin actually provides.

1. Download into a new dedicated folder

Create one empty folder for this message or batch. Do not point a recursive tool at your entire Downloads directory. In the message detail, download each attachment or use Download all. Browsers can block multiple automatic downloads and can rename duplicate filenames, so read the per-file result and check the folder itself.

“Bytes received; browser save triggered” means Once Email finished the HTTP response and asked the browser to save it. It does not prove that the browser completed a durable write. Confirm every expected file, size and multipart name before continuing. Keep sample.part1.rar with later parts and .7z.001 with .7z.002; do not rename volumes merely to make them look simpler.

2. List and plan before extracting

Replace the conspicuous placeholders generated in the message detail with your dedicated input and a different output folder. Then run unpack-flow list '<INPUT>/*' and unpack-flow plan '<INPUT>/*'. Quoted wildcards let UnpackFlow choose ordinary archives and valid first volumes without treating later parts as independent jobs.

The plan is evidence about what the local tool can attempt, not a safety verdict. A .zip extension can be false, a password archive can remain unreadable and a successful plan does not prove that included files are harmless. Stop if the matched scope is broader than the folder you prepared.

3. Run in front or start in the background

For a visible foreground job, use the generated unpack-flow run -r ... command. Recursive mode follows nested archives and writes each input to an isolated result directory without overwriting an existing target. For a long batch, use unpack-flow start -r ...; it returns a task identifier, after which unpack-flow status reports progress and unpack-flow wait waits for the final result. The message page displays the exact platform form.

UnpackFlow keeps source archives. It does not automatically execute an EXE inside a package, bypass passwords or silently delete failed inputs. A damaged archive, missing volume, unsupported method, dependency failure or insufficient disk space must remain a visible failure, even when other files succeed.

4. Verify results and recover partial failures

Check the exit status, final task state, output directories, file counts and a few representative expected files. Do not interpret “some archives extracted” as “the batch succeeded.” For a missing volume, return to the dedicated download folder and recover that exact attachment. For a damaged or password-protected package, retain every source part and obtain a trusted replacement or an authorised password through a separate channel.

If the browser blocked some downloads, retry only failed items; downloading successful items again can create renamed duplicates and break multipart relationships. If the inbox expired midway, preserve the files already received and do not claim that the missing parts can be recovered from Once Email.

5. Clean up and delete separately

Local source cleanup is a new decision after successful verification. Prefer a recoverable trash operation, identify the exact source set and never join cleanup to the first extraction command. Keep sources when any archive is damaged, incomplete, password-protected, unsupported or unverified.

Deleting the temporary inbox is independent. Once Email currently deletes the whole temporary inbox, not one individual message, and a download never triggers deletion. Delete the inbox only after you no longer need server access; deleting it cannot remove local downloads. Likewise, deleting local archives does not remove the email.

This separation—download, list, plan, run or start, verify, local cleanup, then optional inbox deletion—preserves the recovery point at every failure boundary.