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

[Andy Bradford]

Thus said David Levine on Thu, 13 Oct 2016 16:16:38 -0400:

> "X-" headers are deprecated by RFC 6648.  We could add, say, a Mailer
> header.

While the RFC does say this:

   3.  SHOULD NOT prefix their parameter names with "X-" or similar
   constructs.

Why? What's  wrong with "X-"? If  the intent of  RFC 6648 is to  do away
with any special interpretation of "X-" in headers, then why make such a
statement thus  giving a new  special interpretation of  "X-"? Shouldn't
"X-" be just as useable as any other prefix in a header post-RFC6648?

Thanks,

Andy
-- 
TAI64 timestamp: 400058013656



___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Robert Elz]

Date:Fri, 14 Oct 2016 10:58:53 -0400
From:Ken Hornstein 
Message-ID:  <20161014145854.ab15644...@pb-smtp2.pobox.com>

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

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

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

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 

Re: [Nmh-workers] Starting the final call for features for 1.7

[David Levine]

Ralph wrote:

> > > I think the test is mhparam(1)'s checking for a TTY on FDs 0, 1, and
> > > 2.  OpenBSD's man page says $SHELL is used.  Perhaps the test can
> > > make use of this.
> > >
> > > $ cat >cmd
> > > #! /bin/sh
> > >
> > > mhparam path
> > > $ chmod +x cmd
> > > $ SHELL=`pwd`/cmd script

I went with this approach.  And I had to add a run-time check that
script(1) does what we want, by making the program that it runs
look like it's connected to a terminal.  I don't see any obvious
pattern for that:  FreeBSD 10 and Fedora 24 do, Fedora 18 on ARM7
and Ubuntu 14 don't.  Anyway, the test should be robust now.

Thanks, Ralph.

David

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Conjectures about whom

[Ken Hornstein]

>I am thinking about writing a postproc, using Ken Hornstein's example as a
>template (though I will probably use Java rather than bash). It will invoke
>whom and examine its output. I can find no documentation about whom's
>non-error output format. Here is my conjecture about it.

As an aside: now that I look at the code, I realize that post (which really
does the work for whom(1)), opens /dev/null and writes the headers to it.
Boy, once you know how the sausage is made ...

>Each output line (I don't particularly care how lines are delimited) is
>exactly one of:
>
> A string beginning with zero or more white space characters followed by a
> '-'
>
> A string containing exactly one address as a substring.
>
>Is this conjecture true? If so, can I count on it remaining true?

You can also have an address followed by [BCC].  Also, the address (for
dumb historical reasons) is printed as "user at domain".  You can also
in theory have a UUCP address (host!user) but you would have to work
to make that happen, and I don't think you'd actually be able to send it
anywhere if you did.  You can also have a "local" address which has
no @ or at.

I don't think we can make any guarantees on the format of that output;
for example, it might change to being simply user@domain.  Also, getting
rid of the distinction between local and network users might make sense,
but that would require some more thought.  I would simply display the
output to the user and check the exit value.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Nmh-workers] Conjectures about whom

[norm]

I am thinking about writing a postproc, using Ken Hornstein's example as a
template (though I will probably use Java rather than bash). It will invoke
whom and examine its output. I can find no documentation about whom's
non-error output format. Here is my conjecture about it.

Each output line (I don't particularly care how lines are delimited) is
exactly one of:

 A string beginning with zero or more white space characters followed by a
 '-'

 A string containing exactly one address as a substring.

Is this conjecture true? If so, can I count on it remaining true?

Norman Shapiro

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

>> Also ... if we are having post(8) scrub out headers with an Nmh- prefix,
>> we could also have it scrub out any header, like Attach:,
>
>No, we can't.  See previous messages from Ralph, kre, and me on that.

Hrm.  I interpreted Ralph's email as he wanted to filter out _every_
unknown email header, unless it had a colon prefix; that would remove
misspellings like "Bc:", for example.  And kre thought that was a bad
idea (and I agree with that).

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

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[David Levine]

Ken wrote:

> So if traceability is the major concern, would a User-Agent header
> address everyone's issues?

No, because:

Nmh-Attach: foo
User-Agent: nmh-1.7

is more informative than:

Attach: foo
User-Agent: nmh-1.7

And, "This means, moving forward, we only generate nmh-* headers,
while continuing to accept the old ones."

David

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Paul Fox]

