將帶有 GNU 郵件的附件發送到 @kindle.com

背景：我正在嘗試設置一個伺服器來定期提取 RSS 提要，將它們打包在移動電子書中並將它們發送到我的 kindle。

問題：如果我將伺服器配置為發送到我的@kindle.com 電子郵件地址（如此處所述：https ://www.amazon.com/gp/sendtokindle/email ），我會收到一封電子郵件告訴我：

您發送給 Kindle 的電子郵件不包含任何附件。

我正在使用以下命令發送帶有附件的電子郵件：

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

我通過將它發送到我的個人電子郵件地址而不是@kindle.com 來測試這個命令。電子郵件在我的個人收件箱中正確顯示，並帶有附件。

有趣的是，如果我像這樣使用 mutt，它可以正常工作（就像電子書出現在我的 kindle 上一樣）：

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

我正在使用 postfix 將電子郵件轉發到託管的 smtp 伺服器。我已經檢查了後綴日誌 ( /var/log/mail.log)，但看不到上述兩種方法之間的任何差異。伺服器正在執行 Ubuntu 18.04。

問題：為什麼它適用於mutt但不適用mail？我將如何解決此類問題？

---

要求的資訊

來自 mutt 的標題（如果我剝離太多，請告訴我）：

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

郵件標題：

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

仔細檢查後，我注意到來自mail的那個缺少文本“見附件”。

版本：

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

根據我-A正確使用的伺服器上的手冊頁：

  -A, --attach=FILE
         attach FILE

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

我很確定這裡發生的事情是您的mail程序使用 uuencode 格式發送其附件，而mutt以 MIME 格式發送它們。

uuencode 是一種過時的電子郵件格式，並且在很大程度上已被 MIME 取代，因此@kindle.com 的處理程序無法辨識 uuencode 格式，只能辨識 MIME，我不會感到驚訝。

很難判斷您的mail命令將如何執行（根據您的問題），因為mail不同的 Linux 發行版提供了許多實現（其中許多甚至根本不支持附件。）如果您提供有關 Linux 發行版的更多詳細資訊，請打包擁有mail二進製文件，也許還有一些參考man mail，我們可以嘗試確認。（另外，也許手冊頁可能有關於使用 uuencode 格式的附件或 MIME 支持或缺乏的詳細資訊。看看那裡，看看你是否找到更多。）

mail確認這一點的一種方法是使用和向自己發送帶有附件的郵件，mutt然後查看原始電子郵件正文。您應該能夠判斷它看起來像 uuencode 還是 MIME。

uuencode 看起來像這樣：

begin 644 myebook.pdf

雖然 MIME 看起來像這樣：

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

---

**更新：**從您包含的標題來看，您的郵件似乎正在使用 MIME，但正如您自己注意到的那樣，它不是將文件作為附件發送（它會被標記為Content-Disposition: attachment），而是作為電子郵件的主體（忽略你提供的身體。）

MIME 上的 GNU mailutils文件暗示這應該像您預期的那樣工作，例如它指出：

上面的所有範例都將進入通常的互動式 shell，允許您編寫消息的正文。如果不需要，可以通過將 /dev/null 重定向到標準輸入來強制非互動式使用，例如：

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

我對“互動式shell”的理解是，它在等待您輸入消息正文，但接受以特殊字元（~）開頭的命令，這也使其成為命令解釋器。

也許嘗試在mail不使用管道的情況下使用它，看看它是否需要一些輸入，然後如果你直接輸入它，看看它是否接受電子郵件正文？

引用自：https://unix.stackexchange.com/questions/480978