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

[David Levine]

Oliver Kiddle writes:

> David Levine wrote:
> 
> > The option to suppress Content-ID: could be added to either
> > mhbuild or send.  mhbuild seems like the right place,
> > because that's where the MIME message is created.  And it's
> > trivial to do there.
> 
> I would prefer if the option could actually be added to the attach
> whatnow command.

I committed the quick addition to mhbuild.  But I agree
with adding more configurability to attach.

> Instead of the X-MH-Attachment header containing simply the filename, it
> could contain the full mhbuild directive. attach could then take options
> for explicitly specifying the filename, description, mime-type etc. This
> would also mean that it is possible to see what mime-type has been
> chosen before running send.

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.

> I must admit that one of the things I've never liked about
> X-MH-Attachment is that it does stuff like run `file' to build a
> description and provides x-unix-mode. With a few profile entries that
> could all be made configurable.

And to capture one more thought on Content-ID's:  if <> was
added to the mhbuild directive to suppress Content-ID's for each
of the MIME parts, some trickery would still be needed to
suppress it in the top-level messages.  One way would be to have
set_id (), in mhbuildsbr.c, keep track of how many parts have
non-null ct->c_id values.  It would be easier if the calls to
set_id () for the parts (with top == 0) could be moved until
after the place with a user-specified value is retrieved, but I
don't know if that's feasible.  If not, a call to set_id ()
where ct->c_id is set to NULL could be added.  Set_id () would
then keep track of how many parts have Content-ID; when finally
called with top==1, suppress the Content-ID if there are no
parts that have it.

David


> With regard to the new thread, I think it is basically right that
> attachment header handling is done automatically when send is run. I
> would however prefer if running the mime command (i.e. mhbuild) did the
> job of attaching the files. This would mean that the actual work would
> need to be done by mhbuild.
> 
> It's a minor point but another change I would make to the attachment
> stuff is to make the -attach option to send and whatnow a single
> standard profile entry.
> 
> Oliver
> 
> 
> This e-mail and any attachment is for authorised use by the intended recipien
> t(s) only. It may contain proprietary material, confidential information and/
> or be subject to legal privilege. It should not be copied, disclosed to, reta
> ined or used by, any other party. If you are not an intended recipient then p
> lease promptly delete this e-mail and any attachment and all copies and infor
> m the sender. Thank you.