Allow Configurable Attachment Size Limits and Behaviour in Jira Notification Emails

XMLWordPrintable

    • 1
    • 2

      Issue Summary

      When Jira sends notification emails that include attachments, the email delivery channel enforces a payload limit of 230 KB for attachments. If an attachment (or total attachment payload) exceeds this limit, Jira drops the actual file from the email and only includes a text reference. This prevents downstream systems (such as ServiceNow, which rely on the email content to ingest attachments) from receiving larger attachments. Customers would like this behaviour to be configurable and/or more predictable, both for reliability and for security/privacy reasons.

      Steps to Reproduce

      1. In a Jira Cloud project, create an issue and add multiple image attachments of varying sizes, for example:
        • xxx.jpg (~34 KB)
        • yyy.png (~354 KB)
      2. Add a comment to the issue and include:
        • An existing attachment that is below 230 KB (e.g. xxx.jpg)
        • An existing attachment that is above 230 KB (e.g. yyy.png)
      3. Ensure that the issue’s notification scheme is configured so that a user (or an integration endpoint such as ServiceNow) receives email notifications for new comments.
      4. Trigger the notification by posting the comment and observe the resulting email:
        • In a normal mail client (e.g. Outlook, Gmail), and/or
        • In a downstream system that consumes the email (e.g. ServiceNow, which reads attachments from the incoming email).
      5. Compare how the smaller and larger attachments appear in:
        • The email body and attachment list
        • The downstream system’s attachment section (e.g. ServiceNow).

      Expected Results

      • Jira should provide configurable behaviour for attachments in notification emails, for example:
        • Ability to configure whether attachments are:
          • Always included as real attachments (subject to a clearly documented and adjustable limit),
          • Always sent as secure links only, or
          • Included/omitted based on admin‑defined rules (size thresholds, project type, recipient type, etc.).
        • Ability to configure or at least clearly surface the payload limit used by the email delivery channel (currently 230 KB for attachments in this scenario).
      • From an admin and integration perspective:
        • Behaviour should be predictable and documented, so that teams integrating Jira with systems like ServiceNow can reliably understand when attachments will or will not be present in the email.
        • Customers should be able to choose a model that aligns with their security posture (e.g. “no attachments in notifications, only links”) and integration needs (e.g. “attachments must be present for ServiceNow to ingest them”).

      Actual Results

      • For attachments below the 230 KB payload limit (e.g. xxx.jpg at ~34 KB):
        • The attachment is included in the notification email as a real file.
        • Downstream systems such as ServiceNow can see and process the attachment correctly.
      • For attachments above the 230 KB payload limit (e.g. yyy.png at ~354 KB):
        • The notification email only contains a text reference to the attachment.
        • The actual file is dropped from the email to keep the message size under the payload limit.
        • Downstream systems (e.g. ServiceNow) do not receive the attachment and therefore cannot display or store it.
      • This behaviour is:
        • Not configurable per site or per project.
        • Not clearly exposed in the UI or documentation as a tunable limit.
        • Surprising for customers who expect all attachments referenced in the comment to be present in the notification email, especially when they rely on email as an integration channel.

      The below exception is thrown in the xxxxxxx.log file:
       
       N/A – this is not an error/exception scenario from Jira’s perspective, but a size‑based limitation in the email delivery channel. No explicit error is surfaced to admins or end users when the attachment is dropped.

      Workaround

      Currently there is no known workaround for this behavior. A workaround will be added here when available

              Assignee:
              Unassigned
              Reporter:
              Dishon Victor
              Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: