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-* ...]

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

See attachment

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


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".


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
  • I doubt it is on-topic debugging this unless it is a simple matter. If you send the email using mpack, does the attachment arrives? If it works, I can explain why. Nov 10 '18 at 16:55
  • Can you show us the diffs between the working and non-working emails? In particular, any header lines with mime types. Nov 10 '18 at 17:19
  • I had this problem with mutt. I solved it by adding a message body.
    – HappyFace
    Dec 9 '18 at 13:55

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?

  • 1
    My mail does use MIME, however it does look a bit odd to me compared to the one from mutt. Nov 10 '18 at 20:12
  • Updated the answer. From reading the docs, my understanding is that GNU mailutils should work as you're using it, but as you noticed yourself, it seems to be ignoring the message body... Try calling it without the pipe to see what happens there.
    – filbranden
    Nov 10 '18 at 22:12
  • Got the same problem, even without the pipe. I did find this bug report that sounds somewhat similar (although it's concluded that it's not a mailutils bug): savannah.gnu.org/bugs/?func=detailitem&item_id=54992 Nov 10 '18 at 22:49
  • Nice find on that bug, looks similar to what you report. They said the problem was with MS Exchange. If you have a different mail account to send it to (e.g. gmail) or if you can send it to a local user, maybe see if it's unmangled that way. Still, doesn't directly explain why @kindle.com would have a problem with it, unless they seem to have the same problem reported on that bug too...
    – filbranden
    Nov 10 '18 at 22:58

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.

  • I think I'm using it correctly. I've added an extract of the man page to the question. I'm using mail (GNU Mailutils) 3.4 Nov 10 '18 at 20:07
  • Yeah, that's a different mail program than I've used. My comments about the command line aren't relevant. Nov 11 '18 at 0:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.