bugGNU Mailutils - Bugs: bug #54992, mail.mailutils ignores stdin when...

 
 

bug #54992: mail.mailutils ignores stdin when mailing attachment

Submitter:  Johannes Martin <jmartin>
Submitted:  Fri 09 Nov 2018 09:42:13 AM UTC
Votes: 100
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  gray
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 30 Nov 2020 12:32:41 PM UTC, comment #18: 

comment #17:

> You would also need the commit 3a1556505018cad44609c3a759bf3db744469a77.


Ok. Thank you for clarifying it.

Krzysztof Kozłowski <kozlowski9ld>
Mon 30 Nov 2020 11:11:54 AM UTC, comment #17: 

You would also need the commit 3a1556505018cad44609c3a759bf3db744469a77.

Sergey Poznyakoff <gray>
Group administrator
Mon 30 Nov 2020 10:21:24 AM UTC, comment #16: 

comment #15:

> Commit 4321418509 is dated 2019-03-13, while version 3.4 was released on 2017-11-02.  Quite naturally, the bug is still there.
> You need mailutils 3.7 or newer.


Right, I understand that the bug is still there, I was just hoping that the workaround suggested here would work, but it seems it doesn't.
Or maybe there is a better one?

Krzysztof Kozłowski <kozlowski9ld>
Mon 30 Nov 2020 10:02:02 AM UTC, comment #15: 

Commit 4321418509 is dated 2019-03-13, while version 3.4 was released on 2017-11-02.  Quite naturally, the bug is still there.
You need mailutils 3.7 or newer.

Sergey Poznyakoff <gray>
Group administrator
Mon 30 Nov 2020 07:59:20 AM UTC, comment #14: 

comment #7:

> It was fixed in 43214185092e714e0c233bf196f571bba5c17be0. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918806#22 for details


I'm trying to use the --mime workaround in mailutils 3.4, which is still the official version on Ubuntu 18, but it doesn't seem to help with the problem there.

Krzysztof Kozłowski <kozlowski9ld>
Tue 17 Dec 2019 10:42:10 AM UTC, comment #13: 


> But in v3.0 if i use the absolute pathname, i only see the relative name, thats why im pointing this out.


Hmm, indeed.  Thanks for noticing.  v3.0 is quite old, it's a pleasure to know it's still being used.

> It never used to show the absolute pathname when using absolute pathname.


Correction: it used to strip directory component until Fri Jan 13 14:45:09 2017.  One of the changes introduced by commit eabddf8f was to include full pathname unless --content-filename was used.

After some consideration, I agree that the new behavior is problematic. Since this bug has entirely different nature compared to the previous two we discussed in this issue, I have assigned a separate issue for it.  For updates and further discussions, please, see bug #57431.

As to this issue, I'm closing it as fixed.

Sergey Poznyakoff <gray>
Group administrator
Mon 16 Dec 2019 07:00:38 PM UTC, comment #12: 


> > Seems like another bug? 
>
> I don't think so. In theory, it is possible to strip directory components out of the file name, but I don't remember any RFC requiring mail user agent to do so.  Besides, it is not quite clear how many directory components to strip off.  And, last but not the least, I have reasons to suspect that should I implement directory component stripping, I'd start receiving complaints that mail is not behaving the way it used to.


But in v3.0 if i use the absolute pathname, i only see the relative name, thats why im pointing this out. And what if the file is in a different dir?
It never used to show the absolute pathname when using absolute pathname.

ny234 <ny234>
Mon 16 Dec 2019 05:43:58 PM UTC, comment #11: 

Thank you.

> However another small issue is that the attachment below shows the full path of the file instead of the name of the file on its own, like it used to be.


Mailutils never stripped any directory components from the file name.  If you see absolute pathname, that means that you specified this name with the -A option (e.g. -A /home/test/test2.7z).  Try using the relative name instead (-A test2.7z).

> Seems like another bug? 


I don't think so. In theory, it is possible to strip directory components out of the file name, but I don't remember any RFC requiring mail user agent to do so.  Besides, it is not quite clear how many directory components to strip off.  And, last but not the least, I have reasons to suspect that should I implement directory component stripping, I'd start receiving complaints that mail is not behaving the way it used to.

> Please could you push the fix for both of these bugs for Ubuntu 18.04 v3.5?


Unfortunately, that's beyond my authority.  I have no relation to Ubuntu.  For what it's worth, I have no relation to any particular GNU/Linux distribution at all.  For that, please contact the corresponding distribution maintainer.  For Ubuntu, I believe you should find all necessary information here: https://www.debian.org/distrib/packages.

Sergey Poznyakoff <gray>
Group administrator
Mon 16 Dec 2019 04:12:24 PM UTC, comment #10: 


comment #9:

> Thanks for the report. Please try this patch:
> http://git.savannah.gnu.org/cgit/mailutils.git/patch/?id=3a1556505018cad44609c3a759bf3db744469a77


I included the patch in v3.8, re-compiled and installed and it seems to be working now. thank you!

However another small issue is that the attachment below shows the full path of the file instead of the name of the file on its own, like it used to be. Seems like another bug?

Content-Type: application/octet-stream; name="test2.7z"
Content-Disposition: attachment; filename="/home/test/test2.7z"
Content-Transfer-Encoding: base64
Content-ID: <20191216150736.3422.1@test>

I have to use this, to rename it --content-filename=name

