Re: [Nmh-workers] When a message goes only to me, as a cc

n...@dad.org wrote: > Robert Elz writes: > >Date:Wed, 12 Oct 2016 12:00:24 -0400 > >From:Paul Fox > >Message-ID: <20161012160024.c92015182...@grass.foxharp.boston.ma.us> > > > >| so you still might not know that you've left a

Re: [Nmh-workers] When a message goes only to me, as a cc

Robert Elz writes: >Date:Wed, 12 Oct 2016 12:00:24 -0400 >From:Paul Fox >Message-ID: <20161012160024.c92015182...@grass.foxharp.boston.ma.us> > >| so you still might not know that you've left a blank To: header. > >There's nothing

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] When a message goes only to me, as a cc

Ken Hornstein writes: >>I usually have a line, 'n...@dad.org', in my drafts. I do that instead of >>something like 'fcc: inbox', because I want to see what my Email looks like >>after it has gone through the net. But sometimes I forget to otherwise address >>the message. But

Re: [Nmh-workers] When a message goes only to me, as a cc

Hi Norm, Ken wrote: > Traditionally there have been a lot of these "internal" switches used by > programs to pass down information between various (n)mh programs. We've > slowly been documenting them; we haven't got them all. I just ran strace -fe execve -o /tmp/st comp here, with `w',

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)

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

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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

>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