[Nmh-workers] New mhbuild directives

[Lyndon Nerenberg]

> 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.

So now the user has to memorize an internal-to-the-source-code table to 
know when she has to override the built-in inline/attach defaults?  That's 
just nuts.

However, the mhbuild process could certainly be simplified.  The existing 
syntax is powerful, but something of a pain to use.  Having to know the 
MIME content type for an attachment is burdensome, not to mention a likely 
source of errors.  This problem could be addressed with a new pair of 
directives:

  #attach ;attribute <id> (comment) [description] filename

and

  #inline ;attribute <id> (comment) [description] filename

These differ from the existing #type/sub-type in two ways:

1) They automatically determine the MIME type and encoding, and
2) They set the content-disposition as per their directive name.

Both directives fail if they cannot unambiguously determine any required 
MIME content type-related parameters.  I.e., no guessing about character 
sets for 8bit text in the presence of the C locale.  The syntax allows the 
user to provide MIME attribute overrides, so a C locale user could inline 
an iso-latin1 document by saying:

  #include ;charset=iso-8859-1 intltext

To ensure correctness, I would want to implement this using an internal 
implementation of a MIME content-type identifier.  I would restrict it to 
a subset of common MIME types, using a conservative set of encoding 
defaults.  The intent is to get the common cases right, not to get 
everything sometimes right.  There are a couple of light-weight MIME 
content tasters with amenable licenses we could import.

--lyndon