Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[markus schnalke]

Hoi,

discussing these things hadn't been easy sometimes, but the points and
arguments became clear and now we reached some kind of consensus. For
me, the discussion had been worthwhile.


[2010-12-03 11:33] Jon Steinhart <address@hidden>
> 
>  o  Nobody objects to markus addressing this issue.  The objections are that
>     his implementation breaks things, and handling illegal body content is
>     not a compelling enough reason for breaking things.

> So, I think that enough has been said on this topic.  markus, can you outline
> for us an implementation that doesn't break things?  I think that everyone 
> will
> bless your changes if you do.

I agree with you here. Hence I created a new patch that concentrates
on the fourth case, explained in the other mail. AFAIS it does not
break anything.

Let me explain:

As it only modifies your attachment system now, everything is the same
if -attach is not specified.

For -attach being specified, the situation is such:

  no attachment hdr  +  body contains only ASCII  ->  sent as is
  attachment hdr     +  body contains only ASCII  ->  MIMEified
  attachment hdr     +  body contains non-ASCII   ->  MIMEified
  no attachment hdr  +  body contains non-ASCII   ->  MIMEified

The fourth case is different.

Additionally, the body text will be sent with a correct mime-type in
any case. Currently it was sent as application/octet-stream in the
third case.


The relation to `mime' at the whatnow prompt:

One surely wants to unset automimeproc when using -attach.

Running `mime' at the whatnow prompts is usually not needed as Jon's
attachment system handles it automatically.

Collisions only occure if an attachment header is present in the mail
and one runs `mime' at the whatnow prompt. If the body text contains
non-ASCII chars or not is irrelevant, it works as expected in both
cases.

As long as one does not add attachment headers to a specific draft,
one is able to use any mhbuild directives (/^#/) when running `mime'
at the whatnow prompt afterwards.


Further work:

The documentation currently does not cover my changes. Not much to
change, and I like to do that if the proposed changes are accepted.

More complex MIME structures than ``text followed by attachments'' are
not possible with Jon's attachment system. (Like they are not with
most MUAs.) One needs to create them with mhbuild directives and run
`mime' manually. (For forwarding messages, see below.)

Jon's attachment system still needs mhshow-suffix- entries or it will
be really dumb. This is something that should be covered separately,
maybe by a conceptional redesign (automatic detection, mailcap, ...).

Forwarding messages in MIME format could be added to Jon's system in a
way similar to what I proposed initially. I believe this would be
possible without breaking stuff. We would need to add -attach to
forw(1).


meillo


> P.S.  I'm trying to honor the way that you're name appears in your mail 
> header.
>       Do you really want it to be "markus" or should it be "Markus"?

Usually, I prefer ``meillo'' because that's a nearly unique
identifier. If you want to use my real name, I don't care if you spell
it in lower-case or with capital `M'. More important is honoring my
work by mentioning my name in the ChangeLog or commit messages. ;-)

diff --git a/uip/sendsbr.c b/uip/sendsbr.c
index 57ef007..8f5f2e1 100644
--- a/uip/sendsbr.c
+++ b/uip/sendsbr.c
@@ -196,6 +196,7 @@ attach(char *attachment_header_field_name, char 
*draft_file_name,
     int                        c;                      /* current character 
for body copy */
     int                        has_attachment;         /* draft has at least 
one attachment */
     int                        has_body;               /* draft has a message 
body */
+    int                        non_ascii;              /* msg body contains 
non-ASCII chars */
     int                        length;                 /* length of attachment 
header field name */
     char               *p;                     /* miscellaneous string pointer 
*/
 
@@ -228,29 +229,36 @@ attach(char *attachment_header_field_name, char 
*draft_file_name,
        if (strncasecmp(field, attachment_header_field_name, length) == 0 && 
field[length] == ':')
            has_attachment = 1;
 
-    if (has_attachment == 0)
-       return (DONE);
-
     /*
-     * We have at least one attachment.  Look for at least one non-blank line
-     * in the body of the message which indicates content in the body.
+     * Check if body contains at least one non-blank char (= not empty)
+     * and if it contains non-ASCII chars (= need MIME).
+     * We MIMEify the message also if the body contains non-ASCII text.
      */
 
     has_body = 0;
+    non_ascii = 0;
 
     while (get_line() != EOF) {
        for (p = field; *p != '\0'; p++) {
-           if (*p != ' ' && *p != '\t') {
+           if (*p != ' ' && *p != '\t')
                has_body = 1;
+           if (*p > 127 || *p < 0) {
+               non_ascii = 1;
                break;
            }
        }
-
-       if (has_body)
+       if (non_ascii)
            break;
     }
 
     /*
+     * Bail out if there are no attachments and only ASCII text.
+     * This means we don't need to convert it to MIME.
+     */
+    if (!has_attachment && non_ascii == 0)
+       return (DONE);
+
+    /*
      * Make names for the temporary files.
      */
 
@@ -299,8 +307,10 @@ attach(char *attachment_header_field_name, char 
*draft_file_name,
      * Add a mhbuild MIME composition file line for the body if there was one.
      */
 
-    if (has_body)
-       make_mime_composition_file_entry(body_file_name, attachformat);
+    if (has_body) {
+       /* charset will be discovered/guessed by buildmimeproc */
+       fprintf(composition_file, "#text/plain %s\n", body_file_name);
+    }
 
     /*
      * Now, go back to the beginning of the draft file and look for header 
fields