Re: [Nmh-workers] suppress Content-ID's with new mhbuild option?

[Jon Steinhart]

> Nice.  Attach already takes the filename.  Options would need to
> include mime-type, name, mode, description, and Content-ID.  Anything
> else?  If there's too much, it would get unwieldy.
> 
> 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'
> 
>   whatnow? attach -mime-type=application/wierd -name=foo -mode=0x640 
> -description="my app" -contentid="" /tmp/foo
> 
> If any value in the build directive isn't specified, it
> would be determined automatically (using mhshow-suffix for
> the mime-type as it is now, and getting the name from the
> filename, and so on).
> 
> While that example has a lot of typing, its purpose is to
> show all the options.  I expect to rarely specify options,
> given a suitable build directive, such as '#%T; name="%N"
> <>[] %F', with the mime-type and name usually determined
> automatically.  I don't see a need to bother with mode or
> description, and don't want contentid.
> 
> It might be possible to add support for Content-Disposition
> here.

Um, gimme a break here.  Why not just use mhbuild mime-composition files?
I added the attachment handling code so that non-geeks could send attachments.
This is heading in the opposite direction.  How often are these cryptic
arguments really going to be used?  How many other mailers care about this
sort of stuff?  How many mail programs even look at this stuff?

If you decide to make these additions, keep in mind that they have to be done
in the send code, not in the whatnow code.  This is because the design of the
attachment code was such that it would work independent of the user interface.
In particular, I know people who have hacked mh-e to add attachment headers.

Jon