Sending attachments with GNU mail to @kindle.com

Question

Background: I'm trying to set up a server to regularly pull RSS feeds, package them up in a mobi-ebook and send them to my kindle.

Problem: If I configure the server to send to my @kindle.com email address (as described here: https://www.amazon.com/gp/sendtokindle/email) I get back an email telling me:

Your email to Kindle(s) did not include any attachments.

I'm using the following command to send the email with attachment:

echo "See attachment" | mail -s subject -aFrom:"$EMAIL_FROM" -A $EMAIL_FILE -r $EMAIL_FROM $EMAIL_TO

I tested this command by sending it to my personal email address instead of the @kindle.com one. The email appeared correctly with attachment in my personal inbox.

Interestingly it works fine (as in the ebook appears on my kindle) if I use mutt like this:

echo "See attachment" | mutt -s subject -a $EMAIL_FILE -- $EMAIL_TO

I'm using postfix to forward the emails to a hosted smtp server. I already checked the postfix logs (/var/log/mail.log) but couldn't see any differences between the two methods above. The server is running Ubuntu 18.04.

Question: Why does it work with mutt but not with mail? How would I troubleshoot such an issue?

---

Requested information

The headers from mutt (Please let me know if I stripped out too much):

Delivered-To: [...]
Received: by 2002:a2e:9c0f:0:0:0:0:0 with SMTP id s15-v6csp1355528lji;
        Sat, 10 Nov 2018 10:47:03 -0800 (PST)
[... removed X-* ...]
[... removed ARC-* ...]
Date: Sat, 10 Nov 2018 18:46:44 +0000
From: [...]
To: [...]
Subject: mutt
Message-ID: <20181110184643.GA23337@server>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="5mCyUwZo2JvN/JJP"
Content-Disposition: inline
User-Agent: Mutt/1.9.4 (2018-02-28)
[... removed X-* ...]

--5mCyUwZo2JvN/JJP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

See attachment

--5mCyUwZo2JvN/JJP
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="20181024T0942.mobi"
Content-Transfer-Encoding: base64


--5mCyUwZo2JvN/JJP--

Headers from mail:

Delivered-To: [...]
Received: by 2002:a2e:9c0f:0:0:0:0:0 with SMTP id s15-v6csp1355767lji;
        Sat, 10 Nov 2018 10:47:23 -0800 (PST)
[... removed X-* ...]
[... removed ARC-* ...]
MIME-Version: 1.0
Content-Type: application/octet-stream; name="20181024T0942.mobi"
Content-Transfer-Encoding: base64
Subject: mail
To: [...]
X-Mailer: mail (GNU Mailutils 3.4)
Message-Id: <20181110184707.B984A5EAE4@server.localdomain>
Date: Sat, 10 Nov 2018 18:47:07 +0000 (UTC)
From: [...]
[... removed X-* ...]

Upon closer inspection I noticed that the one from mail is missing the text "See attachment".

Versions:

jonas@server:~$ mutt -v
Mutt 1.9.4 (2018-02-28)
[...]   

jonas@server:~$ mail --version
mail (GNU Mailutils) 3.4
[...]

jonas@server:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.1 LTS
Release:    18.04
Codename:   bionic

According to the man page on the server I'm using -A correctly:

   -A, --attach=FILE
          attach FILE

   -a, --append=HEADER: VALUE append given header to the message being sent

Answer 1

I'm fairly sure what is happening here is that your mail program is sending its attachments using uuencode format, while mutt sends them in MIME format.

uuencode is an outdated email format and has been largely superceded by MIME, so I wouldn't be surprised that the handler for @kindle.com would not be able to recognize uuencode format, only MIME.

It's hard to tell how your mail command will behave (from your question) since there are many implementations of mail shipped by different Linux distributions (many of which do not even support attachments at all.) If you give more details about your Linux distribution, package which owns the mail binary and perhaps some reference from man mail, we can try to confirm that. (Also, perhaps the man page might have details about using uuencode format for attachments or MIME support or lack thereof. Look there to see if you find more.)

One way to confirm this is to send mail with attachments to yourself using both mail and mutt and look at the raw email body. You should be able to tell whether it looks like uuencode or MIME.

uuencode looks something like this:

begin 644 myebook.pdf

While MIME looks like this:

Content-Type: application/pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=myebook.pdf

---

UPDATE: From the headers you included, it looks like your mailer is using MIME, but as you noticed yourself, it's not sending the file as an attachment (which would have been marked with Content-Disposition: attachment), but as the main body of the email (ignoring the body you supplied.)

The GNU mailutils documentation on MIME implies that this should work as you expected to, for instance it states:

All the examples above will enter the usual interactive shell, allowing you to compose the body of the message. If that’s not needed, the non-interactive use can be forced by redirecting /dev/null to the standard input, e.g.:

$ mail --attach=archive.tar < /dev/null

My understanding of the "interactive shell" is that it's waiting for you to type the message body, but accepts commands starting with a special character (~), which makes it a command interpreter too.

Perhaps try to use mail without piping the body into it, to see if it's expecting some input, and then see if it accepts an email body if you type it directly?

Answer 2

There are a lot of different programs that go by the name mail. Assuming you have nail, which later turned into "heirloom mail", then it looks like you have used -A and -a backwards. Capital is for account, lowercase is for file to attach. I agree with the comment by Mark Plotnik that you should provide the headers. It's also possible that the kindle is ignoring certain MIME-types and mail and mutt work differently.