Advanced Features#

LLM Rule usage and prompt examples#

MailTrigger supports using LLM prompts as rule logic. When you select LLM Prompt as the rule type, the entire email content is sent to your configured LLM provider along with your prompt. The prompt must return a boolean value, for example:

Is this email related to a user account issue?

This will trigger the LLM to analyze the email and return True or False, determining whether the rule matches.

Use cases include:

  • Customer complaint detection

  • Spam or fraud email detection

  • User request classification (e.g., refund, upgrade)

LLM Action#

LLM Actions allow you to use a prompt to process email behavior, such as modifying content, generating attachments, or determining whether to proceed with subsequent actions.

Feature 1: Modify Email Content#

If “Attach to Mail” is not checked, the LLM’s return value will be used to directly modify the email content. The following fields can be updated:

  • subject

  • body

  • receivers

  • sender

Example prompt:

Please rewrite this subject line to make it clearer.

Feature 2: Control whether to execute next Action (passToNext)#

You can include instructions in your prompt that indicate whether to continue executing the remaining actions in the route.

If this is determined to be spam, return a warning message and stop any further actions.

Feature 3: Attach response as a file#

If “Attach to Mail” is checked, the returned text will be saved as a .txt file and added as an attachment.

You can then reference the result using:

  • $ATTACHMENT1 – first attachment content

  • $ATTACHMENT_LAST1 – last attachment content

  • $ATTACHMENT – a list of all attachment contents

  • $ATTACHMENT2 – second attachment

  • $ATTACHMENT_LAST2 – second-to-last attachment

  • and so on…

JS Rule & JS Action#

JS Rule: Custom logic using JavaScript#

You only need to write the logic that returns a boolean. Your code is automatically wrapped in the following format:

return mail.subject.includes("hello");

The mail variable is provided and contains:

  • mail.subject: email subject

  • mail.body: email body

  • mail.sender: sender

  • mail.receivers: list of recipients

  • mail.attachments: list of attachment contents (as strings)

JS Action: Dynamically modify or process email#

You can:

  • Directly modify email fields (subject, body, receivers)

  • Return content as an attachment (if “Attach to Mail” is checked)

Write only the return block. Your code will be wrapped automatically in an async function. Use mail as the input variable.

// Modify email content
return {
    subject: "New Subject",
    body: "Updated body content"
};

To generate an attachment:

return {
    data: "This content will be added as an attachment"
};

Attaching Action Results as Mail Attachments#

Some actions (such as LLM Action, JS Action, and Webhook Action) allow you to attach their execution results to the original email as a .txt file. This makes it possible for subsequent actions in the route to reuse the result by referencing the attachment content.

Why is this useful?

  • It allows each action to focus on one step (e.g., generate → reuse → respond).

  • You can chain complex behavior without writing all-in-one logic.

Examples:

  • An LLM Action analyzes the email and generates a reply → attaches the reply as summary.txt → the next AutoRespond Action uses $ATTACHMENT_LAST1 as the reply content.

  • A JS Action extracts the error code from a mail log → attaches it → the next Webhook Action posts the error code via API using $ATTACHMENT1.

File naming convention

Attached result files are named using the format:

attachment-action-{action_id}.txt

This ensures traceability and allows you to identify which action generated which file.

Inline Variables for Actions#

When configuring an action, you can use inline variables to reference the contents of the original email. These variables let you dynamically insert values like the subject, body, sender, or even attachment contents into action parameters.

For example, if you’re creating a Forward or AutoRespond action, you can write the body like this:

original message: $BODY

When the action runs, $BODY will be replaced with the full body text of the original email.

Available Inline Variables#

  • $SUBJECT – The original subject of the email

  • $BODY – The original body content (text/plain or fallback from HTML)

  • $SENDER – The sender’s email address

  • $RECEIVERS – A comma-separated list of all recipients

  • $ATTACHMENT – A list of all attachment contents (as raw string or base64)

  • $ATTACHMENT1, $ATTACHMENT2 – The first and second attachment contents

  • $ATTACHMENT_LAST1, $ATTACHMENT_LAST2 – The last and second-to-last attachment contents

Usage Examples#

  • Forwarding email with context: Body: Forwarded by MailTrigger:\n\n$BODY

  • AutoRespond with last attachment as reply: Body: $ATTACHMENT_LAST1

  • Webhook payload with sender and subject: JSON:

    {
      "from": "$SENDER",
      "subject": "$SUBJECT",
      "message": "$BODY"
    }
    
  • LLM-generated file passed to next action: An LLM action writes a summary as an attachment → the next action (e.g. AutoRespond or Webhook) uses $ATTACHMENT_LAST1 to reuse it.

These variables allow powerful chaining and customization across actions without writing code.

Email forwarding and SMTP relay#

Forward Action: Send to another mailbox via external SMTP#

Repackages and sends using a specified SMTP server. Commonly used to notify third parties.

Parameters:

  • smtp_server: SMTP host

  • receivers: destination addresses

  • timeout: timeout in seconds (default: 30)

Relay Action: Send mail directly via MailTrigger#

This action sends email directly from MailTrigger’s internal SMTP server (smtp.mailtrigger.app) — no external SMTP is involved.

Requirements:

  • You must configure your DNS with SPF (e.g., a:smtp.mailtrigger.app)

  • DKIM and DMARC setup are mandatory to prevent delivery issues

  • Email is sent via TLS (port 587), authenticated using your MailTrigger mailbox and password

This is suitable for Gmail’s “Send mail as” setup, or as a lightweight SMTP relay for teams or services.

Important: Because MailTrigger is the actual sender, proper DNS configuration is mandatory to avoid being flagged as spam.

Setting Up Scheduled Actions#

Jack uses a server resource management system that emails him about all server resource changes. However, due to the frequent notifications, Jack misses important messages. To address this, Jack uses MailTrigger’s background task execution feature to write the necessary logic and compile it into a WASM file. Here are the complete steps:

  1. Configure routes so that emails related to “server resource changes” take no action, ensuring they do not clutter Bob’s mailbox.

  2. In the MailTrigger dashboard, navigate to Background Task Settings and create a new configuration.

    Example of background task settings
  3. Configure the background task:

    • Set a clear name, such as “Resource Monitor”.

    • Choose the mailbox and frequency (e.g., every 1 hour).

    • Save and enable the task.

  4. To confirm the task is working:

    • Go to the Task Configuration list.

    • Check the Status column to ensure it shows “Success”.