The Subject was:
[Nmh-workers] suppress Content-ID's with new mhbuild option?
That's taken care of. The discussion had evolved to the mhbuild
directive created by send's -attach option.
Any suggestion on how to associate the option values with the build
directive? printf style?
whatnow: -attach X-MH-Attachment='#%T; name="%N" <%C>[%D; %M] %F'
I don't see why that needs to be configurable instead of hard coded.
I want to use something different than what's in the code.
Though maybe all we need are two kinds of directives. Currently, with
attach, mhbuild directives look like:
#text/plain; name="foo.txt"; x-unix-mode=0644 <>[ English text ] /tmp/foo.txt
#application/pdf; name="foo.pdf"; x-unix-mode=0644 <>[ Adobe Portable
Document Format (PDF) v1.2 ] /tmp/foo.pdf
mhbuild translates them (along with everything else that it does) to:
Content-Type: text/plain; name="foo.txt"; x-unix-mode="0644";
charset="us-ascii"
Content-Description: English text
Content-Type: application/pdf; name="foo.pdf"; x-unix-mode="0644"
Content-Description: Adobe Portable Document Format (PDF) v1.2
Content-Transfer-Encoding: base64
I want:
#text/plain <>[attachment; filename="foo.txt"] /tmp/foo.txt
#application/pdf <>[attachment; filename="foo.pdf"] /tmp/foo.pdf
which mhbuild would (almost) translate to:
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="foo.txt"
Content-Type: application/pdf
Content-Disposition: attachment; filename="foo.pdf"
Content-Transfer-Encoding: base64
The "almost" part is that mhbuild currently creates
Content-Description instead of Content-Disposition. I
hijacked the Content-Description information and used it to
form the Content-Disposition header (with or without
-attach). (Is that a good idea? Or, should
Content-Description be maintained, and new code and data
fields added to support Content-Disposition? I have no need
for Content-Description.)
Selection of the second form above could be controlled by a
-contentdisposition (or -rfc2183) switch to mhbuild. So
with default settings, nmh behavior would be unchanged.
This would be very easy to implement.
David
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers