mail-reporting

The mail-reporting tool facilitates the automated sending of emails, complete with attachments, within Canva workflows. It is specifically designed for reporting purposes in cybersecurity automation, providing timely notifications and insights to team members or stakeholders by leveraging email communication. Outgoing attachments and message bodies can be encrypted natively with the recipient's PGP public key, so sensitive reports no longer need a scripting node to encrypt them beforehand.

Ideal Use Cases & Fit

This tool excels in scenarios such as sending security assessment reports, alerting team members of vulnerabilities discovered during scans, or delivering compliance documentation. It is best utilized when automated notifications are critical for operational efficiency. However, it may not be suitable for scenarios requiring high interactivity or real-time communication.

The native PGP support makes it a good fit for delivering findings to clients or third parties who require encrypted reports, since the recipient's public key can be configured directly in the node.

Value in Workflows

Incorporating mail-reporting into security workflows enhances communication and documentation processes. Positioned at the post-processing stage of assessments, it ensures that critical findings are promptly shared with relevant parties while maintaining a record of the communication. This integration improves responsiveness and accountability within security teams.

Input Data

The tool expects a JSON configuration file with email parameters, which dictates how the email is structured and sent. The required fields include:

• recipients: Email addresses of the recipients.
• subject: Subject line of the email.
• body: Content of the email body, which can be formatted as text or HTML.
• attachments: A list of files to attach, each an object with a filename and its base64-encoded content. Use this to send one or more attachments.
• attachment / attachment_filename: Legacy single-attachment fields (base64 data and its filename). Still supported for backward compatibility.
• encryption: Optional object enabling PGP encryption. See the PGP Encryption section below.

To attach multiple files, provide the plural attachments array. If it is present it takes precedence; otherwise the tool falls back to the legacy single attachment/attachment_filename fields.

Example of the input configuration:

{
  "recipients": "[email protected],[email protected]",
  "subject": "Automated Report",
  "body": "<h2>Report Summary</h2><p>Please find the reports attached.</p>",
  "type": "html",
  "attachments": [
    { "filename": "report.pdf", "content": "SGVsbG8gV29ybGQ=" },
    { "filename": "data.csv", "content": "SGVsbG8gV29ybGQ=" }
  ]
}

Note: all attachments are sent in a single Microsoft Graph request, which limits the total message size (body plus attachments) to roughly 4 MB.

PGP Encryption

Encryption is off by default, so existing workflows are unaffected. To enable it, choose what should be encrypted and supply the recipient's public key.

Modes

Mode	Message body	Attachments
none (default)	sent as configured	sent as configured
attachments	readable	encrypted
body	encrypted	sent unencrypted
all	encrypted	encrypted

attachments is the recommended mode for delivering reports: the covering message stays readable in any mail client, and only the report file needs decrypting. Use body or all when the message text itself is sensitive.

Supplying the key

Public keys are accepted either ASCII-armored or base64 encoded. Because an armored key spans many lines, the base64 form is easier to paste into a node field:

base64 -w0 < recipient-public-key.asc

For a single recipient, paste that value into the pgp_public_key parameter and set encrypt to the mode you need. For several recipients, use the encryption.public_keys array in the input JSON instead — the message is then encrypted so that every listed key can open it.

Example of an input configuration with encryption:

{
  "recipients": "[email protected]",
  "subject": "Weekly security report",
  "body": "<p>The attached report is encrypted with your PGP key.</p>",
  "type": "html",
  "attachments": [
    { "filename": "report.pdf", "content": "SGVsbG8gV29ybGQ=" }
  ],
  "encryption": {
    "mode": "attachments",
    "armor": false,
    "public_keys": [
      "-----BEGIN PGP PUBLIC KEY BLOCK-----\n...\n-----END PGP PUBLIC KEY BLOCK-----"
    ]
  }
}

Setting "enabled": false inside the encryption object turns encryption off while leaving the keys in place, which is useful for toggling the behaviour without editing the key configuration.

What to expect

• Encrypted attachments are renamed. report.pdf is delivered as report.pdf.pgp, or report.pdf.asc when pgp_armor is enabled. Mail clients show these as generic binary attachments with no preview; the recipient decrypts them with their own PGP client.
• The subject line is never encrypted. Neither are the sender, recipient or date. Only the body content and attachment contents are protected, so avoid putting sensitive detail in the subject.
• An encrypted body forces plain text. A PGP message is an armored text block that cannot survive HTML rendering, so type: html is downgraded to text whenever the body is encrypted, and a warning is recorded in the output. Choose the attachments mode to keep a styled covering message.
• Recipients need a PGP client for an encrypted body. An armored block appears as literal text in clients without PGP support, such as Outlook without an add-in. The attachments mode avoids this entirely.
• Nothing is ever sent unencrypted by mistake. If encryption is requested but the key is missing, malformed, expired or revoked, the node fails with an error and no email is sent at all. Expect an expired client key to surface as a workflow failure rather than a plaintext delivery.
• Armored output is about a third larger than binary, which counts against the ~4 MB message limit. Leave pgp_armor off for large attachments.
• Only public keys are accepted. The node rejects private key material, which it never needs.

Verifying the result

The output file records which key was actually used, so a workflow can confirm the report went to the intended recipient:

"encryption": {
  "enabled": true,
  "mode": "attachments",
  "armor": false,
  "body_encrypted": false,
  "attachments_encrypted": true,
  "keys": [
    {
      "fingerprint": "1234567890ABCDEF1234567890ABCDEF12345678",
      "uids": ["Report Recipient <[email protected]>"]
    }
  ]
}

Compare the fingerprint against the one the recipient published. When encryption is off, this block is simply {"enabled": false, "mode": "none"}.

Configuration

• recipients: Newline or comma-separated recipient email addresses.
• subject: Email subject text.
• body: The content of the email body.
• type: Specifies the message type, can be 'text' or 'html' (default: text).
• attachments: List of { filename, content } objects for sending one or more attachments (content is base64-encoded).
• attachment: Base64 encoded data for a single attachment (legacy).
• attachment_filename: Filename for the single attached document (legacy).
• encrypt: What to encrypt with PGP: 'none' (default), 'attachments', 'body' or 'all'.
• pgp_public_key: Recipient PGP public key, ASCII-armored or base64 encoded. For several recipients use the encryption.public_keys array in the input JSON.
• pgp_public_key_file: Path to a recipient PGP public key file.
• pgp_armor: Send ASCII-armored .asc attachments instead of binary .pgp (default: false).

These parameters allow workflow builders to customize the email delivery as per their operational needs, ensuring clear and effective communication in automated processes. Updated: 2026-08-03