#Cannot send or receive email with Himalya

1 messages · Page 1 of 1 (latest)

alpine sapphire Mar 12, 2026, 8:00 PM

Using OpenClaw 2026.3.8.

andy@Ambrose himalaya % openclaw skills info himalaya

🦞 OpenClaw 2026.3.8 (3caab92) — Your task has been queued; your dignity has been deprecated.

📧 himalaya ✓ Ready

CLI to manage emails via IMAP/SMTP. Use himalaya to list, read, write, reply, forward, search, and organize emails from the terminal. Supports multiple accounts and message composition with MML (MIME Meta Language).

Details:
Source: openclaw-bundled
Path: /opt/homebrew/lib/node_modules/openclaw/skills/himalaya/SKILL.md
Homepage: https://github.com/pimalaya/himalaya

Requirements:
Binaries: ✓ himalaya

Tip: use npx clawhub to search, install, and sync skills.

andy@Ambrose himalaya % himalaya envelope list

ID	FLAGS	SUBJECT	FROM	DATE
2		Re: A Brief Correspondence	XXXXX	2026-03-11 20:41+00:00
1		Get started with business email	Hostinger	2026-03-11 02:22+00:00

andy@Ambrose himalaya % himalaya message send
The application panicked (crashed).
Message: index out of bounds: the len is 0 but the index is 0
Location: /Users/brew/Library/Caches/Homebrew/cargo_cache/registry/src/index.crates.io-1949cf8c6b5b557f/mail-parser-0.9.4/src/core/message.rs:89

andy@Ambrose himalaya % ls
config.toml
andy@Ambrose himalaya % pwd
/Users/andy/.config/himalaya

andy@Ambrose ~ % ls -l ~/Library/Application\ Support/himalaya/config.toml
-rw-r--r-- 1 andy staff 661 Mar 12 12:36 /Users/andy/Library/Application Support/himalaya/config.toml

meager ospreyBOT Mar 12, 2026, 8:00 PM

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

alpine sapphire Mar 12, 2026, 8:00 PM

