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

[Ralph Corderoy]

Hi David,

> This message draft has In-Reply-To: and References: header lines,
> introduced by the default replcomps.  How would those lines get
> through post?

nmh would learn that those are in the directive set, like `To', and
`Attach', and ideally something about their RFC format too so it can
check the validity of the user's value before letting it pass through to
the wire.

> If a added a Foo: line to, the draft, what would block it?

Yes, the email wouldn't be sent.  Processed directives, e.g. Attach,
would have been removed by this point.  All that remains should be
directives nmh, post?, is willing to put on the wire, perhaps with
suitable encoding.

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

___
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]

Ralph wrote:

> I'm moving all the headers into nmh's domain, the ones it cares about in
> drafts, anyway.  This is only talking about draft processing.  So
> `Received' isn't in the set.  In effect, all draft headers become nmh
> directives, none of them are wire headers any more.  Directive `To' may
> well become wire `To' after send → post.  So I'm not sure the set is
> that large?  Typos get caught, and we can dribble Attach, Forward, etc.,
> since the whole namespace is ours.

I'm still missing something.  This message draft has In-Reply-To:
and References: header lines, introduced by the default replcomps.
How would those lines get through post?  If a added a Foo: line to,
the draft, what would block it?

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]

Ralph wrote:

> Rather that re-tread worn ground, how about a considered reply to my
> suggestion that all headers be known to nmh and the user having to add
> to that list,

Is "user having to add to that list" in your original proposal?
I'm missing it.  Is it a profile entry to allow the user to add
known header names?  If that's the case, I don't like maintenance
responsibility, even if it is the user's.  Though I think I'm missing
something.

> or pass it as the value of a `wire' header.  :-)
> http://lists.nongnu.org/archive/html/nmh-workers/2016-10/msg00189.html

I don't feel as strongly about your proposal overall.  The
"directive: header: value" syntax for unknown headers is different
from usual headers/pseudoheaders, and that's both good and not so.

But more important, we'd have to maintain a list of known headers.
I don't think that's as easy as it sounds.  It doesn't change
often, but it does, and would introduce incompatibilities for
users who use different versions of nmh (as in home and work).  We
sometimes insist that users use previous versions at their own peril,
but I'd rather minimize that, given the slow release cycle of nmh.

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 Paul,
 > 
 > > i was starting to think i was done with this, but i guess i'm not.
 > 
 > Rather that re-tread worn ground, how about a considered reply to my
 > suggestion that all headers be known to nmh and the user having to add
 > to that list, or pass it as the value of a `wire' header.  :-)
 > http://lists.nongnu.org/archive/html/nmh-workers/2016-10/msg00189.html

i think i got distracted by the mention of marmite and beer-brewing in
the same paragraph.  :-P

but really, i think your proposal goes further than necessary.  clearly,
i don't think much of a "solution" is currently necessary at all, since
i don't think there's much of a problem.  but i don't think the additional
issue you raise, of typo'd headers, is a big one -- and in any case it
feels somewhat orthogonal to the namespace pollution issue.  if we wanted
a "typo solution" (which, as you say, would probably involve teaching
nmh about all valid headers), we could implement that on top of any
namespace we choose, independent of Nmh- prefixes.

paul
=--
paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 57.9 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 Paul,

> i was starting to think i was done with this, but i guess i'm not.

Rather that re-tread worn ground, how about a considered reply to my
suggestion that all headers be known to nmh and the user having to add
to that list, or pass it as the value of a `wire' header.  :-)
http://lists.nongnu.org/archive/html/nmh-workers/2016-10/msg00189.html

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

___
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]

i was starting to think i was done with this, but i guess i'm not.

david wrote:
 > Oliver wrote:
 > 
 > > I prefer that we don't have Nmh- prefixes on our headers. Apart
 > > from it seeming ugly
 > 
 > Don't look at them :-)  I am serious.  These directives are for
 > internal nmh use, not to please the eye unless that can be done with

and yet...  those directives appear right at the top of my edit
buffer, and they do things which are documented that i can control by
adding them and removing them.  i find it hard not to look at them. 
they're no more "internal" than "Fcc".  so pleasing the eye, is,
actually, not unimportant.

 > no drawbacks.  Note the two distinct purposes described earlier in
 > this thread for the lines that appear in a MH/nmh draft header.
 > 
 > > and unnecessary,
 > 
 > 1) Namespace pollution.  2) Traceability when nmh breaks.

the header/pseudoheader namespace has been polluted since just about
when MH was written.  the likelihood of a future problem arising from
a bit more pollution is probably about equal to the number of problems
we've had in the past.

 > 
 > > the reasoning that went behind the deprecation of X- applies.
 > 
 > Does it?  nmh's directives are for internal use only by nmh.  I
 > don't call the directives "headers" for that reason, I call them
 > pseudoheaders.  They resemble headers, but they're not.  post(8)
 > should excise them, and no one should ever see them after.  Ever.

exactly.  and no one will, except for the single "draft forwarded to a
friend" case that's always been with us, and which seems really
unlikely to ever be a problem.  nmh is likely the only mailer in the
world that makes it trivial to import someone else's draft message,
including headers, as a whole.

 > 
 > RFC 6648 objects to X- because:
 > 
 >Under this convention, the name of a parameter not only
 >identified the data, but also embedded the status of the
 >parameter into the name itself
 > 
 > Status can change, so that after standardization, both forms (with
 > and without X-) have to be supported.  nmh directives don't have
 > that issue, except internally within nmh, and we have complete
 > control over that.
 > 
 > Nmh- isn't a status, it's a namespace.  It won't change.
 > 
 > > If mmh, GNU mailutils mh or perhaps a GUI that supports MH
 > > folders like Claws Mail add the same feature, they might not
 > > want the Nmh- prefix.
 > 
 > Of course.  They should never see it.  If they do, it's a problem and
 > I want to know about it.
 > 
 > > But some users may want to mix the clients and have them interoperate.
 > 
 > If a new header called Attach: or Forward: or Anything Else: is
 > standardized, but has different semantics than an nmh pseudoheader with
 > the same name, what would nmh then do?

i guess we'd change the name.  as you've said, these names are only
ever seen within the context of the running nmh.  we'd have to release
note such a change, of course.  we can even document now, that if an
Attach or Forward or Dcc or Fcc header is ever standardized by the
IETF, that we'll probably need to change nmh's user interface at that
time.  in fact, we should add that disclaimer anyway, since we already
face that potential problem with long-existing headers.

paul

 > 
 > > You see the problem in CSS where you end up having to specify certain
 > > properties multiple times for webkit, firefox, IE and then also
 > > without the prefix for once the feature got standardised.
 > 
 > I don't envision nmh's pseudoheader sematics aligning perfectly with
 > anything that might be standardized.
 > 
 > David
 > 
 > ___
 > Nmh-workers mailing list
 > Nmh-workers@nongnu.org
 > https://lists.nongnu.org/mailman/listinfo/nmh-workers
 > 


