Re: makemime not working like before?

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.

--===============5710742776315323077==
Content-Type: multipart/signed;
    boundary="=_ripper.email-scan.com-637590-1770570109-0002";
    micalg=pgp-sha1; protocol="application/pgp-signature"
Content-Transfer-Encoding: 8bit

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-637590-1770570109-0002
Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Alessandro Vesely writes:

> The script uses makemime like so:
>
> 	open(MM, '|-', 'makemime @-') or warn("can't fork: $!"), $failed = 5;
>
> 	print MM "-j
> 		(
> 			-m
> 				multipart/mixed
> 			-a
> 				MIME-Version: 1.0
> 			(
> 				-c
> 					text/html; charset=utf-8
> 				". '&'. fileno($fb) ."
> 			)
> 		)
> 		".'&0'."\n-\n" or warn("bad MM pipe: $!"), $failed = 6;
>
> The script reads an email message with an attachment.  In the code above,  
> <$fb> is a temporary file where the previous part of the script wrote an  
> HTML description of the attachment.
>
> The original message was saved as another temp file, <$fh>.  Before opening  
> MM, the header from <$fh> was printed to stdout, except for MIME header  
> fields which were saved to $mimestuff.  Now, the rest of the original  
> message is being printed as a second entity, a multipart/mixed:

The second parameter to -j, what seems to be &0 here, also needs to be a  
MIME file. It's not clear to me from your description that you already fed  
the attachment to  -c, and are piping that into standard input.

I think that's always been the case, but the difference in behavior might be  
due to the new MIME parser.

If it's a manually assembled MIME file, it should have its own Mime-Version:  
1.0 header.

You can always replace the second parameter with another set of  
parenthesized recursive options, and supply a -c there, to MIME-encode a raw  
file.


--=_ripper.email-scan.com-637590-1770570109-0002
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

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

iHUEABYKAB0WIQRupkKLJP96aW75pIOKYPgoojZS4gUCaYjBfQAKCRCKYPgoojZS
4kYTAP436pWsaccWWq7wPSFTSuf71siR9CTyq3YegJOsiaQ9vgEA6FJNp+EpCL5X
HvhtArsRPoAVDyhOUYU+UXtutY7xKwE=
=/Jh+
-----END PGP SIGNATURE-----

--=_ripper.email-scan.com-637590-1770570109-0002--


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


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

_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

--===============5710742776315323077==--