Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really -attach ]

[Jon Steinhart]

> > Maybe I don't understand your proposed changes.  Apologies if I get this 
> > wrong;
> > I didn't save a copy of your original email and the archives are currently 
> > down.
> > 
> > There are currently -attach options on send and whatnow to support the 
> > non-standard
> > attachment header.  I don't even think about this because my .mh_profile 
> > includes:
> > 
> >     send: -alias aliases -attach X-MH-Attachment
> >     whatnow: -attach X-MH-Attachment
> > 
> > My understanding is that your change would be to remove the -attach options 
> > and to
> > have the .mh_profile include something like this instead:
> > 
> >     attach: X-MH_Attachment
> 
> That's only the minor change I made (in order to enable any program to
> take part without the need to add the -attach switch to all of them).
> I did it because it reduces overall complexity and simplifies the
> configuration (which currently is very complex; you can hardly use nmh
> without spending weeks in setting everything up once).
> 
> This change, AFAIS, only breaks with the versions since you added your
> attachment system and only in the way that the -attach switch is not
> recognized. One hardly wants to define some non-standard attachment
> header anyways, therefore my version adds a default one. The
> attachment format needs to be specified differently if one likes to
> change it.
> 
> Where compatibility does get broken is that my attachment system would
> always be active, while your's by default would not. But that's the
> crucial point!
> 
> As I said above, currently nmh can hardly be used (for modern emailing,
> that people probably like to do) with the default setup. Everyone of
> us, of course has his rather complex setup which does what he likes,
> so you don't see this problem anymore. I needed about two month until
> nmh had been well configured. This included Jerry Peek's book or
> course, the man pages and the pretty old FAQ. I needed lots of time to
> figure out all the stuff. You often don't know if it is broken or if
> you just haven't found out where you need to configure what.

OK.  You raise an interesting point here, but I still think that there are
better ways to address it.

I want to point out that the reason that I did it the way that I did was
because the attachment header is NON STANDARD.  I wanted to make sure that
I didn't break anything.

I didn't have your issues in setting up nmh.  It worked out of the box.
It was way easier than competing mail systems and easier than most gui
systems.  The thing that took time was setting up all of the mhshow stuff
for each mime type.

So two suggestions:

 1.  Add the -attach options for send and whatnow in the default profile
     created by install-mh.  Keeps casual users from having to deal with
     it and doesn't break anything.

 2.  Create a program a la configure that scans a target system for programs
     that handle content and build the mhshow stuff automatically.  This
     can't be hardwired because different things are available on different
     target systems.

> Hence I would like to see nmh do the most likely thing per default.
> This for instance includes converting foreign charsets to the native
> one on show. This also includes the definition of the attachment
> header. I asked myself why a user or system administrator should need
> to set it manually. I fould no answer besides some corner cases where
> the behavior would change.
> 
> If no such header is present and all text is ASCII then the behavior
> is the original.
> 
> If a header is present or non-ASCII is used then the message is
> MIMEified. This very likely is what is intended.  For sending
> non-ASCII text without MIME I don't know. My patch MIMEifies in any
> case if it's non-ASCII.
> 
> Therefore my patch removes the need to run `mime' at the whatnow
> prompt. Why does the user need to decide if he needs MIME or not?
> Mostly he does not know an will MIMEify always. Then plain ASCII
> messages are MIMEified too which is not necessary. My patch does the
> more reasonable thing.
> 
> Further more it does not require the user to know about mhbuild(1)
> directives and makes /^#/ non-special (that's what your system
> provided). Running mime at the whatnow prompt to early had been a
> pain too as one was not able to modify the draft later one. It also
> removes the problems that can occure when mixing automimeproc:1,
> /^#/-lines, and your attachment system. In fact, instead of having two
> attachment systems, we only have one. It includes MIME forwarding too,
> which seems to be only too logical.
> 
> Of course there still are problems which need to be solved. The two
> mayor ones are:
> 
> (1) Less flexibility there are MIME structures that are not possible to
> create. We should carely evaluate which ones are really needed and how
> to access the full flexibiliy of mhbuild with the proposed system.
> 
> (2) MIME type guessing is very dumb. I'd like to see a system here
> that works out-of-the-box, in order to avoid heavy configuration on
> setup. Adding douzends of mhshow-suffix- lines in the profile appears
> merely as a workaround. GNU file(1) provides -i which provides the
> information needed, but this is not portable (actually SUSv3 requires
> -i to mean something else).

I'm confused here.  My attachment code does all of this stuff automatically.
It guesses the content types, eliminates the need to know about mhbuild,
and eliminates the need to run mime.  The only problem of which I'm aware is
order-of-operation stuff when wanting to add attachments to a reply to or
forward of a mime message in which you want the original message included.
What am I missing?

Jon