Re: [Nmh-workers] Call for testing of nmh 1.7 release candidate 3

[Ken Hornstein]

>e.

Hm ... was this supposed to be there?  I only ask because if it wasn't
and you're using 1.7, we should fix that.

>Saw it in another post.  When using previous versions of nmh (1.6 and
>prior) I never had to have the send: line in my .mh_profile.

Sigh. I guess I should have asked Anthony Bentley why he added -notls
since he started that.  But I think Ralph covered that pretty well; to
align with best current practice we changed the default SMTP submission
port to 587.  You do not need to add -notls.

>>>Binary files /home/jerry/code/nmh-1.7-RC3/test/testdir/21786.draft and 
>>>/home/jerry/code/nmh-1.7-RC3/test/testdir/21786.expected differ
>>
>> That's ... interesting.
>>
>>>./test/mhbuild/test-attach: test failed, outputs are in 
>>>/home/jerry/code/nmh-1.7-RC3/test/testdir/21786.draft and 
>>>/home/jerry/code/nmh-1.7-RC3/test/testdir/21786.expected.
>>>FAIL: test/mhbuild/test-attach
>>
>> I think that might have been cleaned up.  Could you do:
>>
>>      make check TESTS=test/mhbuild/test-attach
>>
>> And then let us know what the files that it claimed were different actually
>> contained?
>
>The difference was in the final section -
>
>(9052.expected contains)
>
>Content-Type: application/octet-stream; name="nulls"
>Content-Description: nulls
>Content-Disposition: attachment; filename="nulls"
>Content-Transfer-Encoding: base64
>
>AAAAAAAAAAAAAAAAAAAA
>
>------- =_aaaaaaaaaa0--
>
>(9052.draft contains):
>
>Content-Type: binary/; name="nulls"

Um, wow.  A Content-Type of binary/ ????

I am curious .... if you grep through config.status for the following
variables:

MIMETYPEPROC
MIMEENCODINGPROC

What do they return?  It might be something like

        file --brief --dereference --mime-type

And what happens when you run that command on the file test/mhbuild/nulls ?

--Ken