• Re: Error when sending via Gmail from mpack

    From TimS@3:770/3 to Adrian on Sat Jul 30 14:10:10 2022
    On 30 Jul 2022 at 14:40:16 BST, Adrian <bulleid@ku.gro.lioff> wrote:

    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

    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.

    --
    Tim

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Adrian@3:770/3 to All on Sat Jul 30 14:40:16 2022
    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

    --394963F55A.1659185921/pi2
    Content-Description: Undelivered Message Headers
    Content-Type: text/rfc822-headers
    Content-Transfer-Encoding: 8bit

    Return-Path: <pi@pi2.ffoil.org.uk>
    Received: by pi2 (Postfix, from userid 1000)
    id 394963F55A; Sat, 30 Jul 2022 12:58:35 +0000 (UTC)
    Message-ID: <27775.1659185916@pi2>
    Mime-Version: 1.0
    To: myaddress@gmail.com
    Subject: Front Door Alert
    Content-Type: multipart/mixed; boundary="-"
    Date: Sat, 30 Jul 2022 12:58:35 +0000 (UTC)
    From: pi@pi2.ffoil.org.uk

    --394963F55A.1659185921/pi2--

    My understanding is that mpack uses the same configuration files as
    msmtp (/etc/msmtprc), so the 16 character code that is now used instead
    of the password ought to get picked up there, however this is rather
    poorly documented online

    A search online for the error and mpack configuration has not proved
    fruitful. The Google link provided above doesn't really seem to help as
    the implication is that I need to set up some stuff, but it doesn't tell
    me how.

    Thanks in advance

    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to Adrian on Sat Jul 30 17:02:13 2022
    Adrian <bulleid@ku.gro.lioff> wrote:
    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

    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Adrian@3:770/3 to timstreater@greenbee.net on Sat Jul 30 18:33:58 2022
    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.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Adrian@3:770/3 to theom+news@chiark.greenend.org.uk on Sat Jul 30 18:59:07 2022
    In message <Thx*bwvUy@news.chiark.greenend.org.uk>, Theo <theom+news@chiark.greenend.org.uk> writes
    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.


    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 pi@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
    --
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Jim Jackson@3:770/3 to Adrian on Sun Aug 14 21:49:39 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Adrian@3:770/3 to jj@franjam.org.uk on Sun Aug 14 23:35:38 2022
    In message <slrntfirfj.f9c.jj@iridium.wf32df>, Jim Jackson
    <jj@franjam.org.uk> writes
    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.

    Thanks

    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Adrian@3:770/3 to bulleid@ku.gro.lioff on Mon Aug 15 20:00:40 2022
    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/
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Jim Jackson@3:770/3 to Adrian on Tue Aug 16 09:30:22 2022
    On 2022-08-15, Adrian <bulleid@ku.gro.lioff> wrote:
    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.

    cheers
    Jim

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Adrian@3:770/3 to jj@franjam.org.uk on Tue Aug 16 20:04:33 2022
    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

    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.


    Thanks, I'll have another look.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Adrian@3:770/3 to jj@franjam.org.uk on Wed Aug 17 08:51:56 2022
    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/
    Possible not relevant, but there is a quirk. If output_file exists,
    mpack fails, it won't overwrite it.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Eli the Bearded@3:770/3 to bulleid@ffoil.org.uk on Wed Aug 17 19:17:30 2022
    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)

    In comp.sys.raspberry-pi, Adrian <bulleid@ffoil.org.uk> wrote:
    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="-"

    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.

    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/

    Sadly that no longer resolves.

    ---
    Content-Type: image/jpeg; name="image_202208170739.jpg" Content-Transfer-Encoding: base64
    Content-Disposition: attachment; filename="image_202208170739.jpg"

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Jim Jackson@3:770/3 to Adrian on Wed Aug 17 20:33:03 2022
    On 2022-08-17, Adrian <bulleid@ku.gro.lioff> wrote:
    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 :

    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


    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Adrian@3:770/3 to *@eli.users.panix.com on Wed Aug 17 21:49:53 2022
    In message <eli$2208171435@qaz.wtf>, Eli the Bearded
    <*@eli.users.panix.com> writes
    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)


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

    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.


    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/
    I'm assuming that the set of blank lines is the area for the
    description.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Adrian@3:770/3 to jj@franjam.org.uk on Wed Aug 17 22:25:07 2022
    In message <slrntfqk3v.6bc.jj@iridium.wf32df>, Jim Jackson
    <jj@franjam.org.uk> writes
    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.


    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/
    ---
    Content-Type: image/jpeg; name="image_202207301606.jpg" Content-Transfer-Encoding: base64
    Content-Disposition: inline; filename="image_202207301606.jpg"
    Content-MD5: qCv/c/gqGzcMFAdqCipxvA==

    I've tried editing out the first few lines from the output file (which
    appear above the "This is a MIME" line), which means that what is sent
    via msmtp ought to have the same information that the mpack version has,
    but the jpeg still appears as an inline base64 file, rather than as an
    image.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Eli the Bearded@3:770/3 to bulleid@ffoil.org.uk on Fri Aug 19 17:48:41 2022
    In comp.sys.raspberry-pi, Adrian <bulleid@ffoil.org.uk> wrote:
    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:

    #!/bin/sh
    file="$1"
    if [ ! -f "$file" ] ; then
    echo 'Usage:'
    echo ' echo "To: foo@bar" > output'
    echo ' echo "From: bar@foo" >> output'
    echo ' echo "Subject: qux" >> output'
    echo ' composer jpegfile >> output'
    echo ''
    echo 'Then send with eg, sendmail -oi < output'
    exit 2
    fi

    # simple JPEG as body email
    echo 'Mime-Version: 1.0
    echo 'Content-Type: image/jpeg; name="'"$file"'"'
    echo 'Content-Transfer-Encoding: base64'
    echo 'Content-Disposition: inline; filename="'"$file"'"'
    echo ''
    base64 "$file"
    echo ''

    exit

    And this is a multipart example:

    #!/bin/sh
    file="$1"
    desc="$2"
    if [ ! -f "$desc" ] ; then
    echo 'Usage:'
    echo ' echo "To: foo@bar" > output'
    echo ' echo "From: bar@foo" >> output'
    echo ' echo "Subject: qux" >> output'
    echo ' multicomposer jpegfile description.txt >> output'
    echo ''
    echo 'Then send with eg, sendmail -oi < output'
    exit 2
    fi

    # simple multipart with text and jpeg. The use of = and - means
    # that the boundary string cannot occur in base64 or quoted
    # printable content
    boundary=--==randomness--$$==--

    echo 'Mime-Version: 1.0
    echo 'Content-Type: multipart/mixed; boundary="'$boundary'"'
    echo ''

    # each part starts with named boundary plus two hyphens
    echo "--$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 "--$boundary"
    echo 'Content-Type: image/jpeg; name="'"$file"'"'
    echo 'Content-Transfer-Encoding: base64'
    echo 'Content-Disposition: inline; filename="'"$file"'"'
    echo ''
    base64 "$file"

    # final boundary is indicated with extra hyphens at end
    echo "--$boundary--"
    echo ''

    exit

    My mail software has a set of scripts evolved from Rnmail (in the rn/trn package) that does roughly this but includes a "vi $outfile" step before sendmail is used.

    Elijah
    ------
    added 'rnmail' as a command to the mailx he uses

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Adrian@3:770/3 to *@eli.users.panix.com on Mon Aug 29 16:24:32 2022
    In message <eli$2208191348@qaz.wtf>, Eli the Bearded
    <*@eli.users.panix.com> writes
    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:


    <snip bits of useful script>

    Thanks for that. My apologies for the delay in replying, I was away.

    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. Oh, and when I say that it sends to me@mydomain, I don't get
    a readable image, I still get the base64 text, so it isn't an attachment
    (as such), it is embedded in the body.

    <time delay>

    If in doubt, put the kettle on and have a think.

    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>

    --000000000000539d6405e60d2bf0
    Content-Type: multipart/alternative;
    boundary="000000000000539d6205e60d2bef"

    [image: IMG_4665 (2).JPG]

    <plain text version of mail body>

    <html version of mail body>

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From TimS@3:770/3 to Adrian on Mon Aug 29 17:32:27 2022
    On 29 Aug 2022 at 16:24:32 BST, Adrian <bulleid@ku.gro.lioff> wrote:

    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"

    I wpuld not expect the image to show up here.

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

    I would expect the image to show up here, with a bit of html such as:

    <img href="cid:ii_l6qmw4qn0">


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


    --
    Tim

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Adrian on Mon Aug 29 18:28:47 2022
    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.


    --
    "It is an established fact to 97% confidence limits that left wing
    conspirators see right wing conspiracies everywhere"

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Martin Gregorie@3:770/3 to The Natural Philosopher on Mon Aug 29 19:11:17 2022
    On Mon, 29 Aug 2022 18:28:47 +0100, The Natural Philosopher wrote:

    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.

    Sending via Postfix works too - all my outgoing mail is sent via Postfix
    on my house server.


    --

    Martin | martin at
    Gregorie | gregorie dot org

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Adrian@3:770/3 to tnp@invalid.invalid on Mon Aug 29 19:24:33 2022
    In message <teit0f$16ohq$2@dont-email.me>, The Natural Philosopher <tnp@invalid.invalid> writes
    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.



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

    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Eli the Bearded@3:770/3 to bulleid@ffoil.org.uk on Mon Aug 29 19:36:05 2022
    (Had some issues posting this, hope it doesn't show twice.)

    In comp.sys.raspberry-pi, Adrian <bulleid@ffoil.org.uk> wrote:
    Eli the Bearded <*@eli.users.panix.com> writes
    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:
    Thanks for that. My apologies for the delay in replying, I was away.

    No worries, Usenet should be slow.

    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.

    SPF I know how to do. DKIM is something I've never set up, but I have a
    rought idea.

    SPF is a rule attached to a domain that says where (IP address) it is
    expected mail will come from. If you send mail from somewhere outside
    that IP address range, when SPF says that's verbotten, it gets tossed.
    The rule is distributed as a TXT record in DNS for the FROM address.

    Here's what I have:

    $ dig +short qaz.wtf TXT
    "v=spf1 ip4:166.84.0.0/16 ip4:198.7.7.0/24 ?all"
    $

    Mail from @qaz.wtf should be sent from one of those two IP address
    ranges. The "?all" means that I'm not super confident in that. I'm
    surprised to have that, because I thought I had set it up as "-all"
    which means hard reject everything else. There's also "~all" for
    debugging test of "-all".

    https://en.wikipedia.org/wiki/Sender_Policy_Framework

    DKIM uses a cryptographic key distributed by DNS to sign a list
    of headers on email. The list of which headers are signed (because
    some are expected to change in transit) and the signature for them
    go into a DKIM-Signature header.

    https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail

    I've never set it up. DKIM is so trivial to implement and so useless in practice that spammers are slightly more likely to have DKIM. The only
    thing it protects against (in practice) is spoofing email from someone
    else. But when spammers can just churn new domains, having a signature
    like this (pulled from today's spam) is not exactly useful:

    DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=k1; d=abiconit.digital;
    h=Mime-Version:Content-Type:Date:From:Reply-To:Subject:To:Message-ID; i=killherpes@abiconit.digital;
    bh=ihA1H/o66IYzXraZKYoqcKVFltE=;
    b=ZnHEQtvoBNUORqBDvpPXSqf8OoSWd5KVAAO8OmZT8EN39T7e52jc7xwlVTOsAr7AhwqI9VpVYpSM
    c25O4So4cvgaHK8b78oE4/SRqdTzKvhCg2AOiekRJna/jSsbca4gmSo5K/JQlZ1C7SOOsdCbdTc4
    9mhwzf3hIJpnxGMZko8=
    DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=k1; d=abiconit.digital;
    b=iig5+hHws3m+UYScl7GI/FghybweF7MnR53FvZZelQR1RDvk98Wl7uHFAvM8mfRXLy7tLaMKM9Om
    M0nienwfDfue6m/DktQD9ATPgEhmjwOzdOXDMe+NjMrIVlSOUqBeGd8eTgtCBK2Bum/G+XiFdZuT
    Y/Bncp+Q7dBH201lG9E=;

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

    This may have to do with the way headers get added for forwarding.

    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>

    Probably not. I suspect that the main headers say "multipart/related" instead of "multipart/mixed". Here's simplified headers / body from a piece of email
    I have handy:

    Content-Type: multipart/related;
    boundary="--==_mimepart_outer-multipart-related"

    ----==_mimepart_outer-multipart-related
    Content-Type: multipart/alternative;
    boundary="--==_mimepart_inner-multipart-alternative"
    Content-Transfer-Encoding: 7bit

    ----==_mimepart_inner-multipart-alternative
    Content-Type: text/plain; charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    Content here in QP text.=20

    ----==_mimepart_inner-multipart-alternative
    Content-Type: text/html;
    charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    <p>Content here in QP html.</p>

    =3cimg src=3D"cid:this.contentid">

    ----==_mimepart_inner-multipart-alternative--

    ----==_mimepart_outer-multipart-related
    Content-Type: image/png; filename=some.png
    Content-Transfer-Encoding: base64
    Content-Disposition: inline; filename=some.png
    content-id: <this.contentid>
    X-Attachment-Id: this.contentid

    iVBORw0KGgoAAAAN...

    ----==_mimepart_outer-multipart-related--

    multipart/mixed :
    content plus attachment

    multipart/alternative :
    content in multiple forms

    multipart/related :
    content that uses other parts of the content (typically
    a wrapper around mp/a or mp/m)

    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.

    Well simple things like email can sure be a saga, huh?

    I've set up my email so I'm always reading text/plain from xterms and
    the mailer gives me (password protected) URLs to view attachments and
    "inline" images.

    Elijah
    ------
    also doesn't expect his email system to work for everyone

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Adrian@3:770/3 to bulleid@ku.gro.lioff on Sat Sep 3 13:42:19 2022
    In message <XHU22bPwoNDjFw8H@ku.gro.lloiff>, Adrian
    <bulleid@ku.gro.lioff> writes
    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.


    I've had another session with this, and further improved it. I tried
    cat'ing the file (consisting of the headers, body, attachment etc.
    generated by Eli's script) into msmtp :

    cat /tmp/output | msmtp $addressee

    and that works. My msmtp configuration is set up to use a Gmail account
    to send from, so that avoids having to do anything fancy on my mail
    hosts server, and I don't get an unwanted copy of the email sent to me@mydomain. Basically I'm back to where I was earlier in the year
    before Gmail made their changes.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)