=--
paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 53.8 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]

Oliver wrote:

> I prefer that we don't have Nmh- prefixes on our headers. Apart
> from it seeming ugly

Don't look at them :-)  I am serious.  These directives are for
internal nmh use, not to please the eye unless that can be done with
no drawbacks.  Note the two distinct purposes described earlier in
this thread for the lines that appear in a MH/nmh draft header.

> and unnecessary,

1) Namespace pollution.  2) Traceability when nmh breaks.

> the reasoning that went behind the deprecation of X- applies.

Does it?  nmh's directives are for internal use only by nmh.  I
don't call the directives "headers" for that reason, I call them
pseudoheaders.  They resemble headers, but they're not.  post(8)
should excise them, and no one should ever see them after.  Ever.

RFC 6648 objects to X- because:

   Under this convention, the name of a parameter not only
   identified the data, but also embedded the status of the
   parameter into the name itself

Status can change, so that after standardization, both forms (with
and without X-) have to be supported.  nmh directives don't have
that issue, except internally within nmh, and we have complete
control over that.

Nmh- isn't a status, it's a namespace.  It won't change.

> If mmh, GNU mailutils mh or perhaps a GUI that supports MH
> folders like Claws Mail add the same feature, they might not
> want the Nmh- prefix.

Of course.  They should never see it.  If they do, it's a problem and
I want to know about it.

> But some users may want to mix the clients and have them interoperate.

If a new header called Attach: or Forward: or Anything Else: is
standardized, but has different semantics than an nmh pseudoheader with
the same name, what would nmh then do?

> You see the problem in CSS where you end up having to specify certain
> properties multiple times for webkit, firefox, IE and then also
> without the prefix for once the feature got standardised.

I don't envision nmh's pseudoheader sematics aligning perfectly with
anything that might be standardized.

David

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

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

[Steffen Nurpmeso]

Hello Ralph,

this likely goes to you in private only (via News)

Ralph Corderoy  wrote:
 |kre wrote:
 |> Rather, I usually delete [X-Mailer] as I consider it no-one else's
 |> business which software I use
 |
 |Yes, I'd want to turn it off from that point of view too.  I use mail(1)
 |for short internal emails, and here it's provided by package s-nail
 |which had a series of different core-dump bugs that I triggered.  It
 |quite possibly has buffer overflows  on receiving and rendering emails

Granted.  This is indeed not true.

 |too, and puts out `User-Agent: mail v14.8.12' into every email, like
 |pinning a target to the user's back.  :-)

This is a good suggestion, i should have introduced *user-agent*
just like mutt(1) has, instead of extending *stealthmua* à la "set
stealthmua=noagent" or -Sstealthmua=noagent!
Ciao!

--steffen

___
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,

kre wrote:
> Rather, I usually delete [X-Mailer] as I consider it no-one else's
> business which software I use

Yes, I'd want to turn it off from that point of view too.  I use mail(1)
for short internal emails, and here it's provided by package s-nail
which had a series of different core-dump bugs that I triggered.  It
quite possibly has buffer overflows  on receiving and rendering emails
too, and puts out `User-Agent: mail v14.8.12' into every email, like
pinning a target to the user's back.  :-)

If mh-format(5) had a version string or function then users could litter
X-Mailer and User-Agent, to cover both bases, willy nilly?

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

___
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

> I admit I am not clear where Ralph stands on this particular issue;
> perhaps the Marmite shortage is affecting things :-)

Marmite's basic ingredient is yeast sludge, a waste product from brewing
beer.  Give me the beer.  It's solely produced in Burton, which used to
have a large beer-brewing industry.  "Come friendly bombs and fall on
Burton!"  It's on my target list just above Twiglets.

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

http://lists.nongnu.org/archive/html/nmh-workers/2016-10/msg00096.html
I think `Nmh-' prefix is better on these nmh-directive headers if
everything else stays working as today.

I wandered off onto other options to try and trigger ideas that might be
acceptable to both camps.  And widen the problem a bit to consider
something that helps, or at least doesn't hinder, other problems.

Ideally,

Allow the user to write any legal header and have it hit the wire.
Ensure nmh-directive headers don't leak.
Ensure nmh-directive headers don't clash with external headers.
Catch typos in header names so they don't hit the wire.

Starting to use Nmh- from now on, having Nmh-* stripped by post(8), does
some of that.  Another alternative would be to consider all headers to
be nmh's fare; the user cannot put `Foo: bar' in a draft.  This would
mean we can continue to dribble over the namespace over time since it's
ours, all ours.  We can catch corruptions, `Subjct'.  And post can
ensure only known headers reach the wire, after correct encoding has
been applied.

The `escape' so users can still add their own headers could be another
nmh-directive header, e.g. «Wire: Foo: Bar».  I don't think any valid
header line from a user is an invalid header value, so it can just have
a new header key prefixed?  (I'd probably go for `X' for external to
save the clutter.)

> 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, because users may have a reason to add headers unknown to nmh.

> 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

"This Internet-Draft will expire on April 24, 2014."  Also,
https://datatracker.ietf.org/doc/search/?name=melnikov==on=on=group=
doesn't list it or an RFC conversion.

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

___
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 Paul,

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

A solution could include having a set of all headers nmh expects,
whether it uses their content or not, and all headers outside that set
that are meant to reach the wire need some indication of approval.  I've
suggested the colon prefix.  Other possibilities include an mh_profile
value listing them for frequent ones, and a -send option to add them on
the fly.  Typos or fat-fingered edits to the headers, "Subjct", would
then be caught.

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

___
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:14 Oct 2016 13:46:58 -0600
From:"Andy Bradford" 
Message-ID:  <20161014134658.23137.qm...@angmar.bradfordfamily.org>

  | 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-"?

Technically, you're right, X- should be the same as A- or any other two
random (permitted) chars as the first two of a field name.  The issue is
that people don't think of it that way - because of its history, people
with a little (but not a lot) of knowledge of e-mail standards assume that
X- field names are special, so unless you really know what you're doing, it
is best to avoid it (which is what SHOULD NOT means.)

If you're working for a company called X Y Z Software Inc (or something)
and you want to name a new field X-Y-Z-myname no-one is going to question
it.  But if you just feel like inventing a new field and calling it X-myname
then you really should think again.

One of the nice things about the change (long ago now really) in the X-
rule, is that (if there were any benefit at all in doing it) the IETF is
now able to standardise the widely used X-Mailer field (without being
forced to change the name, and by so doing, making a big mess.)

kre


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

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

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

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

[Ken Hornstein]

>You mentioned "harm":  it depends on how that's defined.  Sure, MUAs can
>igore headers, so no harm there.  But, I define each of intentionally
>withholding traceability and polluting a namespace as harmful.

Yeah, here's how I feel about that:

