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.
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers