<!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "type::bug" label: - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=type::bug and verify the issue you're about to submit isn't a duplicate. ---> ### Summary <!-- Summarize the bug encountered concisely. --> When replying to an issue via email (incoming email / Service Desk), the resulting comment in GitLab is truncated after the first line if the email body contains certain bullet lists (for example, lines starting with `-` and including non-ASCII characters), causing loss of content. ### Steps to reproduce <!-- Describe how one can reproduce the issue - this is very important. Please use an ordered list. --> 1. Configure incoming email / Service Desk on a self-managed Omnibus instance with: - `mailroom['enable'] = true` - `gitlab_rails['incoming_email_enabled'] = true` - IMAP/SMTP pointing to a mailbox (for example, Gmail) for issue replies. 2. Create a test project and configure a Service Desk / incoming email address for an issue. 3. From an external email client, reply to the issue via email with a body that includes: - Multiple lines using hyphen bullets, for example: - `- Some text with non-ASCII characters (such as German umlauts)` - `- Another bullet line` - Additional lines of text after the bulleted list. 4. Send the email and wait for GitLab to ingest it as an issue comment. 5. View the resulting comment on the issue. User is using German as the kommunikation Language, including Keyboards with the QWERTZ Layout. With Gmail in a Webbrowser, specifically Chrome on Linux or Windows devices. ### Example Project <!-- If possible, please create an example project here on GitLab.com that exhibits the problematic behavior, and link to it here in the bug report. If you are using an older version of GitLab, this will also determine whether the bug is fixed in a more recent version. --> This has been observed on a self-managed Omnibus instance (GitLab 19.0.2). I was unable to reproduce the truncating on GitLab.com. ### What is the current *bug* behavior? <!-- Describe what actually happens. --> - The issue comment created from the reply-by-email contains only the first line of the email body. - All subsequent lines (including the bulleted list and any following text) are silently discarded. - The behavior appears correlated with the presence of bullet list lines (for example, lines starting with `-`), including when the content contains non-ASCII characters and/or quoted-printable encoding. - Sending the same content without bullet formatting results in the full email body arriving correctly as a comment. ### What is the expected *correct* behavior? <!-- Describe what you should see instead. --> - The full email body should be preserved when an issue is updated via incoming email / Service Desk, regardless of: - Plain-text bullet formatting (e.g. `-` or `*` at the start of a line), - Presence of non-ASCII characters or quoted-printable encoding. - No part of the user’s message should be silently dropped; if parsing fails, the raw message should still be retained (or an error surfaced) instead of truncating after the first line. ### Relevant logs and/or screenshots <!-- Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's tough to read otherwise. --> Mailroom log on the affected instance was reported as empty at the time of ingestion, and no obvious related errors were observed in Rails logs around the timestamps when the problematic emails were received. Configuration (sanitized example) used for incoming email and SMTP: ```ruby sidekiq['enable'] = true mailroom['enable'] = true gitlab_rails['smtp_enable'] = true gitlab_rails['smtp_address'] = "smtp.example.com" gitlab_rails['smtp_port'] = 465 gitlab_rails['smtp_user_name'] = "issue@example.com" gitlab_rails['smtp_password'] = "<redacted>" gitlab_rails['smtp_domain'] = "example.com" gitlab_rails['smtp_authentication'] = "login" gitlab_rails['smtp_tls'] = true gitlab_rails['incoming_email_enabled'] = true # gitlab_rails['incoming_email_delivery_method'] = "sidekiq" gitlab_rails['incoming_email_address'] = "issue+%{key}@example.com" gitlab_rails['incoming_email_email'] = "issue@example.com" gitlab_rails['incoming_email_password'] = "<redacted>" gitlab_rails['incoming_email_host'] = "imap.example.com" gitlab_rails['incoming_email_port'] = 993 gitlab_rails['incoming_email_ssl'] = true gitlab_rails['incoming_email_start_tls'] = false gitlab_rails['incoming_email_mailbox_name'] = "inbox" gitlab_rails['incoming_email_idle_timeout'] = 60 gitlab_rails['incoming_email_delete_after_delivery'] = false ``` ### Output of checks #### Results of GitLab environment info <!-- Input any relevant GitLab environment information if needed. --> Self-managed Omnibus GitLab: - GitLab version: 19.0.2 - Edition/plan: Self-Managed Premium - Deployment: single-node Omnibus Linux package - Incoming email: `incoming_email_enabled = true`, `mailroom['enable'] = true` - Mail backend: external IMAP/SMTP (for example, Gmail) Full `gitlab:env:info` output was not captured at the time of reporting. <details> <summary>Expand for output related to GitLab environment info</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`) </pre> </details> #### Results of GitLab application Check <!-- Input any relevant GitLab application check information if needed. --> The results of `gitlab:check` were not available at the time of filing this issue. <details> <summary>Expand for output related to the GitLab application check</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:check SANITIZE=true`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true`) (we will only investigate if the tests are passing) </pre> </details> ### Possible fixes <!-- If you can, link to the line of code that might be responsible for the problem. --> The bug appears to be in the incoming email parsing path for replies (mail_room / email reply handling), where certain combinations of: - Bullet list lines starting with `-` or `*`, and - Encoded or non-ASCII characters (for example, quoted-printable, UTF-8) cause the parser to treat the first line as the only valid body content and drop the remainder of the message. Areas to investigate: - Email body parsing in the incoming email / Service Desk pipeline (mail_room and any email-reply-parsing helpers). - Handling of multipart and quoted-printable messages with bullet lists, ensuring we do not mis-identify the remainder of the email as a signature, quote block, or discardable content. ### Patch release information for backports If the bug fix needs to be backported in a [patch release](https://handbook.gitlab.com/handbook/engineering/releases/patch-releases) to a version under [the maintenance policy](https://docs.gitlab.com/policy/maintenance/), please follow the steps on the [patch release runbook for GitLab engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md). Refer to the [internal "Release Information" dashboard](https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1) for information about the next patch release, including the targeted versions, expected release date, and current status. #### High-severity bug remediation To remediate high-severity issues requiring an [internal release](https://handbook.gitlab.com/handbook/engineering/releases/internal-releases/) for single-tenant SaaS instances, refer to the [internal release process for engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/internal-releases/engineers.md?ref_type=heads). <!-- If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"` -->