- Traceability - I mean, why is this an issue?  Who would really care?  I'm
  trying to imagine the scenario here; we a) leak a header called "Forward"
  b) someone notices, c) someone CARES enough to decide this is a problem,
  and d) wants to track down the MUA responsible.
- Polluting the namespace - I mean, also ... really, is this a thing we
  should have to worry about?  If it happens, and it seems like it's easy
  enough to prevent.

These are pretty abstract concepts to me; I'm trying to see how this
really would impact anything.  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 no one
seems to care.

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

> I can boil it down to this: these headers may leak out, if there are bugs
> or unusual behavior.  But I have realized ... I don't care.

I do care.  "Be conservative in what you do"

> Thinking about it more, we already leak some "internal" headers out.

Water under the bridge.  Let's do the right thing moving forward.

You mentioned "harm":  it depends on how that's defined.  Sure, MUAs can
igore headers, so no harm there.  But, I define each of intentionally
withholding traceability and polluting a namespace as harmful.

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

Then let's not.

David

___
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,

> I realize that sounds harsh, but I am trying to understand why leaking
> those headers would be harmful.

If they're are mistyped Attach, Bcc, or Dcc then they could be
embarrassing?

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

___
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]

>In case my point was missed:  the Attach: header was not scrubbed out.

So, I've been thinking about this more this evening, and I think I've
put my finger on the roots of my opinion.

I can boil it down to this: these headers may leak out, if there are bugs
or unusual behavior.  But I have realized ... I don't care.

I realize that sounds harsh, but I am trying to understand why leaking
those headers would be harmful.  I mean, yeah, it's not something we
should do, but AFAICT if any random header is leaked to the world, as
long as it is formatted correctly then I fail to see the harm to anything.
So this colors my thinking in this way: I understand the concerns people
have about traceability, but since in my mind the harm is zero, usability
concerns and aesthetics have a much higher weight.  And I think, in all
honesty, almost zero people would care one bit; the vast majority of
MUAs filter out unknown headers.

Now please understand, I am not completely convinced I am RIGHT.  I am
just sounding out my current thinking.  I welcome discussion here.

Thinking about it more, we already leak some "internal" headers out.
For example, _if_ you use annotations, your emails, and you dist a message
you have replied to or forwarded, those annotation headers will "leak".
Is that harmful?  I would argue no; things have been that way for more
than a few decades.  I mean, it might be harmful for YOU in terms of
privacy, but those headers don't seem to cause any harm.

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

I'd be fine with that, or it seems like User-Agent is preferred nowadays.

A Marmite-less Ralph says:

>Here's that colon-prefix idea again.  Any header without has to be in
>nmh's domain.  `To' is, even if the out-going email happens to have one
>of the same name;  nmh gets in there for the aliases, encoding, etc.
>The issue tracker wants an Attach header if I'm trying to attach a file
>to an existing issue.  By using the colon prefix I'm stating it's a raw
>mail header outside of nmh's purview and it's automatically got its own
>namespace distinct from nmh's prefix-less one.

I can understand the issue that you might want to create an Attach: header
to send out.  But ... I have to ask.  Is that ACTUALLY something people
need to do?  Yes, I undertand that the namespace collision might in theory
be a problem with real headers people want to generate.  But, a large
proportion of MUAs simply don't let you add arbitrary headers to your
message; I doubt someone would create a software package that required
you to interact with it via arbitrary email headers.

Also, I do have an issue with the : prefix headers; right now everything
we generate is actually valid according to RFC 5322 syntax.  If we
are concerned about stuff leaking because of bugs or user mistakes,
we shouldn't ever have users or programs generate non-RFC 5322 format
headers in the draft, because that could be harmful.

--Ken

___
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:Thu, 13 Oct 2016 12:20:27 -0400
From:Paul Fox 
Message-ID:  <20161013162027.8e7725180...@grass.foxharp.boston.ma.us>

  | as i understand it, the only worry with not using an Nmh- prefix is
  | with leaking headers.  since none of these are supposed to ever get
  | out, conscientious scrubbing should get rid of them.  (lyndon claimed
  | they'd get out, but didn't offer an example of how, so i'm still
  | unclear on that.)

That's easy, you just partly compose a draft, including attachment
commands, save it, don't send it, and forward it to someone else for
approval of the content before sending it to the intended recipients
(who then forwards it to others...)

This is just one way, if the header exists at all, it will escape.  The
only question is whether this is a serious problem or not.

kre

ps: please no "scrubbibg" of unknown headers - as things are, it is trivial
to support (in a sense) anything new or that some strange mail system
prefers, but if we start removing everything that we don't understand, that
won't be possible any more.


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

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

[Valdis . Kletnieks]

On Thu, 13 Oct 2016 22:18:21 +0100, Ralph Corderoy said:
> I tend to think those (X-)?Mailer headers are a bit of a waste of space
> and time.  The same value in thousands of copies of emails.  All those
> bytes, clock cycles, etc., when nothing cares about the value.

Until you're trying to track down a weird bug and root-cause it to the
fact that Lotus Notes uses different values for boundary= on a multipart/
(it uses two blanks in the header, but only one in the body), so my .procmailrc
has in it:

# Lotus Notes is a boil on the buttocks of e-mail.,...
:0 hwf
*^X-Mailer:.*(IBM|Lotus) Notes
| sed -e 's/boundary="=_alternative  /boundary="=_alternative /'

You spend a few decades doing e-mail support as one of your hats, you learn
to be glad that MUA's put in X-Mailer:, and most MTA's stick a 'with $software'
clause into their Recieved: headers.




pgporOtUGm8FQ.pgp
Description: PGP signature
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Oliver Kiddle]

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

User-Agent seems to be the newer replacement for X-Mailer. I don't know
if that's standardised or not other than in HTTP.

I prefer that we don't have Nmh- prefixes on our headers. Apart
from it seeming ugly and unnecessary, the reasoning that went behind
the deprecation of X- applies. If mmh, GNU mailutils mh or perhaps
a GUI that supports MH folders like Claws Mail add the same feature,
they might not want the Nmh- prefix. But some users may want to mix
the clients and have them interoperate.

You see the problem in CSS where you end up having to specify certain
properties multiple times for webkit, firefox, IE and then also
without the prefix for once the feature got standardised.

Regarding the questions that started this thread. I'd like it if #forw
directives could specify attachments within a message. So if part 2 is
an attached file, #forw +inbox 1.2 would mime attach the file. A Forward
or Attach header could also provide a shortcut with a forw option to
add those. forw -mime works but sometimes I want to strip out much of
the message body or include only some attachments.

Oliver

___
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,

> > Incompatible change, I realise.  Just trying to step back a bit and
> > see why we ended up here.

That was more explaining my meanderings rather than asking the question.
:-)

