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

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

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

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'

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

>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

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

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.

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

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

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

>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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>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

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

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,

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

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

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

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

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

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

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

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

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

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,

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

>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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

> 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

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

> 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

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

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

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

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

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

>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

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

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 >

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

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

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

>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

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

>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

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

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

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

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

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

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

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

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

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

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

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

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

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

>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

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

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

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

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.

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

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

[Nmh-workers] Changes to forw(1)

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