>it's a shame to have to foist the decision as to which to use (Attach >or Inline) onto the user.
Well, at a fundamental level we pretty much have to foist that decision to the user, right? Unless we hardcode a list of types. >perhaps a list of types which should be >inlined by default would be better. > mhbuild --inlined-type text/calendar --inlined-type message/rfc822 ... >(or maybe comma-separated) Well, other than making the command line super-huge this would work, but I'm not a big fan personally. I guess my thinking is that "Attach" is short for "attachment", which is named because of the Content-Disposition header. We now have a demonstrated need for attachments which are Not Really Attachments in the proper sense ... they are inline. We could have people use mhbuild directives, but let's face it ... those suck. Someone else brought up the fact that they were unhappy that patches attached with the Attach header were marked with a disposition of "attachment" ... which to me again suggests that we need something better. I think defining it by content-types isn't so great, because really it seems like more of an issue when dealing with certain MUAs, which suggests to me you want to change it on a per-message or destination basis. In terms of implementation ... it should be pretty easy. The magic happens in build_mime() and setup_attach_content() in mhbuildsbr.c. Seems like the easiest thing to do is add a flag to "struct attach_list" to indicate if this attachment is inline or not, and make setup_attach_content() take that flag and DTRT. --Ken _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