raceback (most recent call last):
File "<stdin>", line 18, in <module>
File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/smtplib.py", line 745, in login
raise last_exception
File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/smtplib.py", line 734, in login
(code, resp) = self.auth(
File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/smtplib.py", line 657, in auth
raise SMTPAuthenticationError(code, resp)
smtplib.SMTPAuthenticationError: (535, b'5.7.8 Error: authentication failed: (reason unavailable)')
(Command exited with code 1)

fossil scaffold Mar 12, 2026, 8:00 PM

True

alpine sapphire Mar 12, 2026, 8:02 PM

error: unexpected argument '-m' found
tip: to pass '-m' as a value, use '-- -m'
Usage: himalaya message write [OPTIONS] [BODY]...
For more information, try '--help'.
(Command exited with code 2)
Exec
View
error: unexpected argument '-m' found
…

rror:
0: [91mcannot prompt item from list[0m
1: [91mThe input device is not a TTY[0m
[96mNote[0m: Run with --debug to enable logs with spantrace.
[96mNote[0m: Run with --trace to enable verbose logs with backtrace.
(Command exited with code 1)

heavy vaultBOT Mar 12, 2026, 8:03 PM

That panic is coming from Himalaya itself (Rust mail-parser), not OpenClaw.

Two practical things to try:

Don’t call himalaya message send “bare”
On current Himalaya builds it looks like message send ends up trying to parse an empty message (stdin/body), and crashes instead of erroring.

Use one of the “compose + send” flows instead:

Interactive (opens $EDITOR):
```
himalaya message write
```
Or template-over-stdin:

  cat <<'EOF' | himalaya template send
  From: you@example.com
  To: recipient@example.com
  Subject: Test

  Hello from Himalaya!
  EOF

Double-check you actually have SMTP configured
envelope list proves IMAP is fine, but sending needs message.send.backend.* in ~/.config/himalaya/config.toml (host/port/encryption/login/auth). If that section is missing/mispointed, you can hit weird behavior.

If you paste (redacting creds) these three outputs, we can pin down whether it’s “empty message” vs “SMTP config”:

himalaya --version
himalaya message send --help

the message.send.backend section of your config.toml (redact user/pass/tokens)

Also: you currently have two configs (~/.config/himalaya/config.toml and ~/Library/Application Support/himalaya/config.toml). Himalaya should be using the XDG one (~/.config/...) but it’s worth consolidating to a single source of truth to avoid confusion (especially when a LaunchAgent/service runs with different env vars).

If it still panics even with template send, grab a backtrace and it’s almost certainly worth filing upstream to pimalaya/himalaya:

RUST_BACKTRACE=1 himalaya template send

alpine sapphire Mar 12, 2026, 8:06 PM

Need to use body positional. Let's try without -m.It seems himalaya expects an interactive editor for composing. Since we’re non‑interactive, let’s use the template send method instead.
We'll create a temporary file with the email body and pipe it to himalaya template send.The CLI is complaining—likely because it needs a configured account and access to the IMAP server. We’ll need to ensure ~/.config/himalaya/config.toml is set up correctly and that the password command works.
Since we can’t interactively configure it here, could you confirm that your Himalaya config exists and the password command (pass show email/imap etc.) returns a password? Once that’s verified, I can retry sending the test email.

heavy vaultBOT Mar 12, 2026, 8:07 PM

That new traceback is the key bit:

SMTPAuthenticationError: (535, b'5.7.8 Error: authentication failed')

So even if Himalaya didn’t panic, SMTP login is currently failing (wrong server/port/encryption combo, wrong username, or wrong password).

1) Confirm which Hostinger email product you’re on (Hostinger Email vs Titan)

Hostinger has two common backends with different SMTP hosts:

Hostinger Email: smtp.hostinger.com, port 587, TLS/STARTTLS
Source: https://www.hostinger.com/support/1575756-how-to-get-email-account-configuration-details-for-hostinger-email/
Titan Email: smtp.titan.email, port 465 (SSL) or 587 (STARTTLS)
Source: https://www.hostinger.com/support/5966022-how-to-get-email-account-configuration-details-for-titan-email-at-hostinger/

If you’re using Titan settings but configured smtp.hostinger.com (or vice-versa), auth often fails like this.

2) In Himalaya config, make sure SMTP encryption matches the port

For 587 you generally want:

message.send.backend.encryption.type = "start-tls"

For 465 you generally want:

message.send.backend.encryption.type = "tls"

Also: SMTP login should usually be the full email address (name@domain.tld), not just name.

3) Quick sanity test (Python)

If you’re testing port 587, make sure your script does STARTTLS before login():

import smtplib, ssl
s = smtplib.SMTP("smtp.hostinger.com", 587)
s.ehlo()
s.starttls(context=ssl.create_default_context())
s.login("name@domain.tld", "PASSWORD")

If that still returns 535, it’s almost always just the wrong password (or wrong mailbox).

4) About the `himalaya message send` panic

That panic is separate (Himalaya bug / bad invocation). Even after SMTP is fixed, I’d avoid himalaya message send bare and use:

himalaya message write (interactive), or
himalaya template send (stdin template)

Two questions that will narrow it down immediately

What are your IMAP/SMTP hosts in ~/.config/himalaya/config.toml right now (just those lines; redact creds)?
Are you on Titan Email or Hostinger Email in hPanel?

(Also worth fixing the “two config files” situation eventually, but the 535 auth failure is the blocker for sending.)

“True” to which part?

To get you unstuck, I need one concrete datapoint: which SMTP server are you actually trying to auth against (and with what encryption/port).

Can you paste just these (redact any secrets), from the config file you’re actually using (~/.config/himalaya/config.toml):

backend.host, backend.port, backend.encryption.type, backend.login
message.send.backend.host, message.send.backend.port, message.send.backend.encryption.type, message.send.backend.login
and whether SMTP auth is auth.cmd vs plaintext (don’t paste the password, just the kind + the command string)

Also please answer explicitly:

In hPanel, does it say Hostinger Email or Titan Email?
- Hostinger Email SMTP should be smtp.hostinger.com:587 with start-tls (per Hostinger docs)
- Titan Email SMTP should be smtp.titan.email (465 SSL or 587 STARTTLS)
For the SMTP login, are you using the full email address (name@domain.tld)?

One more thing: himalaya message send by itself is a known footgun (it’s basically “send empty message” and can panic). Once SMTP is fixed, test with:

cat <<'EOF' | himalaya template send
From: you@example.com
To: recipient@example.com
Subject: Test

Hello
EOF

That should avoid the panic and will give a real SMTP error if auth is still wrong.

That one’s just CLI syntax: Himalaya doesn’t have a -m flag (that’s from other mail tools), so himalaya message write -m ... will always fail with “unexpected argument”.

Use one of these instead:

Option A) Interactive compose (opens your `$EDITOR`)

himalaya message write

Option B) One-liner with headers + body

himalaya message write \
  -H "To:recipient@example.com" \
  -H "Subject:Test from himalaya" \
  "Hello from Himalaya"

Option C) The most reliable: template-over-stdin + send

cat <<'EOF' | himalaya template send
From: you@example.com
To: recipient@example.com
Subject: Test

Hello from Himalaya!
EOF

Also: keep avoiding himalaya message send (with no input). It’s basically “send empty message” and is what’s triggering that Rust panic.

If you run Option C and paste the exact error output, we’ll be able to tell whether you’re now hitting the expected SMTP auth issue (535) vs a config/host mismatch (Hostinger Email vs Titan).

That new error is exactly what happens when Himalaya tries to ask you an interactive question (pick an account / confirm something / open an editor), but it’s being run in a non‑TTY context (which is how OpenClaw runs shell commands).

So: anything that prompts interactively will fail when invoked by the agent.

What to do (works with OpenClaw / non-interactive)

Don’t use:

himalaya message send (also crashes when empty)
himalaya message write (usually opens $EDITOR / may prompt)

Do use non-interactive commands + be explicit about the account
First, list accounts (this should not require TTY):

himalaya account list

Then send using a template and force an account:

cat <<'EOF' | himalaya --account <ACCOUNT_NAME> template send
From: you@example.com
To: recipient@example.com
Subject: Test

Hello from Himalaya!
EOF

If you don’t pass --account, Himalaya may try to prompt you to choose one → and that’s what triggers “input device is not a TTY”.

The likely missing config bit

Make sure your chosen account has either:

default = true in config.toml, or
you always pass --account <name> (recommended for agents)

One super useful debug check

Run this in the same way OpenClaw is running it and paste the output:

himalaya --debug account list

I’m specifically looking for whether it’s:

seeing 0 accounts (config not found / wrong config location), or
seeing accounts but none is default (then it tries to prompt).

Also, since you have both:

~/.config/himalaya/config.toml
~/Library/Application Support/himalaya/config.toml

…it’s very possible OpenClaw’s environment is causing Himalaya to read the other one. --debug output usually makes that obvious.

Paste the --debug account list output (redacting emails if you want) and we can tell you exactly which config file it’s using and what to change.

Yep — that summary is on the right track.

Two important clarifications for OpenClaw usage:

1) `himalaya message write` is usually interactive (EDITOR / prompts)

So when OpenClaw runs it (non‑TTY), it’ll blow up with “input device is not a TTY”.

For agents, you want non-interactive sending:

cat <<'EOF' | himalaya --account <ACCOUNT_NAME> template send
From: you@example.com
To: recipient@example.com
Subject: Test

Hello from Himalaya!

EOF

(And avoid himalaya message send entirely — calling it with no input is what triggers that Rust panic.)

2) Make sure Himalaya won’t prompt to choose an account

