Enviando anexos com o correio GNU para @ kindle.com

Question

Plano de fundo : Estou tentando configurar um servidor para receber regularmente feeds RSS, empacotá-los em um e-book e enviá-los ao meu Kindle.

Problema : Se eu configurar o servidor para enviar para o meu endereço de e-mail @ kindle.com (conforme descrito aqui: link ) Eu recebo um e-mail dizendo:

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

Estou usando o seguinte comando para enviar o email com anexo:

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

Eu testei este comando enviando-o para o meu endereço de e-mail pessoal em vez do endereço @ kindle.com. O email apareceu corretamente com o anexo na minha caixa de entrada pessoal.

Curiosamente, funciona bem (como no e-book aparece no meu kindle) se eu uso o mutt assim:

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

Estou usando o postfix para encaminhar os e-mails para um servidor smtp hospedado. Eu já verifiquei os logs do postfix ( /var/log/mail.log ), mas não vi nenhuma diferença entre os dois métodos acima. O servidor está executando o Ubuntu 18.04.

Pergunta : Por que funciona com mutt , mas não com mail ? Como eu resolveria um problema desse tipo?

Informações solicitadas

Os cabeçalhos de mutt (Por favor, deixe-me saber se eu tirei muito):

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

Cabeçalhos do e-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: <[email protected]>
Date: Sat, 10 Nov 2018 18:47:07 +0000 (UTC)
From: [...]
[... removed X-* ...]

Após uma inspeção mais próxima, notei que o texto de mail está faltando no texto "Ver anexo".

Versões:

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

De acordo com a página do manual no servidor, estou usando -A corretamente:

   -A, --attach=FILE
          attach FILE

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

    

Answer 1

Tenho quase certeza de que o que está acontecendo aqui é que o programa mail está enviando seus anexos usando o formato uuencode, enquanto mutt os envia no formato MIME.

uuencode é um formato de e-mail desatualizado e foi substituído pelo MIME, então eu não ficaria surpreso se o manipulador de @ kindle.com não fosse capaz de reconhecer o formato uuencode, apenas MIME.

É difícil dizer como o comando mail se comportará (a partir de sua pergunta), pois há muitas implementações de mail enviadas por diferentes distribuições Linux (muitas das quais nem sequer suportam anexos). mais detalhes sobre sua distribuição Linux, pacote que possui o binário mail e talvez alguma referência de man mail , podemos tentar confirmar isso. (Além disso, talvez a página man possa ter detalhes sobre o uso do formato uuencode para anexos ou suporte a MIME ou a falta dele. Veja lá para ver se você encontra mais.)

Uma maneira de confirmar isso é enviar e-mails com anexos para você mesmo usando mail e mutt e observe o corpo do e-mail bruto. Você deve ser capaz de dizer se parece com uuencode ou MIME.

uuencode é algo como isto:

begin 644 myebook.pdf

Enquanto o MIME é assim:

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

UPDATE: Nos cabeçalhos que você incluiu, parece que o seu mailer é usando MIME, mas como você percebeu, ele não está enviando o arquivo como um anexo (o que teria sido marcado com Content-Disposition: attachment ), mas como o corpo principal do email (ignorando o corpo que você forneceu.)

A documentação do GNU mailutils no MIME indica que isso deve funcionar como você esperava, por exemplo:

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

Meu entendimento do "shell interativo" é que ele está esperando que você digite o corpo da mensagem, mas aceita comandos que começam com um caractere especial (~), o que o torna um interpretador de comandos também.

Talvez tente usar mail sem canalizar o corpo para ele, para ver se ele está esperando alguma entrada e, em seguida, veja se ele aceita um corpo de e-mail se você o digitar diretamente?

    

Answer 2

Existem muitos programas diferentes que usam o nome mail . Supondo que você tenha nail , que mais tarde se transformou em "e-mail de herança", parece que você usou -A e -a para trás. Capital é por conta, em minúsculas é para arquivo para anexar. Concordo com o comentário de Mark Plotnik de que você deve fornecer os cabeçalhos. Também é possível que o Kindle esteja ignorando certos tipos MIME e mail e mutt funcionem de maneira diferente.