has_attachment always false in envelope list JSON output

[Alfa-ai-ccvs-tech]

Issue Update: MML <#part> creates inline text, not MIME attachments; has_attachment always false

Summary

Two distinct bugs confirmed:

1. MML <#part> directive fails to create MIME attachments — file content is inlined as plain text
2. has_attachment JSON field always returns false regardless of actual attachments

Environment

• himalaya: v1.1.0 +imap +maildir +smtp +sendmail +wizard +pgp-commands
• OS: Linux (Pop!_OS) x86_64
• IMAP: Gmail (imap.gmail.com:993 TLS)
• SMTP: Gmail (smtp.gmail.com:587 STARTTLS)
• Config: Standard account, message.send.save-copy = false

Reproduction 1: MML <#part> creates inline text

Steps

# Create test file
echo "BINARY_ATTACHMENT_CONTENT_12345" > /tmp/test-attach.txt

# Send via MML template
cat << 'EOF' | himalaya template send -a myaccount --trace 2>&1 | grep -E '(mml|content|guessing)'
From: sender@gmail.com
To: recipient@example.com
Subject: MML Attachment Test

Body text.

<#part filename=/tmp/test-attach.txt><#/part>
EOF

Actual Trace Output

mml::message::body::compiler::tokens: no content type found, guessing from body: text/plain

Actual Result (email received)

From: sender@gmail.com
To: recipient@example.com
Subject: MML Attachment Test

Body text.

BINARY_ATTACHMENT_CONTENT_12345

Problem: File content is inlined as plain text. No MIME attachment created. Gmail does NOT show this as an attachment.

Expected Result

Email should be Content-Type: multipart/mixed with the file as a separate Content-Disposition: attachment part.

Variations Tested (all fail)

• <#part filename=/tmp/test-attach.txt><#/part> — content inlined
• <#part filename=/tmp/test-attach.txt disposition=attachment><#/part> — content inlined
• <#part type=application/octet-stream filename=/tmp/test-attach.txt><#/part> — tag appears literally in body, not processed

---

Reproduction 2: has_attachment always false

Steps

# Check envelope of any email with known attachment
himalaya envelope list -a myaccount -f "[Gmail]/Sent Mail" --page-size 5 -o json

Actual Result

{
  "id": "136",
  "subject": "MML Attachment Test",
  "has_attachment": false
}

Expected Result

{
  "id": "136",
  "subject": "MML Attachment Test",
  "has_attachment": true
}

Note: This applies to ALL folders (INBOX, Sent Mail, etc.) and ALL emails, including those with verified Content-Type: multipart/mixed in raw headers.

---

Verification: Python SMTP creates real attachments

To confirm this is a himalaya/MML issue, not Gmail/IMAP:

import smtplib
from email.mime.multipart import MIMEMultipart
from email.mime.text import MIMEText
from email.mime.base import MIMEBase
from email import encoders

msg = MIMEMultipart()
msg['From'] = 'sender@gmail.com'
msg['To'] = 'recipient@example.com'
msg['Subject'] = 'Python SMTP Test'

msg.attach(MIMEText('Body text.', 'plain'))

with open('/tmp/test-attach.txt', 'rb') as f:
    part = MIMEBase('application', 'octet-stream')
    part.set_payload(f.read())
    encoders.encode_base64(part)
    part.add_header('Content-Disposition', 'attachment', filename='test-attach.txt')
    msg.attach(part)

with smtplib.SMTP('smtp.gmail.com', 587) as server:
    server.starttls()
    server.login('sender@gmail.com', 'password')
    server.send_message(msg)

Result: Content-Type: multipart/mixed with proper attachment. Gmail displays it correctly. himalaya shows:

Body text.

<#part type=application/octet-stream filename="test-attach.txt"><#/part>

(This is himalaya's MML representation of actual MIME attachment parts.)

---

Key Observations

1. MML tokenizer finds no parts: The trace no content type found, guessing from body: text/plain suggests the MML compiler treats the entire template as a single plain text body.

2. File content is read and inlined: The <#part filename=...> tag IS being processed (file content appears), but as inline text, not as a MIME part.

3. has_attachment detection is completely broken: Even when attachments are created by external tools, the JSON flag is always false.

4. Disparity between IMAP providers: I saw another issue mentioning Fastmail works correctly. This may be Gmail-specific.

---

Questions for Maintainers

1. Is this a known issue with Gmail IMAP specifically?
2. Does MML require Content-Type: multipart/mixed header explicitly declared?
3. Is has_attachment based on MIME structure detection or IMAP flags?

Happy to provide more debug output, packet captures, or test specific builds.

[soywod]

Somehow I cannot reproduce your issue. Could you try with a release build from the CI?

[Alfa-ai-ccvs-tech]

@soywod Thanks for the quick response. I've updated the issue with much more detailed reproduction steps and evidence.

Key findings from deeper testing:

1. MML <#part> is broken on Gmail — the file content gets inlined as plain text instead of creating a MIME attachment. The trace shows:

   mml::message::body::compiler::tokens: no content type found, guessing from body: text/plain
   

   This suggests the MML tokenizer isn't finding the <#part> directive at all.

2. Tested with --trace and various MML syntax variations — all fail.

3. Verified with Python SMTP that Gmail CAN receive proper MIME attachments (confirmed working).

4. has_attachment JSON flag is a separate bug — always returns false even for emails with verified MIME attachments.

About the CI build: I'm happy to test with a nightly/CI build if you can point me to a specific artifact. My current version is:

himalaya v1.1.0 +imap +maildir +smtp +sendmail +wizard +pgp-commands
build: linux gnu x86_64
git: unknown, rev unknown

I noticed another issue mentioned Fastmail works correctly — this might be Gmail IMAP specific. The save-copy = false setting may also be relevant.

Let me know what additional debug info would help.

[soywod]

Regarding MML part, I believe it is a misinterpretation of the himalaya message read command. This command allows you to "read a human-friendly version of the message associated to the given envelope id(s)." (quoted from the --help). A text/plain (or any other text/*) attachement can be easily displayed, inlined. Try with a picture, you should get a different result. You can also try the himalaya message export --full command to get the real MIME message. With the example you gave, I get sth like this:

MIME-Version: 1.0
From: <sender@gmail.com>
To: <recipient@example.com>
Subject: MML Attachment Test
Message-ID: <18951df7a09de20d.3cafc71268a1a89a.10b4ca3cd0585ab2@soywod>
Date: Tue, 17 Feb 2026 19:02:57 +0000
Content-Type: multipart/mixed; 
	boundary="18951df7a09e096b_d6db5a2c3beea87_fd92c38d79d9872a"


--18951df7a09e096b_d6db5a2c3beea87_fd92c38d79d9872a
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Body text.


--18951df7a09e096b_d6db5a2c3beea87_fd92c38d79d9872a
Content-Type: text/plain
Content-Disposition: attachment; filename="test-attach.txt"
Content-Transfer-Encoding: quoted-printable

BINARY_ATTACHMENT_CONTENT_12345=0A
--18951df7a09e096b_d6db5a2c3beea87_fd92c38d79d9872a--

Regarding has_attachement, you can take the himalaya-x86_64-linux: https://github.com/pimalaya/himalaya/actions/runs/22065719058/artifacts/5526418428.