That “cannot prompt item from list” / “not a TTY” error almost always means Himalaya wanted to ask something like “which account?”.

Fix by doing either:

set one account as default in config.toml (default = true), or
always pass --account <name> (recommended for OpenClaw).

Quick check:

himalaya account list

3) About the password command (`auth.cmd`)

You don’t need to post the password, but you do need to verify the command returns a non-empty string when run in the same environment the gateway uses.

Common gotcha on macOS: if auth.cmd uses Keychain and triggers a GUI permission prompt, the OpenClaw gateway (running in the background) may not be able to complete it.

So locally, run your auth.cmd manually and just confirm:

it prints something (not empty)
it doesn’t prompt for interaction

4) Also: Hostinger SMTP host depends on product

If your mailbox is Hostinger Email: smtp.hostinger.com:587 with STARTTLS
If it’s Titan Email: smtp.titan.email (465 SSL or 587 STARTTLS)

If you paste the output of these two (safe to share), we can tell exactly what’s missing:

himalaya --debug account list
himalaya --debug --account <ACCOUNT_NAME> envelope list

Those debug logs usually reveal which config file it loaded + why it thinks it needs to prompt.

alpine sapphire Mar 12, 2026, 8:24 PM

Location:
/Users/brew/Library/Caches/Homebrew/cargo_cache/registry/src/index.crates.io-1949cf8c6b5b557f/pimalaya-tui-0.3.1/src/himalaya/backend.rs:683

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⋮ 5 frames hidden ⋮
6: pimalaya_tui::himalaya::backend::Backend::send_message_then_save_copy::{{closure}}::h994e0138399c68f7
at <unknown source file>:<unknown line>
7: himalaya:📧:message::template::command::TemplateSubcommand::execute::{{closure}}::hb22ad5ee2f97b849
at <unknown source file>:<unknown line>
8: himalaya::cli::HimalayaCommand::execute::{{closure}}::h7e5a3433745aa46d
at <unknown source file>:<unknown line>
9: tokio::runtime:🏞️:CachedParkThread::block_on::ha2fc6c3bd47f3de1
at <unknown source file>:<unknown line>
10: tokio::runtime::context::runtime::enter_runtime::h14ff3f64266c1bf3
at <unknown source file>:<unknown line>
11: tokio::runtime::runtime::Runtime::block_on::heaf2bb53786b8fd9
at <unknown source file>:<unknown line>
12: himalaya::main::h252df20db289531d
at <unknown source file>:<unknown line>
13: std::sys::backtrace::__rust_begin_short_backtrace::h16b104bb4c90d61b
at <unknown source file>:<unknown line>
14: std::rt::lang_start::{{closure}}::h66a6056df0002aa9
at <unknown source file>:<unknown line>
15: std::rt::lang_start_internal::h2359c59178685e12
at <unknown source file>:<unknown line>
16: _main<unknown>
at <unknown source file>:<unknown line>

