Re: [Nmh-workers] Request Deprecation of mts.conf's mmdelim1 and mmdelim2.

Hi Ken, > > msh has gone post 1.6. Can inc's -pack die too > > before 1.7? It seems there's quite a bit of lingering msh rotting away. > > :-) > > I say, "Oh, hell YES!" Done that with 6170b76c. I think I've jiggled test/inc/test-pop correctly; one of its -pack uses wasn't -pack related so

Re: [Nmh-workers] Request Deprecation of mts.conf's mmdelim1 and mmdelim2.

>inc(1) implies above that `inc -host pop3.example.com -pack spool.mmdf' >is for msh(1) users. msh has gone post 1.6. Can inc's -pack die too >before 1.7? It seems there's quite a bit of lingering msh rotting away. >:-) I say, "Oh, hell YES!" --Ken

Re: [Nmh-workers] Request Deprecation of mts.conf's mmdelim1 and mmdelim2.

Hi again, More woes. > I take this to be an MH-only file, unused by other parties. Thus if > nothing in nmh reads them then it doesn't have to bother to create and > maintain them any more? And so all the supporting code can also go > pre-1.7? The main user in creating map files is inc(1),

Re: [Nmh-workers] Request Deprecation of mts.conf's mmdelim1 and mmdelim2.

Hi, I asked: > Does anyone know about the `map' file that is built by packf? ... > I don't think MH uses them so they're probably leftovers to feed to > the swine. I suspect the last user was msh(1), removed by 1.6-branchpoint-16-ge6917522, i.e. after 1.6's release. A `map' file is an array of

Re: [Nmh-workers] Request Deprecation of mts.conf's mmdelim1 and mmdelim2.

>Well, using RFC 4155 parse rules for From_ lines can lead to >different message boundary detection. Sigh. I don't view that RFC as particularly relevant now, as it has some serious problems (like only 7-bit data, for one). Also, it explicitly says there is no escaping mechanism; I guess the

Re: [Nmh-workers] Request Deprecation of mts.conf's mmdelim1 and mmdelim2.

Ken Hornstein wrote: |>It seems it has been simply be carried along from original Unix |>mail storage, and never has been properly adjusted thereafter. |>POSIX also standardized this loose format which was in use since |>that beginning. RFC 4155 defined a more proper format.

Re: [Nmh-workers] Request Deprecation of mts.conf's mmdelim1 and mmdelim2.

>It seems it has been simply be carried along from original Unix >mail storage, and never has been properly adjusted thereafter. >POSIX also standardized this loose format which was in use since >that beginning. RFC 4155 defined a more proper format. I think there are two things that are being

Re: [Nmh-workers] Request Deprecation of mts.conf's mmdelim1 and mmdelim2.

>No, it always was in band - the 4-SOH sequence was searched for in all >lines of the message, and SOH has always been a possible character in >e-mail. Just even more unlikely years ago than it is now. You know, I _was_ going to disagree here but Robert is, as he almost always is, 100% correct.

Re: [Nmh-workers] Request Deprecation of mts.conf's mmdelim1 and mmdelim2.

Robert Elz wrote: ... |If the mbox encoding format had been properly designed, rather than just |a "we need some way to fix the problem that a line starting 'From' in |a message acts like a separator" (which was a real issue/bug in early |implementations of it) this

Re: [Nmh-workers] Request Deprecation of mts.conf's mmdelim1 and mmdelim2.

Hi, kre wrote: > No, it always was in band - the 4-SOH sequence was searched for in all > lines of the message, and SOH has always been a possible character in > e-mail. Just even more unlikely years ago than it is now. I have, AIX, recollections of one of the four SOH sometimes being munged

Re: [Nmh-workers] Request Deprecation of mts.conf's mmdelim1 and mmdelim2.

Date:Wed, 24 May 2017 09:50:29 +0100 From:Jon Fairbairn Message-ID: | Back when I made the decision it was out of band. No, it always was in band - the 4-SOH sequence was searched for in all lines

Re: [Nmh-workers] Request Deprecation of mts.conf's mmdelim1 and mmdelim2.

Robert Elz writes: > Date:Tue, 23 May 2017 09:35:52 +0100 > From:Jon Fairbairn > Message-ID: > > | One of the first things I learnt was that > | using in-band data as a