> There are a couple of things going on here.  One is, like you said,
> headers tell nmh programs what to do.  These are user-editable, and in
> cases of things like "To: and "cc:" users are expected to edit them.
>
> The other part is we're now using more headers as an IPC mechanism
> from one set of nmh programs to another.  There was always some of
> this, of course - repl(1) sets the To: and/or cc: headers, but now we
> are starting to make use of this for things like attach, and the
> proposal for forw(1).  These can also be user-editable, and I think
> that's desirable.  There will probably be more of them.

I think you end up in the second paragraph saying Attach, etc., fall
into the same bucket as the first's, which is how I lumped them
together.  That just leaves headers that nmh doesn't read or write at
all.  Bar any of those getting out by accident and we'd be half-way
there.

Here's that colon-prefix idea again.  Any header without has to be in
nmh's domain.  `To' is, even if the out-going email happens to have one
of the same name;  nmh gets in there for the aliases, encoding, etc.
The issue tracker wants an Attach header if I'm trying to attach a file
to an existing issue.  By using the colon prefix I'm stating it's a raw
mail header outside of nmh's purview and it's automatically got its own
namespace distinct from nmh's prefix-less one.

To: bughunter
From: ralph
Subject: issue 42
Attach: core
:Attach: Obtained on Arch Linux with s-nail 14.8.10-1.

As for being incompatible, Python had that `from __future__ import'
thing, Perl has `require 5.042', and .mh_profile could probably grow
something to keep *old* behaviour so new users, and old users that don't
experience breakage, get new behaviour.

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

___
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 Paul,

> > In case my point was missed:  the Attach: header was not scrubbed
> > out.
>
> sure, but that's a bug.  and (i think) we could catch those bugs with
> a test script.

I don't have the relevant switch to have Attach processed automatically
so it getting through isn't a bug, and I might even be trying to
communicate with some issue tracker that wants that header.  And then
there's catching the Atach header.

> > > i'd think adding an "X-Mailer: nmh-1.6" header would help even
> > > more. 
> >
> > "X-" headers are deprecated by RFC 6648.  We could add, say, a
> > Mailer header.
> 
> okay -- whatever's the right thing.

I tend to think those (X-)?Mailer headers are a bit of a waste of space
and time.  The same value in thousands of copies of emails.  All those
bytes, clock cycles, etc., when nothing cares about the value.  nmh
doesn't produce the message ID normally, but with MIME it does cook up
«boundary="- =_aa0"» and it did occur to me the other day
that it could be more interesting than that without getting longer and
still allowing for it to be bumped and be unique.

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

___
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:

> sure, but that's a bug.

I'm not sure about that.  What if the user has a legitimate reason
to use a such a header?  And we can't predict all such pseudoheader
names out into the future.  nmh should squat on the Nmh- namespace
to severely minimize this issue.

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:
 > Paul F wrote:
 > >  > I put one in this message.  (And also an Nmh-Attach: header, which will
 > >  > get scrubbed out, see below.)
 > >
 > > great!  so there's no problem.  ;-) :-)
 > 
 > In case my point was missed:  the Attach: header was not scrubbed out.

sure, but that's a bug.  and (i think) we could catch those bugs with
a test script.

 > 
 > > i'd think adding an "X-Mailer: nmh-1.6" header would help even more. 
 > > (i confess i'm a little surprised that we don't already emit such a
 > > header.  i see that exmh does.)
 > 
 > "X-" headers are deprecated by RFC 6648.  We could add, say, a Mailer
 > header.

okay -- whatever's the right thing.

paul
=--
paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 61.7 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]

Paul F wrote:

> not if i'm already in my editor, it's not.  and if i wait until leaving
> the editor, i'll likely forget the attachment.  so i sometimes use an
> editor macro to create the Attach: header, and sometimes i type it by
> hand.

Fair enough.  Though the editor macro could just as easily include the
Nmh- prefix.

> i could easily imagine doing that with Forward: as well.

And an editor macro could just as easily use a #forw directive.

>  > PF> as i understand it, the only worry with not using an Nmh- prefix is
>  > PF> with leaking headers.  since none of these are supposed to ever get
>  > PF> out, conscientious scrubbing should get rid of them.  (lyndon claimed
>  > PF> they'd get out, but didn't offer an example of how, so i'm still
>  > PF> unclear on that.)
>  > 
>  > I put one in this message.  (And also an Nmh-Attach: header, which will
>  > get scrubbed out, see below.)
>
> great!  so there's no problem.  ;-) :-)

In case my point was missed:  the Attach: header was not scrubbed out.

> i'd think adding an "X-Mailer: nmh-1.6" header would help even more. 
> (i confess i'm a little surprised that we don't already emit such a
> header.  i see that exmh does.)

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

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]

>Incompatible change, I realise.  Just trying to step back a bit and see
>why we ended up here.

There are a couple of things going on here.  One is, like you said, headers
tell nmh programs what to do.  These are user-editable, and in cases
of things like "To: and "cc:" users are expected to edit them.

The other part is we're now using more headers as an IPC mechanism from
one set of nmh programs to another.  There was always some of this, of
course - repl(1) sets the To: and/or cc: headers, but now we are starting
to make use of this for things like attach, and the proposal for forw(1).
These can also be user-editable, and I think that's desirable.  There
will probably be more of them.

--Ken

___
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:
 > PF> and i prefer "attach" and "forward" to "nmh-attach" and "nmh-forward".
 > 
 > To save keystrokes?  That shouldn't be a consideration in scripts.
 > And interactively, "a path" (at the What Now? prompt) is less
 > keystrokes that "Attach: path".

not if i'm already in my editor, it's not.  and if i wait until leaving
the editor, i'll likely forget the attachment.  so i sometimes use an
editor macro to create the Attach: header, and sometimes i type it by
hand.  i could easily imagine doing that with Forward: as well.

clearly this boils down to preference.  i prefer not to confuse the MH
user interface (what appears in the text editor, and on the command
line) with unnecessary visual clutter.

 > PF> as i understand it, the only worry with not using an Nmh- prefix is
 > PF> with leaking headers.  since none of these are supposed to ever get
 > PF> out, conscientious scrubbing should get rid of them.  (lyndon claimed
 > PF> they'd get out, but didn't offer an example of how, so i'm still
 > PF> unclear on that.)
 > 
 > I put one in this message.  (And also an Nmh-Attach: header, which will
 > get scrubbed out, see below.)

great!  so there's no problem.  ;-) :-)

 > 
 > KH> Personally, even if those headers DID leak out, I don't think it would
 > KH> be the end of the world, or even a big deal at all.
 > 
 > Yes, but why not try to do better:  if one does leak out, allow anyone to
 > track it down.

i'd think adding an "X-Mailer: nmh-1.6" header would help even more. 
(i confess i'm a little surprised that we don't already emit such a
header.  i see that exmh does.)

paul
=--
paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 62.8 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:

KH> I guess this illustrates one problem with open-source projects; who makes
KH> the decisions when people disagree?  It's not that people who want
KH> an Nmh- prefix are being unreasonable; I mean, I understand all of their
KH> arguments; I just think my arguments are more compelling.

Do the arguments boil down to traceability vs. keystrokes?

The status quo supports both:  Nmh-Attach: is used by the code, and if
someone wants to use Attach:, they can.  I think that Attach: is not
the best we can do as net citizens, and that we shouldn't continue down
that path with Forward:.

Paul wrote:

PF> in defense of not using a prefix:  these are all user visible headers,
PF> intended to be viewed and manipulated daily.  i'm certainly happier
PF> typing "bcc" and "fcc" than "nmh-bcc" and "nmh-fcc",

Let me clarify:  I'm not proposing that we go back and retrofit old headers.
As Lyndon wrote:

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

PF> and i prefer "attach" and "forward" to "nmh-attach" and "nmh-forward".

To save keystrokes?  That shouldn't be a consideration in scripts.
And interactively, "a path" (at the What Now? prompt) is less
keystrokes that "Attach: path".

PF> as i understand it, the only worry with not using an Nmh- prefix is
PF> with leaking headers.  since none of these are supposed to ever get
PF> out, conscientious scrubbing should get rid of them.  (lyndon claimed
PF> they'd get out, but didn't offer an example of how, so i'm still
PF> unclear on that.)

I put one in this message.  (And also an Nmh-Attach: header, which will
get scrubbed out, see below.)

KH> Personally, even if those headers DID leak out, I don't think it would
KH> be the end of the world, or even a big deal at all.

Yes, but why not try to do better:  if one does leak out, allow anyone to
track it down.

Ralph wrote:

RC> Pass through, nmh ignores or doesn't expect, headers should be indicated
RC> in some manner, e.g. colon prefix.  Then `Bc: norm' and `Attahc:

post(1) scrubs pseudoheaders that begin with "Nmh-".  It also advises the user
for each that has a non-empty value.

David

___
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 Paul,

> as i understand it, the only worry with not using an Nmh- prefix is
> with leaking headers.  since none of these are supposed to ever get
> out, conscientious scrubbing should get rid of them.

Headers in a draft are being used for two things.  Directives to nmh,
and verbatim headers to hit the wire.  In the former, we've Attach, but
also To, CC, etc., as they are examined rather than just passed through
by nmh.  I have 

MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

in my mail/components and I think they're all nmh directives too
inasmuch as it takes note of them?  I can plonk `Foo-Bar: Xyzzy 42'
there at the moment and it passes through.  Perhaps that's the problem.
Pass through, nmh ignores or doesn't expect, headers should be indicated
in some manner, e.g. colon prefix.  Then `Bc: norm' and `Attahc:
/home/ralph/paris.jpeg' aren't going to escape?

Incompatible change, I realise.  Just trying to step back a bit and see
why we ended up here.

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

___
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:
 > Paul F. wrote:
 > 
 > > lyndon wrote:
 > >  > 
 > >  > This means, moving forward, we only generate nmh-* headers, while
 > >  > continuing to accept the old ones.
 > 
 > Yup.
 > 
 > >  > This is particularly important now that "forw -mime" is becoming
 > >  > the default; these headers *will* escape now.
 > >
 > > why?  how?  it seems to me that you have to work pretty hard to
 > > get them into the wild -- mhbuild will eliminate them normally, won't
 > > it?
 > 
 > Note that post scrubs Bcc, Dcc, etc.  But not Nmh-Attach or Attach.
 > 
 > Also, nmh (whatnow) uses Nmh-Attach internally, not Attach.

was there a consensus on this issue?  (i'm assuming that there _was_
a consensus on ken's proposal for adding a Forward: header similar to
the current Attach:.)

in defense of not using a prefix:  these are all user visible headers,
intended to be viewed and manipulated daily.  i'm certainly happier
typing "bcc" and "fcc" than "nmh-bcc" and "nmh-fcc", and i prefer
"attach" and "forward" to "nmh-attach" and "nmh-forward".  using a
dot, as in ".attach" would i suppose be a marginal improvement, but
still a wart.

as i understand it, the only worry with not using an Nmh- prefix is
with leaking headers.  since none of these are supposed to ever get
out, conscientious scrubbing should get rid of them.  (lyndon claimed
they'd get out, but didn't offer an example of how, so i'm still
unclear on that.)

paul
=--
paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 63.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)

[Ken Hornstein]

>> I think, given current nmh design, this isn't an issue if you _forward_
>> an email (because the headers that you forward are not interpreted by
>> mhbuild).  Nor is it an issue if you use "dist", since mhbuild isn't run
>> on the message you are redistributing.  Although it does occur to me
>> that if you were to put an "Attach" header in the dist draft file,
>> something unexpected would happen; we should fix that.
>
>Does the calculus change if 'forw -mime' becomes the default?

Nope.

--Ken

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

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

[Valdis . Kletnieks]

On Tue, 11 Oct 2016 15:20:04 -0400, Ken Hornstein said:
> >So say I'm a miscreant,and I send you an e-mail phrased such that you'll
> >forward it. Meanwhile, I've surreptitiously placed an 'Attach: /etc/passwd' 
> >in
> >the headers of the mail I sent you
>
> I think, given current nmh design, this isn't an issue if you _forward_
> an email (because the headers that you forward are not interpreted by
> mhbuild).  Nor is it an issue if you use "dist", since mhbuild isn't run
> on the message you are redistributing.  Although it does occur to me
> that if you were to put an "Attach" header in the dist draft file,
> something unexpected would happen; we should fix that.

Does the calculus change if 'forw -mime' becomes the default?


pgpyVdFbhUfyU.pgp
Description: PGP signature
___
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]

>So say I'm a miscreant,and I send you an e-mail phrased such that you'll
>forward it. Meanwhile, I've surreptitiously placed an 'Attach: /etc/passwd' in
>the headers of the mail I sent you

I think, given current nmh design, this isn't an issue if you _forward_
an email (because the headers that you forward are not interpreted by
mhbuild).  Nor is it an issue if you use "dist", since mhbuild isn't run
on the message you are redistributing.  Although it does occur to me
that if you were to put an "Attach" header in the dist draft file,
something unexpected would happen; we should fix that.

--Ken

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

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

[Valdis . Kletnieks]

On Mon, 10 Oct 2016 15:28:33 -0400, David Levine said:

> Does anyone manually insert "Attach:" into their draft messages?

So say I'm a miscreant,and I send you an e-mail phrased such that you'll
forward it. Meanwhile, I've surreptitiously placed an 'Attach: /etc/passwd' in
the headers of the mail I sent you

(Yes, making this work *does* require that the recipient of the forwarded
message do a 'reply all', and their MUA clones over all attachments. Like
Outlook seems to do)


pgpeV1yryUjss.pgp
Description: PGP signature
___
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:

> david wrote:
>  > Note that post scrubs Bcc, Dcc, etc.  But not Nmh-Attach or Attach.
>
> why not?

Actually, I was mistaken:  it does filter out all header lines that start with 
"Nmh-".

As to why it doesn't scrub Attach:  because no one implemented that.

>  > Also, nmh (whatnow) uses Nmh-Attach internally, not Attach.
>
> immaterial.  :-)

Except to those who might want to update their scripts to be
consistent, now that they know that post will filter out Nmh-Attach
if it leaks through :-)

David

___
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]

Replying to myself,

> BTW, RFC 2822 defines Bcc, including that it can remain in the sent
> email with no values to indicate to the non-blind recipients that
> blinds were sent.

And other programs, like sendmail, handle Bcc headers so that's a case
where MH's use does blot out another's use.

> So given the only illegal header is `:Forward: +inbox 42', and David's
> traceability argument of having the world knock on our door, I think
> I'm still in favour of an `Nmh-' prefix.

Of course, a UTF-8 prefix is invalid.  ;-)

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

___
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:
 > Paul F. wrote:
 > 
 > > lyndon wrote:
 > >  > This is particularly important now that "forw -mime" is becoming
 > >  > the default; these headers *will* escape now.
 > >
 > > why?  how?  it seems to me that you have to work pretty hard to
 > > get them into the wild -- mhbuild will eliminate them normally, won't
 > > it?
 > 
 > Note that post scrubs Bcc, Dcc, etc.  But not Nmh-Attach or Attach.

why not?

 > 
 > Also, nmh (whatnow) uses Nmh-Attach internally, not Attach.

immaterial.  :-)

paul
=--
paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 47.7 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,

