This problem seems to have arisen since the recent Gmail changes.
I can send emails fine using msmtp, but if I use mpack (I want to be
able to email files) I run into problems. The return code (echo $?)
from mpack is 0, but after about 30 seconds, I get the following email
to the local mail box on the Pi.
--394963F55A.1659185921/pi2
Content-Description: Delivery report
Content-Type: message/delivery-status
Reporting-MTA: dns; pi2
X-Postfix-Queue-ID: 394963F55A
X-Postfix-Sender: rfc822; pi@pi2.ffoil.org.uk
Arrival-Date: Sat, 30 Jul 2022 12:58:35 +0000 (UTC)
Final-Recipient: rfc822; myaddress@gmail.com
Original-Recipient: rfc822;myaddress@gmail.com
Action: failed
Status: 5.7.26
Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 550-5.7.26 This message does not pass
authentication
checks (SPF and DKIM both 550-5.7.26 do not pass). SPF check for
[pi2.ffoil.org.uk] does not pass 550-5.7.26 with ip:
[81.187.18.146].To best protect our users from spam, the 550-5.7.26 message
has been blocked. Please visit 550-5.7.26
https://support.google.com/mail/answer/81126#authentication for more
550
5.7.26 information.
o6-20020a05600002c600b0021e8c772ea6si4998559wry.1022 -
gsmtp
Diagnostic-Code: smtp; 550-5.7.26 This message does not pass...
authentication
checks (SPF and DKIM both 550-5.7.26 do not pass). SPF check for
[pi2.ffoil.org.uk] does not pass 550-5.7.26 with ip:
[81.187.18.146].To best protect our users from spam, the 550-5.7.26 message
has been blocked. Please visit 550-5.7.26
https://support.google.com/mail/answer/81126#authentication for more
550
5.7.26 information.
From: pi@pi2.ffoil.org.uk
You have to enable 2FA in your gmail account and then under security, obtain >an app-specific password which you use instead of any previous password when >logging into gmail's SMTP from your app.
Google is telling you the SPF and DKIM are wrong: the address you're
sending from (81.187.18.146: Andrews and Arnold, Chichester) doesn't match >the SPF for pi2.ffoil.org.uk (which appears to be set at your domain >registrar, presumably for your ffoil.org.uk email).
Since pi2.ffoil.org.uk doesn't exist in the DNS, I suspect you've >misconfigured your email client to send from a nonexistent address and
Google is not letting you do that. You need to set the From: header to be
a valid address, preferably one already set in your Gmail account.
In message <jkkse2F75o0U1@mid.individual.net>, TimS
<timstreater@greenbee.net> writes
You have to enable 2FA in your gmail account and then under security, obtain >>an app-specific password which you use instead of any previous password when >>logging into gmail's SMTP from your app.
So far as I can tell, this has already been done. I can send via the
same route using msmtp, and so far as I can tell mpack uses the same
conf file as msmtp.
On 2022-07-30, Adrian <bulleid@ku.gro.lioff> wrote:
In message <jkkse2F75o0U1@mid.individual.net>, TimS >><timstreater@greenbee.net> writes
You have to enable 2FA in your gmail account and then under security, obtain >>>an app-specific password which you use instead of any previous password when >>>logging into gmail's SMTP from your app.
So far as I can tell, this has already been done. I can send via the
same route using msmtp, and so far as I can tell mpack uses the same
conf file as msmtp.
Have you tried to use mpack to just create a named file of the mail. Then use >msmtp to send the file?
You could inspect the file generated to see what has been set in the headers, >and alter the from field etc if necessary.
No, I haven't tried it, the thought hadn't occurred to me. I'll give
it a go and report back.
In message <QG+GIsU6iX+iFwxT@ku.gro.lloiff>, Adrian
<bulleid@ku.gro.lioff> writes
No, I haven't tried it, the thought hadn't occurred to me. I'll give
it a go and report back.
Hmm, well it sort of works.
I can run mpack against the image that I want to send, and it creates an output file, but there is no addressing information with it :
Message-ID: <10695.1660569414@pi2>
Mime-Version: 1.0
Subject: Front Door Alert
Content-Type: multipart/mixed; boundary="-"
This is a MIME encoded message. Decode it with "munpack"
or any other MIME reading software. Mpack/munpack is available
via anonymous FTP in ftp.andrew.cmu.edu:pub/mpack/
---
Content-Type: image/jpeg; name="image_202208151316.jpg" Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="image_202208151316.jpg"
Content-MD5: 7YS3HQC2BvZxh142Go44Xg==
and then into the encoded version of the image.
Mpack won't allow me to add a destination address if the output is to a
file (rather than as an email).
I can then cat that into msmtp (after some header information), and the
email duly appears. So far, so good. The problem now is that I don't
have a jpg file (as such), I've got a base64 encoding of it, and my
(Android) phone won't convert that back into a usable JPG (one that I
can look at),
Ok you can add the From: and To: to the file created by mpack before
sending with msmtp.
When using mpack use the '-c' option to specify the mime type of the
file being packed.
-c image/jpeg
For other files you can probably use
xdg-mime query filetype /tmp/tmpfile
to find to right mime type to specify. Dunno why mpack changes it
behaviour between the 2 cases.
It should be easy to script this.
Ok you can add the From: and To: to the file created by mpack before
sending with msmtp.
When using mpack use the '-c' option to specify the mime type of the
file being packed.
-c image/jpeg
mpack -a -s "Front Door Alert" -c image/jpeg -o
output_file <file>
Sadly, that doesn't seem to work either.
The email gets through (as expected), but the
image isn't view able :
Message-ID: <822.1660721985@pi2>
Mime-Version: 1.0
Subject: Front Door Alert
Content-Type: multipart/mixed; boundary="-"
This is a MIME encoded message. Decode it with
"munpack"
or any other MIME reading software.
Mpack/munpack is available
via anonymous FTP in ftp.andrew.cmu.edu:pub/mpack/
---
Content-Type: image/jpeg; name="image_202208170739.jpg" Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="image_202208170739.jpg"
In message <slrntfmote.2ni.jj@iridium.wf32df>, Jim Jackson
<jj@franjam.org.uk> writes
Ok you can add the From: and To: to the file created by mpack before >>sending with msmtp.
When using mpack use the '-c' option to specify the mime type of the
file being packed.
-c image/jpeg
mpack -a -s "Front Door Alert" -c image/jpeg -o output_file <file>
Sadly, that doesn't seem to work either.
The email gets through (as expected), but the image isn't view able :
Message-ID: <822.1660721985@pi2>
Mime-Version: 1.0
Subject: Front Door Alert
Content-Type: multipart/mixed; boundary="-"
This is a MIME encoded message. Decode it with "munpack"
or any other MIME reading software. Mpack/munpack is available
via anonymous FTP in ftp.andrew.cmu.edu:pub/mpack/
---
Content-Type: image/jpeg; name="image_202208170739.jpg" Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="image_202208170739.jpg" Content-MD5: 2II3sSh8sqvNYfHOZVinnw==
Possible not relevant, but there is a quirk. If output_file exists,
mpack fails, it won't overwrite it.
Adrian
I'm sure there's a comp.mail.* group that's relevant, but I won't just
add the crosspost. (.mime is better, .misc is more active)
You are using -a to make this an attachment instead of inline. Is that
the source of the problem?
I just did some playing with mpack myself. The output is compliant with >mid-90s RFCs (eg RFC-2046), I am not up on more modern standards, but it
is very quirky looking compared to modern MIME encoding.
Tell me, have you tried using a description file? Just, so you know, the >content is actually "multipart"?
mpack ... -d /dev/null ...
Works as well (or badly :^) ) as using a text description.
Then there is probably something wrong with the android mail reader app.
Actually when I used tested this proceedure I didn't use the "-a"
option. I edited the created file with a To: line and a From: line and
sent the email to my main email which I read with alpine - but it
correctly identified the attached as an image and fired up the usual
image viewer when asked to. I also sent it to my google mail account and
it displayed there fine.
Eli the Bearded <*@eli.users.panix.com> writes
I just did some playing with mpack myself. The output is compliant with
mid-90s RFCs (eg RFC-2046), I am not up on more modern standards, but it
is very quirky looking compared to modern MIME encoding.
mpack -c image/jpeg -d /dev/null -o output_file <file>
gives :
Message-ID: <14058.1660767984@pi2>
Mime-Version: 1.0
Subject:
Content-Type: multipart/mixed; boundary="-"
This is a MIME encoded message. Decode it with "munpack"
or any other MIME reading software. Mpack/munpack is available
via anonymous FTP in ftp.andrew.cmu.edu:pub/mpack/
---
---
Content-Type: image/jpeg; name="image_202208172025.jpg" Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="image_202208172025.jpg"
Content-MD5: NhPEg4pgYEkaTbtZnOkNsg==
I'm assuming that the set of blank lines is the area for the
description.
You would be 100% correct. And the lack of headers on the description
part is a big "quriky" output.
BTW, if you just need a message composed with a single file of a known
type and no other frills, that's really easy to do via shell script. The >benefits of mpack are slim for that small use case.
You print your headers, with some particular mime details, you include
your base64 encoded image, and done. This is a super-bare-bones untested >version that has no multipart, just jpeg:
Looking at emails that I've been sent that have images attached, they
appear to be rather more complicated than what I'm getting so far:
<usual headers - irrelevant to here>
--000000000000539d6405e60d2bf0
Content-Type: multipart/alternative;
boundary="000000000000539d6205e60d2bef"
--000000000000539d6205e60d2bef
Content-Type: text/plain; charset="UTF-8"
[image: IMG_4665 (2).JPG]
<plain text version of mail body>
--000000000000539d6205e60d2bef
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html version of mail body>
--000000000000539d6205e60d2bef--
--000000000000539d6405e60d2bf0
Content-Type: image/jpeg; name="IMG_4665 (2).JPG"
Content-Disposition: inline; filename="IMG_4665 (2).JPG" Content-Transfer-Encoding: base64
Content-ID: <ii_l6qmw4qn0>
X-Attachment-Id: ii_l6qmw4qn0
<image in base64>
--000000000000539d6405e60d2bf0--
Switching to the multipart address script, rather than the simple
version it all appears to work. The email appears on my mail hosts
server, I can see an attachment (but not read it, this shouldn't be a problem, I rarely read emails directly on the server). The mail gets
copied to my Gmail account (where I can read it, and view the
attachment), and it also forwards to my home PC (which I'm not bothered about, but can live with), and I can view the attachment there as well.
Thanks to all those who've contributed. We have a solution that works
for me, but may not work for others.
Adrian
Switching to the multipart address script, rather than the simple
version it all appears to work.
On 29/08/2022 16:24, Adrian wrote:
Switching to the multipart address script, rather than the simple
version it all appears to work.
Yes. I believe I had to do that when emailing computer generated PDF invoices.
Ive got some php code that works if needs be.
On 29/08/2022 16:24, Adrian wrote:
Switching to the multipart address script, rather than the simple
version it all appears to work.
Yes. I believe I had to do that when emailing computer generated PDF >invoices.
Ive got some php code that works if needs be.
Eli the Bearded <*@eli.users.panix.com> writes
BTW, if you just need a message composed with a single file of a knownThanks for that. My apologies for the delay in replying, I was away.
type and no other frills, that's really easy to do via shell script. The
benefits of mpack are slim for that small use case.
You print your headers, with some particular mime details, you include
your base64 encoded image, and done. This is a super-bare-bones untested
version that has no multipart, just jpeg:
The good news is that the basic version of the script sort of works (the sendmail command needs the -t flag as well). The bad news is that it
only works if I send it to me@mydomain, but not a Gmail address, we are
back to the error in my original posting where it complains about SPF
and DKIM, but with no hint as to how to set that up for outgoing mails
from a Pi.
The mail server that I use allows me to set up rules. So, I set up a
rule for anything sent to somethingelse@mydomain, that sends a copy to
my Gmail address, no error messages, but the image still comes through embedded rather than attached (and so unreadable).
Looking at emails that I've been sent that have images attached, they
appear to be rather more complicated than what I'm getting so far:
<usual headers - irrelevant to here>
Switching to the multipart address script, rather than the simple
version it all appears to work. The email appears on my mail hosts
server, I can see an attachment (but not read it, this shouldn't be a problem, I rarely read emails directly on the server). The mail gets
copied to my Gmail account (where I can read it, and view the
attachment), and it also forwards to my home PC (which I'm not bothered about, but can live with), and I can view the attachment there as well.
Switching to the multipart address script, rather than the simple
version it all appears to work. The email appears on my mail hosts
server, I can see an attachment (but not read it, this shouldn't be a >problem, I rarely read emails directly on the server). The mail gets
copied to my Gmail account (where I can read it, and view the
attachment), and it also forwards to my home PC (which I'm not bothered >about, but can live with), and I can view the attachment there as well.
| Sysop: | Xerxes |
|---|---|
| Location: | Azle, Texas |
| Users: | 119 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 116:52:17 |
| Calls: | 3,023 |
| Calls today: | 5 |
| Files: | 156 |
| U/L today: |
0 files (0K bytes) |
| D/L today: |
0 files (0K bytes) |
| Messages: | 293,897 |
| Posted today: | 0 |