Please could you push the fix for both of these bugs for Ubuntu 18.04 v3.5? Would appreciate this as it is very time-consuming to re-compile for many pc's

ny234 <ny234>
Sun 15 Dec 2019 07:30:03 PM UTC, comment #9: 
Sergey Poznyakoff <gray>
Group administrator
Sat 14 Dec 2019 09:01:19 PM UTC, comment #8: 

comment #7:

> It was fixed in 43214185092e714e0c233bf196f571bba5c17be0. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918806#22 for details


For me on Ubuntu 18.04, this bug still persists in the following versions of mailutils 3.5, 3.6, 3.8.  The only version this works in is a compiled 3.0 version.
I have built and compiled all above latest versions, but i am still getting a noname.txt attachment together with the original attachment instead of both the original attachment & the actual message in the Body.

I am using this one-liner:
echo "This is the Body" | "/usr/local/bin/mail" "$ToMail" -r "$FromMail" -s "$Subject" -A test.txt

Please reproduce and advise.

ny234 <ny234>
Mon 18 Mar 2019 06:22:00 PM UTC, comment #7: 

It was fixed in 43214185092e714e0c233bf196f571bba5c17be0. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918806#22 for details

Sergey Poznyakoff <gray>
Group administrator
Mon 18 Mar 2019 04:49:43 PM UTC, comment #6: 

I am using Ubuntu 18.04 LTS, GNU Mailutils 3.4 and MSMTP 1.6.6 to send an e-mail, containing an attachment, from a Bash script (and/or testing from the command line) using a GMail account for sending and another GMail account for receiving:


echo "This is the body of the e-mail" | mail address@example.com -s "This is the subject" -A /file/path/file.txt


This results in an e-mail with the attachment but no text in the body of the e-mail. If I send the same e-mail without the attachment, the text appears in the body of the e-mail.

Jason Pope <boards188>
Tue 05 Feb 2019 08:57:20 AM UTC, comment #5: 

I successfully sent a message with attachment + rfc822 text to postfix using:

echo foo | mail --content-type=application/pdf --content-filename=file.pdf --attach=file.pdf --subject="My Subject" --content-type=text/plain --alternative

But not all mailservers accept the attachment. MS Exchange seems to strip it.

Is there no way to send an attachment + text from a shell script with standard gnu mail? What am I doing wrong?

Daniel Hiepler <rigid>
Fri 09 Nov 2018 01:10:41 PM UTC, comment #4: 

The only difference between mails sent by 3.1 and 3.5 is that 3.5 always adds the Content-Disposition header and includes the
charset and name variables to the Content-Type type header of each attachment (in accordance with RFC2183 and RFC4229).

All in all, it looks as a bug-report to ME, rather than to GNU mailutils.

Sergey Poznyakoff <gray>
Group administrator
Fri 09 Nov 2018 12:28:53 PM UTC, comment #3: 

Sorry, it seems like this is another szenario where Microsoft Exchange messes up. When I send the mail to a non-exchange domain, it arrives fine, only when my employer's exchange server is handling the recipient domain, the contents are corrupted (body removed and replaced by copy of attachment).

I'm not sure what exactly is different in the mails that causes exchange to mess up mails sent from mailutils 3.4 and up but no those from 3.1 and below.

Johannes Martin <jmartin>
Fri 09 Nov 2018 12:16:38 PM UTC, comment #2: 

That's strange. I just downloaded mailutils 3.5 and compiled if from sources on a freshly installed debian/testing system:

From the compilation directory:
./mail/mail --version | ./mail/mail --content-type=text/plain --attach=/etc/issue -s test -email is unavailable-

Same result as with mailutils 3.5 from the debian repository (missing body).

Johannes Martin <jmartin>
Fri 09 Nov 2018 11:11:08 AM UTC, comment #1: 

Can't reproduce it with mailutils 3.5

Sergey Poznyakoff <gray>
Group administrator
Fri 09 Nov 2018 09:42:13 AM UTC, original submission:  

Since mailutils 3.4, mail.mailutils ignores stdin (the mail body) when an attachment is specified on the command line.

Test case:
LANG=C mail.mailutils --version | mail.mailutils --content-type=text/plain --attach=/etc/issue -s test -email is unavailable-

mailutils up to and including 3.1 sends an email with the output of mail.mailutils --version as body and the contents of /etc/issue as attachment.

mailutils from 3.4 on (also tested 3.5) sends an email with the contents of /etc/issue as both the mail body and attachment.

Tested on Ubuntu (14.04, 16.04, 18.04) and Debian (stretch, buster, sid).

The problem also occurs if stdin is a tty rather than a pipe.

Johannes Martin <jmartin>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by kozlowski9ld (Posted a comment)
  • -email is unavailable- added by ny234 (Posted a comment)
  • -email is unavailable- added by boards188 (Posted a comment)
  • -email is unavailable- added by rigid (Posted a comment)
  • -email is unavailable- added by rigid (Voted in favor of this item)
  • -email is unavailable- added by gray (Posted a comment)
  • -email is unavailable- added by jmartin (Submitted the item)
  •  

    There are 100 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-12-17 gray Open/ClosedOpen Closed
    2019-12-16 gray StatusNeed Info Fixed
    2019-12-15 gray StatusFixed Need Info
    2019-03-18 gray StatusWorks For Me Fixed
    2019-02-05 rigid Carbon-Copy- Added rigid
    2018-11-09 gray StatusNone Works For Me
        Assigned toNone gray

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code