I think there's a difference between nmh headers the user might
typically add manually in a draft, e.g. Bcc, and those that are more the
mechanics of something they drive another way, e.g. Attach and the
whatnow prompt.  (Will the new Forward grow a `forward' whatnow(1)
command in time BTW?)

There seems to be two ideals.  Not cooking up headers that may clash.
Not letting our headers, however they're formed, leak.  I was wondering
about an illegal header prefix so that whatever's used we can ensure it
doesn't leak.  It could also be more terse for those that don't want to
type `Nmh-'.

from: tom
to: dick
.bcc: harry
.forward: +inbox 42 314 1718

It would have to be post(8) that's checking for `dot' headers since it
isn't send(1) that processes all of them;  some remain for post,
assuming that's the postproc.  `Dot files' are familiar from ls(1)
treating them as `hidden'.

But!  There are no illegal header field characters;  RFC 2822 says
anything from 33 to 126, except a colon, is OK.  So we'd still be
trampling, but having a shorter prefix to indicate it's internal, never
to leak.  (Though I agree "never" is doubtful, and there are alternate
postprocs to mess up.)

BTW, RFC 2822 defines Bcc, including that it can remain in the sent
email with no values to indicate to the non-blind recipients that blinds
were sent.

So given the only illegal header is `:Forward: +inbox 42', and David's
traceability argument of having the world knock on our door, I think I'm
still in favour of an `Nmh-' prefix.

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

___
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:

> lyndon wrote:
>  > 
>  > This means, moving forward, we only generate nmh-* headers, while
>  > continuing to accept the old ones.

Yup.

>  > This is particularly important now that "forw -mime" is becoming
>  > the default; these headers *will* escape now.
>
> why?  how?  it seems to me that you have to work pretty hard to
> get them into the wild -- mhbuild will eliminate them normally, won't
> it?

Note that post scrubs Bcc, Dcc, etc.  But not Nmh-Attach or Attach.

Also, nmh (whatnow) uses Nmh-Attach internally, not Attach.

David

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

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

[Lyndon Nerenberg]

> On Oct 10, 2016, at 11:23 AM, Ken Hornstein  wrote:
> 
>> i vote for presenting the user with a user-friendly component name.
>> if conflict is an issue, could we make the names of these "special"
>> headers tuneable via a profile entry?
>>   Nmh-Attach-Component: Attach
>>   Nmh-Forward-Component: Forward
> 
> FWIW, I am _not_ a fan of making this adjustable.  I would say that it would
> create more code and more documentation, for very little benefit.

Amen!


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

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

[Lyndon Nerenberg]

> On Oct 10, 2016, at 2:38 PM, Paul Fox  wrote:
> 
> why?  how?  it seems to me that you have to work pretty hard to
> get them into the wild -- mhbuild will eliminate them normally, won't
> it?

Nope, not when MIME forwarding becomes the default.  (You should see the header 
cruft that shows up in the messages we get at Hushmail.)
___
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]

lyndon wrote:
 > 
 > > On Oct 10, 2016, at 9:26 AM, Ken Hornstein  wrote:
 > > 
 > > I am going on prior art here; specifically, Fcc.  I don't see the value
 > > in adding an Nmh- prefix to any Nmh-specific header.  I realize this is
 > > something that there is not universal agreement on.
 > 
 > It's a simple namespace issue.  These headers escape the nmh
 > environment.  Being generic, other software might attribute other
 > meanings to them, and do unexpected things.  Putting everything
 > behind "nmh-", and advertising we do so, mostly eliminates the
 > risk.
 > 
 > This means, moving forward, we only generate nmh-* headers, while
 > continuing to accept the old ones.
 > 
 > This is particularly important now that "forw -mime" is becoming
 > the default; these headers *will* escape now.

why?  how?  it seems to me that you have to work pretty hard to
get them into the wild -- mhbuild will eliminate them normally, won't
it?

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

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

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

[Lyndon Nerenberg]

> On Oct 10, 2016, at 9:26 AM, Ken Hornstein  wrote:
> 
> I am going on prior art here; specifically, Fcc.  I don't see the value
> in adding an Nmh- prefix to any Nmh-specific header.  I realize this is
> something that there is not universal agreement on.

It's a simple namespace issue.  These headers escape the nmh environment.  
Being generic, other software might attribute other meanings to them, and do 
unexpected things.  Putting everything behind "nmh-", and advertising we do so, 
mostly eliminates the risk.

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

This is particularly important now that "forw -mime" is becoming the default; 
these headers *will* escape now.

--lyndon


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

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

[Lyndon Nerenberg]

> On Oct 10, 2016, at 6:19 AM, Ken Hornstein  wrote:
> 
> 1) forw be changed so -mime is the default. 

+1000.  This is long(!) overdue.

___
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]

ken wrote:
 > >Does anyone manually insert "Attach:" into their draft messages?
 > 
 > I do, FWIW.  It may be that I'm the only one.

i do, though via a script, so i guess that doesn't count.

i kind of thought this was a settled issue too, 

paul

 > 
 > I admit that maybe I'm a little frustrated, as I thought this was
 > thoroughly litigated in these threads:
 > 
 > http://lists.nongnu.org/archive/html/nmh-workers/2012-03/msg00015.html
 > http://lists.nongnu.org/archive/html/nmh-workers/2014-01/msg9.html
 > 
 > That doesn't mean that I'm unwilling to revisit those decisions; I just
 > kind of felt this had been settled already.
 > 
 > --Ken
 > 
 > ___
 > Nmh-workers mailing list
 > Nmh-workers@nongnu.org
 > https://lists.nongnu.org/mailman/listinfo/nmh-workers
 > 

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

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

[bergman]

In the message dated: Mon, 10 Oct 2016 15:28:33 -0400,
The pithy ruminations from David Levine on 
 were:
=> Ken wrote:
=> 

=> 
=> > I don't see the value of having a special Nmh- prefix.
=> 
=> Traceability is valuable.

Agreed.

=> 
=> > If they happen to leak out in the wild,
=> > they won't harm anything since they're not official headers.
=> 
=> The won't harm anything, but how will Ralph know who to ask to fix it?
=> 
=> Does anyone manually insert "Attach:" into their draft messages?

Yes, but rarelyso rarely that I could easily stop if the header prefix 
changed.

Mark

=> 
=> David
=> 
=> ___
=> Nmh-workers mailing list
=> Nmh-workers@nongnu.org
=> https://lists.nongnu.org/mailman/listinfo/nmh-workers
=> 
-- 
Mark BergmanBiker, Rock Climber, SCUBA Diver, Unix mechanic, IATSE #1 Stage
hand
'94 Yamaha GTS1000A^1 2015 Aprilia Capo
nord
berg...@panix.com  https://www.flickr.com/photos/rm
sppu

http://wwwkeys.pgp.net:11371/pks/lookup?op=get=bergman%40panix.com

I want a newsgroup with a infinite S/N ratio! Now taking CFV on:
rec.motorcycles.stagehands.pet-bird-owners.pinballers.unix-supporters
15+ So Far--Want to join? Check out: http://www.panix.com/~bergman 

___
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]

>The only responsible choice is to include the prefix.  Otherwise, we
>run the risk of messages leaking out with internal pseudoeheader names.
>Like this message!

Man, how did you get that out there?  Well, I guess if you ran mhbuild
on it first and then added it, that could happen.

>Note that Nmh-Attach and Attach are synonomous.  And all others, except
>Envelope-From:, used by nmh originated with MH.

I understand that ... it's just that the original designers of MH didn't
think it was a problem.  Okay, fine, they probably didn't envision
things like Attach or Forward, but they didn't envision MIME either.

So, that's one of those things where there is prior art, but I will
admit it's not super compelling.

>> I don't see the value of having a special Nmh- prefix.
>
>Traceability is valuable.

Yeah, okay, I can get that ... it's just ... well, I kind of want
users to be able to add those headers.  So having awkward names makes
that harder.  I guess it depends on what you think is important.

>The won't harm anything, but how will Ralph know who to ask to fix it?

Ha!  Well, okay, can't really argue with that one. :-)

>Does anyone manually insert "Attach:" into their draft messages?

I do, FWIW.  It may be that I'm the only one.

I admit that maybe I'm a little frustrated, as I thought this was
thoroughly litigated in these threads:

http://lists.nongnu.org/archive/html/nmh-workers/2012-03/msg00015.html
http://lists.nongnu.org/archive/html/nmh-workers/2014-01/msg9.html

That doesn't mean that I'm unwilling to revisit those decisions; I just
kind of felt this had been settled already.

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

> > [Ralph:]
> >Because the sooner we create the prefix, the sooner future new headers
> >can fall under it.  Ken says we discussed this over `Attach'.  Here we
> >are for `Forward'.  Next year it will be another one?

> My recollection is that it actually came up originally for
> Envelope-From, actually.

Both, so this is the third time in nmh history.  Let's settle it once and
for all.

The only responsible choice is to include the prefix.  Otherwise, we
run the risk of messages leaking out with internal pseudoeheader names.
Like this message!

Note that Nmh-Attach and Attach are synonomous.  And all others, except
Envelope-From:, used by nmh originated with MH.

> I don't see the value of having a special Nmh- prefix.

Traceability is valuable.

> If they happen to leak out in the wild,
> they won't harm anything since they're not official headers.

The won't harm anything, but how will Ralph know who to ask to fix it?

Does anyone manually insert "Attach:" into their draft messages?

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]

>i vote for presenting the user with a user-friendly component name.
>if conflict is an issue, could we make the names of these "special"
>headers tuneable via a profile entry?
>Nmh-Attach-Component: Attach
>Nmh-Forward-Component: Forward

FWIW, I am _not_ a fan of making this adjustable.  I would say that it would
create more code and more documentation, for very little benefit.

--Ken

___
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]

>Because the sooner we create the prefix, the sooner future new headers
>can fall under it.  Ken says we discussed this over `Attach'.  Here we
>are for `Forward'.  Next year it will be another one?

My recollection is that it actually came up originally for
Envelope-From, actually.

So, here's the official list of headers that nmh uses for what would be
classified as "internal use", that is to say, send(1)/post(8) uses them to
change their behavior, but they do not actually get sent out on the wire.

Bcc:
Dcc:
Fcc:
Envelope-From:
Attach:

(there is also Resent-Bcc, Resent-Dcc, and Resent-Fcc).  I'm not counting
the things like Resent/Forwarded/Replied, as while send(1) does create
those headers, it's not really using them to change anything that it does.
I'll take the blame for the last two, but the previous ones have been
around forever.

My feelings are that there is plenty of prior art for having special
headers that tell send/post what to do, I don't see the value of having
a special Nmh- prefix.  But like I said before, I recognize that not
everyone feels the same way.  If they happen to leak out in the wild,
they won't harm anything since they're not official headers.

--Ken

___
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]

>Because the sooner we create the prefix, the sooner future new headers
>can fall under it.  Ken says we discussed this over `Attach'.  Here we
>are for `Forward'.  Next year it will be another one?

I am going on prior art here; specifically, Fcc.  I don't see the value
in adding an Nmh- prefix to any Nmh-specific header.  I realize this is
something that there is not universal agreement on.

--Ken

___
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]

>thinking about this further, i think i might rather teach Attach about
>mh message numbers and sequences than add a new Forward header. 
>Attach is already examining its file arguments to decide how to a
>attach any given file -- teaching it recognize message specifiers
>isn't a big stretch.  this would clearly lead to these two
>invocations having different results:

Two problems I see:

"Attach" means, "attach this file with a disposition of 'attachment'".
It takes one argument: filename.  The #forw directive (which I am
planning on emulating) takes a folder name and message numbers; it does
not create a disposition, so it defaults to "inline".  This means different
semantics for Attach depending on the file type; I think that's bad.

It's more code.

--Ken

___
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 Paul,

> adding the "Nmh-" prefix would create the very first such header.  as
> i understand it, we already have 4 nmh-specific headers:  Resent,
> Forwarded, Replied,

Those are all added only if -anno is used for each of those commands.
They don't appear in a draft?

> and Attach.  i don't see much value in creating a unique prefix for
> the fifth.

Because the sooner we create the prefix, the sooner future new headers
can fall under it.  Ken says we discussed this over `Attach'.  Here we
are for `Forward'.  Next year it will be another one?

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

___
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 Paul,

> > > +1.  The `Forward' header is grabbing another one for nmh's use,
> > > in addition to the existing `Attach'.  Should we be using
> > > `Nmh-Forward' if the user isn't likely to have the hassle of
> > > typing them most of the time?
> > 
> > Sigh.  I think when we hashed this out last time, the (rough)
> > consensus was that not puttting in a "Nmh-" prefix was fine.  Attach
> > had prior art (I think mutt used it), and Forward seems to be
> > similarly named.
> 
> i vote for presenting the user with a user-friendly component name.
> if conflict is an issue, could we make the names of these "special"
> headers tuneable via a profile entry?

Isn't that just another level of code, documentation, and grokking by
the user when Nmh-Forward would just sit there, be spotted and
understood by the user, and typically left alone.  Either the message
numbers might be edited, or the whole line deleted.  I actually think
it's an advantage to see that this is a Nmh header and not one that may
have general purpose interpretation.

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

___
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]

