From: sirjofri <sirjofri+ml-9front@sirjofri.de>
To: 9front@9front.org
Subject: Re: [9front] [Bug] Mail fails to send attachments
Date: Sat, 20 Feb 2021 13:02:05 +0000 (UTC) [thread overview]
Message-ID: <113789e3-82f3-4c5e-b68f-d1c786dfd11c@sirjofri.de> (raw)
In-Reply-To: <B715E6C5294F35E59811788D81B9D626@eigenstate.org>
Hello,
20.02.2021 01:49:09 ori@eigenstate.org:
> Quoth sirjofri <sirjofri+ml-9front@sirjofri.de>:
>> I noticed that marshal also handles the whole boundary stuff and
>> attachments. The output file I get in pipefrom does not contain the
>> data
>> from the attachment.
>>
>> To verify I made this pipefrom:
>>
>> #!/bin/rc
>> echo $* > /tmp/msgargs
>> cat > /tmp/msgcontent
>>
>> Then look at these files.
>>
>> The whole thing is formatted as a multipart message, but it only
>> contains
>> the message text, no attachments.
>>
>> I also looked at the history of the marshal code, I don't think the
>> sendmail function is bad here.
>>
>> sirjofri
>>
>
> I'd look at whether we're closing the wrong fd
> if we're passing '-S'.
I found out, it's something completely different.
The function foldername builds the path to the outgoing directory. For
this, it uses the upasname environment variable (or the login name if
it's not set).
However, I had my upasname set to my sender address (joel@sirjofri.de),
so it builds the string: /mail/box/joel@sirjofri.de/outgoing, which of
course cannot be opened (it doesn't exist!).
Therefore, openfolder does return a wrong Biobuf with a file descriptor
-1, our tee function fails to write there and nothing works.
Removing my upasname variable confirmed this bug.
Now I just need to find a proper solution to this. Looking at the
returned file descriptor could be one, writing not to user but login
directory another.
If you want to follow my description in code, marshal.c:/^sendmail,
switch() case 0:, if (rcvr != nil), switch() case 0, the foldername
function call.
sirjofri
next prev parent reply other threads:[~2021-02-20 13:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-19 19:56 theinicke
2021-02-19 20:13 ` sirjofri
2021-02-19 20:54 ` Romano
2021-02-19 21:13 ` ori
2021-02-19 23:47 ` sirjofri
2021-02-20 0:28 ` sirjofri
2021-02-20 0:49 ` ori
2021-02-20 13:02 ` sirjofri [this message]
2021-02-19 23:27 ` ori
2021-02-20 13:16 ` [9front] [Patch] " sirjofri
2021-02-20 13:37 ` hiro
2021-02-20 14:03 ` [9front] bad headers in mail (was: Mail attachment bug) sirjofri
2021-02-20 14:10 ` hiro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=113789e3-82f3-4c5e-b68f-d1c786dfd11c@sirjofri.de \
--to=sirjofri+ml-9front@sirjofri.de \
--cc=9front@9front.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).