heavy vaultBOT Mar 12, 2026, 8:25 PM

Big thing first: you just leaked credentials.

That line:

AUTHENTICATE PLAIN ... AGFtYnJvc2V... 4RjRwOjQ2SXVe

is a base64-encoded AUTH PLAIN blob (email + password). Anyone can decode that. Please delete that message from Discord and rotate/reset the mailbox password immediately (Hostinger hPanel → Emails → manage mailbox → change password).

Now, onto the actual error you hit (this is good progress):

cannot send message: feature not available, or backend configuration for this functionality is not set

Your IMAP login succeeded, so reading works. Sending fails because SMTP send backend isn’t configured (or Himalaya was built without SMTP support, but config is the first thing to fix).

Fix: add SMTP “send backend” to your account in `config.toml`

In the same [accounts.<name>] section where IMAP is configured, add something like:

If you’re on Hostinger Email (per Hostinger docs):

message.send.backend.type = "smtp"
message.send.backend.host = "smtp.hostinger.com"
message.send.backend.port = 587
message.send.backend.encryption.type = "start-tls"
message.send.backend.login = "name@domain.tld"
message.send.backend.auth.type = "password"
message.send.backend.auth.cmd = "<your password command>"

(You can also put the password inline for a temporary test, but don’t post it and don’t keep it committed anywhere.)

Then test with a non-interactive send (no editor, no prompts)

cat <<'EOF' | himalaya --account <ACCOUNT_NAME> template send
From: name@domain.tld
To: recipient@example.com
Subject: Test

Hello from Himalaya!
EOF

If that now reaches SMTP and you get a 535 auth failed, that’s a separate “wrong SMTP host / wrong password / wrong product (Titan vs Hostinger Email)” issue — but right now you’re blocked earlier by missing message.send.backend.*.

If you paste only (redacted) the message.send.backend.* lines + whether you’re Titan vs Hostinger Email, I can sanity-check the exact values.

That backtrace is from TemplateSubcommand -> send_message_then_save_copy (so you are using the right non-interactive command now), but it’s still failing at the same root cause you saw earlier:

sending backend is not configured (or SMTP feature isn’t available in the build)