ken wrote:
 > >> Thoughts?  I realize this is a significant behavior change
 > >
 > >+1.  The `Forward' header is grabbing another one for nmh's use, in
 > >addition to the existing `Attach'.  Should we be using `Nmh-Forward' if
 > >the user isn't likely to have the hassle of typing them most of the
 > >time?
 > 
 > Sigh.  I think when we hashed this out last time, the (rough) consensus
 > was that not puttting in a "Nmh-" prefix was fine.  Attach had prior
 > art (I think mutt used it), and Forward seems to be similarly named.

i vote for presenting the user with a user-friendly component name.
if conflict is an issue, could we make the names of these "special"
headers tuneable via a profile entry?
Nmh-Attach-Component: Attach
Nmh-Forward-Component: Forward

paul
=--
 paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 45.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]

Ralph wrote:

> +1.  The `Forward' header is grabbing another one for nmh's use, in
> addition to the existing `Attach'.  Should we be using `Nmh-Forward' if
> the user isn't likely to have the hassle of typing them most of the
> time?

Absolutely.  The existing code allows either Nmh-Attach or Attach.
We should use only Nmh-Forward here.

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]

>> Thoughts?  I realize this is a significant behavior change
>
>+1.  The `Forward' header is grabbing another one for nmh's use, in
>addition to the existing `Attach'.  Should we be using `Nmh-Forward' if
>the user isn't likely to have the hassle of typing them most of the
>time?

Sigh.  I think when we hashed this out last time, the (rough) consensus
was that not puttting in a "Nmh-" prefix was fine.  Attach had prior
art (I think mutt used it), and Forward seems to be similarly named.

--Ken

___
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]

>If I understand you, you are proposing to do, what you said yesterday, was
>very difficult.

Well ... we never did exactly nail down what you wanted (see Ralph's and
my email on this subject).  Take a look at:

http://lists.nongnu.org/archive/html/nmh-workers/2016-10/msg00045.html

"Option 1" is very hard to do _natively_ inside of forw.  I am not
proposing that.  "Option 2" (which forw can already do, and we have
never really established if that's sufficient for your needs) is what
I'm planning on making work better.

Ralph says:
>No, I think he's just turning `forw -mime' into plain `forw', and
>removing the need for running `mime' at the whatnow prompt.  So it's
>more automatic for the common need.

Yes, exactly!

--Ken

___
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,

>mhbuild will still handle #forw directives in case someone wants to
>have exact control over their message content.

 o/

> 4) After 1.7 comes out, Jon Steinhart will send a message to
> nmh-workers asking why forw doesn't work anymore :-) (I'm sorry, I
> couldn't resist).

After 1.9.

> Thoughts?  I realize this is a significant behavior change

+1.  The `Forward' header is grabbing another one for nmh's use, in
addition to the existing `Attach'.  Should we be using `Nmh-Forward' if
the user isn't likely to have the hassle of typing them most of the
time?

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

___
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 Norm,

> If I understand you, you are proposing to do, what you said yesterday, was
> very difficult.

No, I think he's just turning `forw -mime' into plain `forw', and
removing the need for running `mime' at the whatnow prompt.  So it's
more automatic for the common need.

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

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

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

[norm]

Ken Hornstein  writes:
>Okay, hopefully we've beaten this whole thing into the ground, and after
>all that here's what I suggest we do for 1.7:
>
>1) forw be changed so -mime is the default.  So if you, for example, still
>want to send a RFC 934 digest, you'd have to use -nomime.
>
>2) Doing forw -mime will result in the following header being placed in
>the draft (just an example, you get the idea):
>
>Forward: +inbox 8 22 38
>
>Smart people will notice this looks a lot like the #forw mhbuild
>directive.  This is not a coincidence :-)
>
>3) mhbuild will process any "Forward" headers at send(1) time and put
>them as message/rfc822 parts at the end of the message.  mhbuild will
>still handle #forw directives in case someone wants to have exact control
>over their message content.
>
>4) After 1.7 comes out, Jon Steinhart will send a message to nmh-workers
>asking why forw doesn't work anymore :-) (I'm sorry, I couldn't resist).
>
>Thoughts?  I realize this is a significant behavior change, and while I
>do poke fun at Jon occasionally he does bring up the fair point that
>breaking things is unfriendly.  AFAICT nothing will break (everything will
>still work) but users will definitely notice a difference.

If I understand you, you are proposing to do, what you said yesterday, was
very difficult.

Norman Shapiro

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

[Nmh-workers] Changes to forw(1)

[Ken Hornstein]

Okay, hopefully we've beaten this whole thing into the ground, and after
all that here's what I suggest we do for 1.7:

1) forw be changed so -mime is the default.  So if you, for example, still
   want to send a RFC 934 digest, you'd have to use -nomime.

2) Doing forw -mime will result in the following header being placed in
   the draft (just an example, you get the idea):

   Forward: +inbox 8 22 38

   Smart people will notice this looks a lot like the #forw mhbuild
   directive.  This is not a coincidence :-)

3) mhbuild will process any "Forward" headers at send(1) time and put
   them as message/rfc822 parts at the end of the message.  mhbuild will
   still handle #forw directives in case someone wants to have exact control
   over their message content.

4) After 1.7 comes out, Jon Steinhart will send a message to nmh-workers
   asking why forw doesn't work anymore :-) (I'm sorry, I couldn't resist).

Thoughts?  I realize this is a significant behavior change, and while I
do poke fun at Jon occasionally he does bring up the fair point that
breaking things is unfriendly.  AFAICT nothing will break (everything will
still work) but users will definitely notice a difference.

--Ken

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