david wrote:
 > Ken wrote:
 > 
 > > Also ... if we are having post(8) scrub out headers with an Nmh- prefix,
 > > we could also have it scrub out any header, like Attach:,
 > 
 > No, we can't.  See previous messages from Ralph, kre, and me on that.

huh?  if that's what you meant, that's not what i heard.  i heard
arguments saying that headers could still leak (via forwarding, and
via typos, neither of which is a new risk), but i don't recall anyone
saying that we _can't_ scrub the Attach: and Forward: headers in
post.  (kre reasonably pointed out that we shouldn't scrub unknown
headers -- but that's different.)

paul
=--
paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 47.1 degrees)


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[David Levine]

Ken wrote:

> Also ... if we are having post(8) scrub out headers with an Nmh- prefix,
> we could also have it scrub out any header, like Attach:,

No, we can't.  See previous messages from Ralph, kre, and me on that.

David

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

>Ken wrote:
>
>> - Traceability - I mean, why is this an issue?  Who would really care?
>
>I count four people who have responded that they do.  I might have miscounted,
>but obviously some do care.

I'm not saying that no one cares ... but I'm not sure I agree with the
count there.

As I read it, you and Lyndon are on the "Nmh-" prefix side,
unambiguously.  Me, Paul, and Oliver are unambiguously on the "no
prefix" side.  In terms of everyone else who has commented on this
thread ... I admit I am not clear where Ralph stands on this particular
issue; perhaps the Marmite shortage is affecting things :-) Ralph's
not so crazy on letting those headers get out, but he never said that
he wanted or didn't want a Nmh- prefix.  Mark Begman did say that
traceability was good, so I could see putting him in the Nmh- prefix
camp (I would personally describe his position as "no objections",
but he can correct me if he wants). Valdis only commented on the
X-Mailer/User-Agent issue, and Robert's response did not really mention
a preference either.  So, it's a bit of a wash there.

>> Also, copying other art ... the few MUAs
>> that do stuff similar to this (mutt is the prime example I could find)
>> use headers for this purpose without any special prefix, and
>
>And messages used to have a couple of handfuls of header lines.  Now
>they're 3 to 4 (of my) screenfulls, and some have names like X-AOL-IP,
>X-Pobox-Relay-ID, X-MS-Has-Attach,
>x-ms-office365-filtering-correlation-id,
>X-MS-Exchange-Transport-CrossTenantHeadersStamped,
>x-forefront-antispam-report, X-GMAIL-LABELS, X-GMAIL-THRID, and
>X-GMAIL-MSGID.  So I don't buy your point about prior art.  At all.

Well, I was thinking more about the the particular thing _nmh_ does, in
terms of having a user or another program insert a header for another
part of the MUA to interpret and remove before sending.  I believe, looking
at those headers, those are inserted by MTAs, and they are intended to
be sent.

>> and no one seems to care.
>
>I care.  And others have indicated that they care.

Fair enough; I guess I didn't mean "there were zero people who cared",
but more, "There was no general outrage across the Interwebs".

As long as we're beating this into the ground, I wanted to bring
up something else.  In another message you said:

>The status quo supports both:  Nmh-Attach: is used by the code, and if
>someone wants to use Attach:, they can.

I realized that change went in post-1.6, so that's not completely accurate
in terms of released code.

Also ... if we are having post(8) scrub out headers with an Nmh- prefix,
we could also have it scrub out any header, like Attach:, and we could
have it put in a X-Mailer or User-Agent header.  It looks like that
was never standardized for Email, but it comes from HTTP and there was
an Internet-Draft here to use it for Email:

https://tools.ietf.org/html/draft-melnikov-email-user-agent-00

So if traceability is the major concern, would a User-Agent header
address everyone's issues?

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] I see nmh is now available in epel repo for RHEL, Scientific Linux and CentOS

[David Levine]

Jón wrote:

> This morning I got a notification from the package manager that
> a new version of nmh was available. This was a nice surprise as
> hitherto I had built my own rpms for nmh (and was rather behind
> the times). So now upgraded to 1.6
>
> I didn’t see any mention on here that this was going to happen.