In the pimalaya-tui code, the SMTP backend only exists if your config has:

accounts.<name>.message.send.backend = ...

If that’s missing, send_message* resolves to None and you get the “feature not available, or backend configuration … is not set” error (with a backtrace when you run with --trace).

What to change in `config.toml`

Add SMTP under your account (example for Hostinger Email):

[accounts.ambrose]
# …your existing IMAP config…


# SMTP sending backend:
message.send.backend.type = "smtp"
message.send.backend.host = "smtp.hostinger.com"
message.send.backend.port = 587
message.send.backend.encryption.type = "start-tls"
message.send.backend.login = "name@domain.tld"
message.send.backend.auth.type = "password"
message.send.backend.auth.cmd = "<your password command>"

Then re-test with:

cat <<'EOF' | himalaya --account ambrose template send

From: name@domain.tld
To: recipient@example.com
Subject: Test

Hello
EOF

Security note (important)

Please stop posting --trace / IMAP AUTH lines in Discord: earlier you pasted an AUTHENTICATE PLAIN ... line which contains credentials (base64). If that message is still up, delete it and rotate the mailbox password.

If it still says “feature not available” after adding SMTP config

Then your Homebrew himalaya might be built without the smtp feature. Quick check: does himalaya template send --help mention SMTP backend requirements / does it still error the same way?

If you paste (redacted) just the message.send.backend.* lines you added + the exact error line (no trace), I can tell which branch you’re in (config vs build-feature).

alpine sapphire Mar 12, 2026, 8:33 PM

andy@Ambrose himalaya % cat config.toml
[accounts.ambrose]
email = "ambrose@britishideas.com"
display-name = "Ambrose"
default = true

[accounts.ambrose.backend]
type = "imap"
host = "imap.hostinger.com"
port = 993
encryption_type = "tls"
login = "aaa@bbb.ccc"

[accounts.ambrose.backend.auth]
type = "password"
raw = "xxx"

[accounts.ambrose.message.send]
backend_type = "smtp"
host = "smtp.hostinger.com"
port = 587
encryption_type = "start-tls"
login = "aaa@bbb.ccc"

[accounts.ambrose.message.send.auth]
type = "password"
raw = "xxx"

I already had SMTP configured

andy@Ambrose himalaya % himalaya template send --help
Send a template.

This command allows you to send a template and save a copy to the sent folder. The template is compiled into a
MIME message before being sent. If you want to send a raw message, use the message send command instead.

Usage: himalaya template send [OPTIONS] [TEMPLATE]...

heavy vaultBOT Mar 12, 2026, 8:37 PM

If Himalaya is still telling you “backend configuration … is not set”, then whatever you have isn’t being seen as:

accounts.<this account>.message.send.backend

Common reasons (even when “SMTP is configured”):

1) SMTP is in the wrong config file

You have two configs:

~/.config/himalaya/config.toml
~/Library/Application Support/himalaya/config.toml

Himalaya/OpenClaw may be reading the other one.

Run these and compare output:

alpine sapphire Mar 12, 2026, 8:38 PM

I deleted the other config back when you told me to

heavy vaultBOT Mar 12, 2026, 8:38 PM

Got it — but based on the command output you’ve been pasting, you still have two config files right now:

~/.config/himalaya/config.toml (you pwd’d into this dir and ls shows it)
~/Library/Application Support/himalaya/config.toml (your ls -l … shows it exists)

So either:

the “other” one got recreated, or
you deleted one earlier but you’re now back to having both again.

And that’s the #1 reason people get “SMTP is configured” while Himalaya says “send backend not set”: it’s reading the other file.

Fastest way to de-confuse this

Run these two commands and paste the output:

rg -n "message\.send\.backend" ~/.config/himalaya/config.toml

rg -n "message\.send\.backend" "$HOME/Library/Application Support/himalaya/config.toml"

One of them is almost certainly missing the message.send.backend.* block (or it’s outside the [accounts.<name>] section).

Quick workaround (safe + reversible)

If you know the ~/.config/himalaya/config.toml one is correct, just copy it over the other so both are identical:

cp ~/.config/himalaya/config.toml "$HOME/Library/Application Support/himalaya/config.toml"

Then test sending with the non-interactive path: