>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
_______________________________________________
Nmh-workers mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/nmh-workers
