Error when sending via Gmail from mpack

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.

Theo

In message snipped-for-privacy@mid.individual.net>, TimS snipped-for-privacy@greenbee.net writes

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.

Adrian

In message <Thx* snipped-for-privacy@news.chiark.greenend.org.uk>, Theo <theom+ snipped-for-privacy@chiark.greenend.org.uk> writes

Thanks.

The problem is (I think), that I can't find a way of configuring the client (mpack). There is no command line option for setting the "from" field. From what little I've been able to find out, it uses the same config file that msmtp uses, and that works quite happily with msmtp. The /etc/msmtprc file sets the domain as ffoil.org.uk, and the "from" has a valid address on that domain. However, I have a suspicion that it is only using the bits that it needs to connect to the mail server.

However, the plot thickens. Since my OP, I've had an email with attachment sent from my Pi using mpack, and that without my changing anything. That has snipped-for-privacy@pi2.ffoil.org.uk as the "from". Whilst I'm not disputing what you are saying above (it makes sense to me), it looks as though it is more subtle than that, otherwise I'd get a 100% failure rate, whereas it seems that I'm getting a high (but not consistent) failure rate.

Adrian

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.

Thanks

Adrian

In message <QG+GIsU6iX+ snipped-for-privacy@ku.gro.lloiff>, Adrian snipped-for-privacy@ku.gro.lioff> writes

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), whereas when I can get mpack to work (which it does occasionally), I can see the image in the body of the email, no extra work required.

Adrian

-- To Reply : replace "bulleid" with "adrian" - all mail to bulleid is rejected Sorry for the rigmarole, If I want spam, I'll go to the shops Every time someone says "I don't believe in trolls", another one dies.

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.

cheers Jim

In message snipped-for-privacy@iridium.wfdf, Jim Jackson snipped-for-privacy@franjam.org.uk> writes

Thanks, I'll have another look.

Adrian

In message snipped-for-privacy@iridium.wfdf, Jim Jackson snipped-for-privacy@franjam.org.uk> writes

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/

That's an insanely short boundary. I'm wondering if that's the issue. My home-grown mailer uses ones like

boundary="--=bind19830=--"

Base64 content won't contain '---', so it's techically safe and legal but very startling.

Sadly that no longer resolves.

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.

Elijah

------ found mpack silently edited description lines starting with ---

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.

Jim

In message <eli$ snipped-for-privacy@qaz.wtf, Eli the Bearded <*@eli.users.panix.com> writes

Thanks, this may yet end up there, it probably isn't strictly a Pi problem.

I don't think the -a is making any difference.

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/

In message snipped-for-privacy@iridium.wfdf, Jim Jackson snipped-for-privacy@franjam.org.uk> writes

Thanks, but you seem to be seeing something different to me.

Whilst the intention is to read the emails (*) using Android, I can't read them using either Thunderbird or Turnpike either. I get the same outcome as I do with the Android reader (the Gmail app used on a tablet and a phone). I can see the attachment, but it is in base64 encoded version, not as a readily view able jpg image.

• on the odd occasions that the image being sent directly by mpack works (Gmail occasionally accepts the outgoing message), the image is directly readable using the Gmail app and Thunderbird (and at a guess by Turnpike). I generally delete them, but I've still got one sitting around, but it doesn't look radically different :

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/

$boundary" echo 'Content-Type: text/plain; charset="UTF-8"' # echo 'Content-Transfer-Encoding: quoted-printable; echo '' # if you have it, consider "mmencode -q < $desc" to quoted-printable # encode body cat $desc echo ''

echo "

Yes. I believe I had to do that when emailing computer generated PDF invoices.

Ive got some php code that works if needs be.

I wpuld not expect the image to show up here.

Thanks for the offer, but the Bash script appears to be working fine.

Adrian