Member Avatar for mcatest

Is it possible to e-mail an .exe or .zip file so that only the recipient can unzip it & it cannot be sent from the recipient to a second recipient? I.e. the file cannot be re-sent from that person to another person.

SNIP

Edited by happygeek because: fake sig snipped
  • 2 Contributors
  • 3 Replies
  • 195 Views
  • 2 Days Discussion Span
  • Latest Post Latest Post by Member #585571

Dani AI

Generated

was correct that key-based (OpenPGP) encryption is the technical way to make an emailed attachment readable only by a specific recipient: encrypt the file to the recipient’s public key so only their private key can decrypt it. GnuPG manual. (gnupg.org) That said, encryption does not stop a recipient who can read the decrypted file from re-sending, copying, or photographing it—preventing redistribution requires enterprise rights-management or controlled sharing and even those controls are not foolproof. (flylib.com)

A minimal GnuPG workflow (CLI) to implement ’s suggestion looks like this:

# generate keypair (if needed)
gpg --full-generate-key

# export/import public key
gpg --armor --export recipient@example.com > recipient.pub.asc
gpg --import recipient.pub.asc

# encrypt for recipient (creates file.zip.gpg)
gpg --output file.zip.gpg --encrypt --recipient recipient@example.com file.zip

# recipient decrypts
gpg --output file.zip --decrypt file.zip.gpg

Use signing ( --sign ) to prove origin. For direct reference on commands and options see the GnuPG documentation. (gnupg.org)

Practical tips: many mail providers block plain .exe attachments—encrypt before sending and attach the encrypted blob (.gpg or ASCII-armored .asc) instead. GUI helpers exist: Kleopatra/Gpg4win for Windows and GPG Suite on macOS; Thunderbird has built-in OpenPGP support for mail integration. Gpg4win, Thunderbird OpenPGP HOWTO. (gpg4win.org)

If the primary goal is to prevent onward sharing rather than simply preventing unauthorized opening, consider enterprise IRM/DRM or “specific people” secure sharing (OneDrive/SharePoint / Azure Information Protection / Purview) to restrict forwarding, set expirations and revoke access—but these require managed identities and still cannot stop screen photos or manual copying. Microsoft IRM overview. (support.microsoft.com)

Recommended Answers

All 3 Replies

Member Avatar for Member #585571

You need to encrypt the message using a key. You will have the public and private key and the recipent should have the public key. Only the recipent will be able to decrypt the message.

Member Avatar for mcatest

You need to encrypt the message using a key. You will have the public and private key and the recipent should have the public key. Only the recipent will be able to decrypt the message.

Thanks. How would I actually do this?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.