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 [email protected] http://lists.nongnu.org/mailman/listinfo/nmh-workers