I was just going to send out a message:  nmh 1.6 is in the EPEL5
and EPEL6 repos as of last night/this morning.  It was submitted
to EPEL7 as well, so should be available there soon.

I'm sending this to nmh-announce as well.  The next release, 1.7,
will display a welcome message similar to the following on the first
use of an interactive nmh command:


Welcome to nmh version 1.6

See the release notes in `mhparam docdir`/NEWS

Send bug reports, questions, suggestions, and patches to
nmh-workers@nongnu.org.  That mailing list is relatively quiet, so user
questions are encouraged.  Users are also encouraged to subscribe, and
view the archives, at https://lists.gnu.org/mailman/listinfo/nmh-workers


David

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[David Levine]

Ken wrote:

> - Traceability - I mean, why is this an issue?  Who would really care?

I count four people who have responded that they do.  I might have miscounted,
but obviously some do care.

> - Polluting the namespace - I mean, also ... really, is this a thing we
>   should have to worry about?

Yes.

> If it happens, and it seems like it's easy enough to prevent.

It's easier to not pollute it in the first place, and use Nmh- going
forward.

> These are pretty abstract concepts to me; I'm trying to see how this
> really would impact anything.

But, you conceded:

> I mean, yeah, it's not something we should do

> Also, copying other art ... the few MUAs
> that do stuff similar to this (mutt is the prime example I could find)
> use headers for this purpose without any special prefix, and

And messages used to have a couple of handfuls of header lines.  Now
they're 3 to 4 (of my) screenfulls, and some have names like X-AOL-IP,
X-Pobox-Relay-ID, X-MS-Has-Attach,
x-ms-office365-filtering-correlation-id,
X-MS-Exchange-Transport-CrossTenantHeadersStamped,
x-forefront-antispam-report, X-GMAIL-LABELS, X-GMAIL-THRID, and
X-GMAIL-MSGID.  So I don't buy your point about prior art.  At all.

> and no one seems to care.

I care.  And others have indicated that they care.

David

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Nmh-workers] I see nmh is now available in epel repo for RHEL, Scientific Linux and CentOS

[Jon Fairbairn]

This morning I got a notification from the package manager that
a new version of nmh was available. This was a nice surprise as
hitherto I had built my own rpms for nmh (and was rather behind
the times). So now upgraded to 1.6

I didn’t see any mention on here that this was going to happen.

-- 
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2014-04-05)


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[David Levine]

Paul F wrote:

> but there's no solution, to this, right?  we can't control typos, whether
> there's an Nmh- prefix on the header or not.  and we're not going to change
> Fcc/Dcc/Bcc in any case.  so isn't this is a moot point?

We can't eliminate the effects of arbitrary typos, of course, but we can
help reduce them.  We can, and do, eliminate nearly all those after a
fixed Nmh- prefix.  If a user wants to use Nmh-Bcc: in their draft, along
with a trivial postproc that translates that and blocks, say, B.*, they could.

Also, anyone can put an Nmh-Attach: header in their components file so it's
there for every message.  post will filter it out if unused.  The same is
true of Cc:, Bcc:, etc., but going forward, we don't want to add more
special cases.

David

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Paul Fox]

ralph wrote:
 > Hi Ken,
 > 
 > > > If they're are mistyped Attach, Bcc, or Dcc then they could be
 > > > embarrassing?
 > >
 > > Well ... sure?  But I think that's an issue with any header name.
 > 
 > No, I mean "Subjct: Nice to see you again" isn't embarassing;  I always
 > intended they'd see the header's value.  "Bc: myboss, yourboss", is.
 > And "Atach: /home/ralph/pita-client/foo" is as normally they'd only see
 > "foo".

but there's no solution, to this, right?  we can't control typos, whether
there's an Nmh- prefix on the header or not.  and we're not going to change
Fcc/Dcc/Bcc in any case.  so isn't this is a moot point?

paul
=--
paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 41.0 degrees)


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ralph Corderoy]

Hi Ken,

> > If they're are mistyped Attach, Bcc, or Dcc then they could be
> > embarrassing?
>
> Well ... sure?  But I think that's an issue with any header name.

No, I mean "Subjct: Nice to see you again" isn't embarassing;  I always
intended they'd see the header's value.  "Bc: myboss, yourboss", is.
And "Atach: /home/ralph/pita-client/foo" is as normally they'd only see
"foo".

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers