Re: reformime -x option behavior change in v3.2.0 - path handling issue

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--===============2390616286563634618==
Content-Type: multipart/signed;
    boundary="=_ripper.email-scan.com-77607-1764108045-0001";
    micalg=pgp-sha1; protocol="application/pgp-signature"

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_ripper.email-scan.com-77607-1764108045-0001
Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Jan Smutn=C3=BD via Courier-maildrop writes:

> I have identified the specific code responsible for this behavior chang=
e and =20
> have prepared a patch that would restore the ability to use paths in th=
e -x =20
> option while maintaining backward compatibility.
>
> Could you please clarify the intended behavior for the -x option? If yo=
u =20
> would consider accepting a patch to restore the previous functionality =20
> (perhaps as an additional option to maintain compatibility), please let =
me =20
> know the preferred method for submitting contributions.

I believe I see what you're referring to.

A part of the filename comes from the E-mail's MIME header. The intent of =20
that portion of the code is to prevent troublemakers from emailing =20
attachments with slashes, periods, and other assorted practical jokes in =20
their filename, and have that automatically included in the automatically=
-=20
generated filename.

That part needs to say. The mistake is that this is also applied to the -=
x =20
parameter's value, which it should not be. That's under your full control=
. =20
The cleaning should be done only to the stuff that gets pulled out of the =20
headers.

The fix is to simply move the

filename.insert(filename.begin(), pfix.begin(), pfix.end());

part to after the immediately-following for-loop, instead of just before =
it.

If you'd like to formally submit this fix yourself, you are welcome to =20
either attach it as email, or submit it as a PR on Github. Either one wil=
l =20
work.


--=_ripper.email-scan.com-77607-1764108045-0001
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRupkKLJP96aW75pIOKYPgoojZS4gUCaSYnDQAKCRCKYPgoojZS
4r9XAP0fL3QKSN/mFunwGoAaYiid19v2we0mjK0vacX1N593FQEAgPAy+rxajKTX
o404NMgCYDYF7BfkHfYeR1mqWgSdKgE=
=bLDW
-----END PGP SIGNATURE-----

--=_ripper.email-scan.com-77607-1764108045-0001--


--===============2390616286563634618==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


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

--===============2390616286563634618==--