523 Encryption Needed: Invalid Unencrypted Mail

I’m trying to set up a chatmail account so I can use it with both a Deltachat client and a classic client, (neomutt).

(There are other posts here on Chatmail servers, so I hope my problems with getting Neomutt talking to nine.testrun.org won’t be considered offtopic.)

I had little trouble getting Neomutt talking to Nine over IMAP. So now my Deltachat messages are backed up in Maildir format (I intend to post a howto once it’s all working).

The SMTP is more of a problem. Neomutt certainly thinks it is encrypting my outgoing messages, and the keys seem correct. But the server complains the messages are unencrypted:

msmtp: the server did not accept
the mail
msmtp: server message: 523
Encryption Needed: Invalid
Unencrypted Mail
msmtp: could not send mail
(account
xxxxxxxx@nine.testrun.org from
/home/mobian/.msmtprc)

The relevant bits I’m trying in my muttrc config file:

set crypt_replysign
set crypt_replysignencrypted
set pgp_show_unusable=no
set crypt_use_gpgme=yes
set crypt_opportunistic_encrypt=yes
set pgp_self_encrypt=yes
set crypt_autoencrypt=yes
set crypt_replyencrypt=yes

If anyone has any pointers, I’d appreciate them!

I’ve now had this problem with other mailclients. Encryption with the recipient’s key seems to be working fine. I suspect that it is the OpenDKIM that I’m not managing right.

I’m not sure where I’d find my DKIM keys or config in Deltachat. Any advice welcome.

edit: Don’t think this is DKIM after all, would be more likely to get a 5.7.1 No valid DKIM signature found message.

The code that filters mails on a chatmail server returns this error on a fall-through condition.

I’ll poke at this some more and post any useful results.

I think what would help more is that you share an example raw/eml file with the presumably encrypted email that the chatmail is rejecting as unencrypted so chatmail devs can see why it is being detected as unencrypted and hopefully solve the problem in the chatmail filter

Yes, that would make sense. Thank you.

The mail clients that do encryption seem to have a lot of options, and these produce a variety of encrypted formats, variously exportable through various interfaces (often not in eml format).

Some of the messages they produce are labelled as implementing various encryption standards, which seem to be low-level combinatorial standards (they define one aspect of a message, instead of being top-level standards that define all of the format of a message). I can receive and decrypt messages sent from a Deltachat client with other clients, so I can also see the format of canonical DC emails; I’ve been comparing the two.

I will seek specifically eml files for (my best guess as to) some fairly standard and minimal configurations for common clients. Perhaps I can find a way to intercept the SMTP so I don’t need to hunt through the various clients to get the eml files.

IIRC mutt has a config to save a local copy of outgoing email in some “spool-folder” or something like that (I am abusing my memory here from when I used mutt years ago)

I said eml to mention something, what I mean is the raw email as usually would be sent to the SMTP server, and as it is commonly stored in the mailbox folders / files by email clients, just the headers and raw body content

So this is something slightly different but, one hopes, useful: a command which reliably produces the error.

echo "Test message body text" | gpg --verbose --encrypt --sign --recipient="receiver@nine.testrun.org" --local-user="sender@nine.testrun.org" | msmtp --host=nine.testrun.org --domain=[127.0.0.1] --port=587 --tls=on --auth=on --user=sender@nine.testrun.org --from=sender@nine.testrun.org receiver@nine.testrun.org

Actual email addresses which are in the keyring are needed, and it will prompt for the nine.testrun.org login password and for any access passwords configured for the keyring. I can add details of this on

The domain= is strictly needed, defaults fail. For instance, omitting the square brackets causes it to fail with this error message:

msmtp: server message: 504 5.5.2
<127.0.0.1>: Helo command
rejected: need fully-qualified
hostname