[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Changes to forw(1)

From: Robert Elz
Subject: Re: [Nmh-workers] Changes to forw(1)
Date: Sat, 15 Oct 2016 02:25:36 +0700

    Date:        Fri, 14 Oct 2016 10:58:53 -0400
    From:        Ken Hornstein <address@hidden>
    Message-ID:  <address@hidden>

  | Ralph, kre?  Would you like to clarify your positions for thick-headed
  | fellows like me?

As was pointed out in anothr message, I didn't take any position on the
filtering queston (other than not just blindly filtering anything we don't

Forthis in general, I think we need to keep in mind that there are two
very different kinds of fields involved - first there are fields that
are supposed to be user to user (or UA to UA, or similar) and then there are
those things that are internal implementation issues within nmh (or some other
mailer) and are just used for passing info from the user to his/her UA
(and which a GUI UA would probably accomplish via a menu selection or
button, or something, rather than by using fields, or anything else using

The latter type ought to be filtered out (where possible) the former not.

I inferred there was some confusion about this, as there was mention made
(when discussing using the nmh- prefix) of what would mmh (and a bunch of
other UA's) do if they wanted similar functionality - with the assumtion
being that this problem was similar to (or even the same as) the arguments
that eventually doomed the X- concept (a decision with which I completely
agree- X- always was a dumb idea, it just took hindsight to really
appreciate that.)

But that's not relevant here at all, the fields in question are ones which
are internal to nmh, if mmh wants a a field to do attaches, it can use
mmh-attach or mmh-attach-file, mmh-attach-message ... (whatever they want)
and so (in the obvious similar way) does every other UA that desires something
similar.   If nmh used just Attach: and mmh wanted to implement the same
strategy, and also chose Attach, there would be (or should be) no conflict,
not even if they use wildly different syntaxes for the field-body.

It is also different, in that the X- concept had exactly one string for
everyone (excpet the IETF) to use, embedding a manufacturer/prdouct/...
string (in some semi-rational common way - such as a prefix) avoids many
of the problems.  It stll has the "that's a good idea, we should standardise
that for everyone" problem - but that's not at all relevant to internal
use fields that are not supposed to escape (it is exactly because there
is no point in standardising some internal glue of nmh's, and that no-one
else ever should, or likely would, care how the internals of nmh work, that
we are even discussing changing the # lines in the body into Attach (or
nmh-attach) fields in the header.  That is, none of this is anyone else's

In general, I think I kind of prefer the prefix version, and then (as much
as is possible) scrubbing everything with that prefix - and of course, using
it only for internal nmh fields (even changing anno to use nmh-xxx for the
added fields might be a good idea - it would complicate scan format file
which would need to deal with both the old and new, but that's tolerable
I think.

On the other hand, I don't like the :attach suggestion at all - it looks
like it might be nice, but it results in message files (before processing
with send/post/mhbuild or whatever actually deals with this stuff) that
are not syntactically valid messages - and would (I think) result in a
command like:
        show last +drafts
potentially issuing errors about the malformed message.  That I think would
be a big mistage - assuming users don't screw up the editing (I sometimes
add cc; headers...) message files should always be valid messages, or as
close to it as possible.

The reasons I prefer the prefix version, are that it makes it trivial to
filter all such internal fields (again, as much as possible) and that it
doesn't prevent users using Attach (or whatever) as a header field should
some other mailer (at the recipient) uses that for some totally unrelated
purpose than the one we are discussing.   There's close to zero chance that
some other mailer will want nmh-anything as a field.

I don't care much about the accountability question - I don't see that as
important at all - I am an exmh user (who also uses MH commands - the nmh
versions of those), and while I haven't done it to the exmh I am currently
using, one of my normal standard mods is to kill the X-Mailer stuff (and
not because it has the X- prefix ... "X-Mailer" is pretty much the de-facto
stadard for UA identification - I don't think I have ever seen a MUA that uses
User-Agent (though I guess some of the browser oriented ones might.)
Rather, I usually delete it as I consider it no-one else's business which
software I use - if my mail is arriving in some form that causes problems,
I want the recipients to tell me about it, not look at some header info and
just throw up their hands and say" "oh that sh*thouse xxx mailer, always been
broken, forget it."   Nor am I interested in contributing (via stealth
really) to someones count of how many messages/users are using each of the
MUAs that exist.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]