reformime -x option behavior change in v3.2.0 - path handling issue
Jan Smutný via Courier-maildrop <[email protected]> Tue, 25 Nov 2025 22:11:36 +0100
| Newsgroups | gmane.mail.maildrop |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============5663515273411080113==
Content-Type: multipart/alternative;
boundary="------------Gl5JQlIODQpU20dyDqzQfSdS"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------Gl5JQlIODQpU20dyDqzQfSdS
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Hello,
We have been using reformime as part of the mail-filter/maildrop Gentoo
package for several years. Prior to version 3.2.0, the -x option
accepted full paths in its argument (e.g., "-x
/home/user/mail/myprefix"), extracting MIME message parts to the
directory "/home/user/mail/" with filenames beginning with "myprefix".
Since version 3.2.0, forward slash characters ("/") in the argument are
replaced with underscores ("_"), causing all parts to be extracted to
the current directory with the original path becoming part of the
filename prefix. For example, what previously extracted to
"/home/user/mail/myprefix001" now extracts to
"./home_user_mail_myprefix001" in the current directory.
While I cannot definitively say whether either behavior should be
considered a bug or feature, this change has caused issues for our
existing workflows and scripts that relied on the previous path-handling
behavior. The change was undocumented and unexpected from our perspective.
I have identified the specific code responsible for this behavior change
and have prepared a patch that would restore the ability to use paths in
the -x option while maintaining backward compatibility.
Could you please clarify the intended behavior for the -x option? If you
would consider accepting a patch to restore the previous functionality
(perhaps as an additional option to maintain compatibility), please let
me know the preferred method for submitting contributions.
Thank you for your time and for maintaining this useful tool.
Best regards,
Jan Smutný
--
S pozdravem / Best regards
Ing. Jan Smutny
EXCELLO | Virusfree
E: [email protected] <mailto:[email protected]>
W: http://www.excello.cz <http://www.excello.cz/>
W: http://www.virusfree.cz <http://www.virusfree.cz/>
Twitter <https://twitter.com/excello_cz>
Linkedin <http://www.linkedin.com/company/511927>
--------------Gl5JQlIODQpU20dyDqzQfSdS
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p><span><span>Hello, <br>
</span></span></p>
<p><span>
</span><span>We have been using reformime as part of the
mail-filter/maildrop Gentoo package for several years. Prior to
version 3.2.0, the -x option accepted full paths in its argument
(e.g., "-x /home/user/mail/myprefix"), extracting MIME message
parts to the directory "/home/user/mail/" with filenames
beginning with "myprefix".</span></p>
<p><span></span><span>Since version 3.2.0, forward slash characters
("/") in the argument are replaced with underscores ("_"),
causing all parts to be extracted to the current directory with
the original path becoming part of the filename prefix. For
example, what previously extracted to
"/home/user/mail/myprefix001" now extracts to
"./home_user_mail_myprefix001" in the current directory.</span></p>
<p><span>While I cannot definitively say whether either behavior
should be considered a bug or feature, this change has caused
issues for our existing workflows and scripts that relied on the
previous path-handling behavior. The change was undocumented and
unexpected from our perspective.</span></p>
<p><span>I have identified the specific code responsible for this
behavior change and have prepared a patch that would restore the
ability to use paths in the -x option while maintaining backward
compatibility.</span></p>
<p><span>Could you please clarify the intended behavior for the -x
option? If you would consider accepting a patch to restore the
previous functionality (perhaps as an additional option to
maintain compatibility), please let me know the preferred method
for submitting contributions.</span></p>
<p><span>Thank you for your time and for maintaining this useful
tool.</span></p>
<p><span>Best regards,<br>
Jan Smutný<br>
</span></p>
<div class="moz-signature">-- <br>
<style>
p.signature {
margin: 0cm 0cm 0.0001pt;
font-family: Calibri, sans-serif;
}
a.signature-link {
color: #954f72;
text-decoration: none;
}
</style>
<p class="signature">S pozdravem / Best regards</p>
<p class="signature">Ing. Jan Smutny</p>
<p class="signature">EXCELLO | Virusfree</p>
<p class="signature"><br>
</p>
<p class="signature">E: <a
class="signature-link moz-txt-link-freetext"
href="mailto:[email protected]">[email protected]</a></p>
<p class="signature">W: <a
class="signature-link moz-txt-link-freetext"
href="http://www.excello.cz/">http://www.excello.cz</a></p>
<p class="signature">W: <a
class="signature-link moz-txt-link-freetext"
href="http://www.virusfree.cz/">http://www.virusfree.cz</a></p>
<p class="signature"><br>
</p>
<p class="signature"><a class="signature-link"
href="https://twitter.com/excello_cz">Twitter</a></p>
<p class="signature"><a class="signature-link"
href="http://www.linkedin.com/company/511927">Linkedin</a></p>
</div>
</body>
</html>
--------------Gl5JQlIODQpU20dyDqzQfSdS--
--===============5663515273411080113==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--===============5663515273411080113==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Courier-maildrop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/courier-maildrop
--===============5663515273411080113==--