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

>Not qmail? http://qmail.org/man/man5/mbox.html describes mboxrd by >default, and then describes how qmail-local locks the file. Dang. Well, I see that the default is for qmail to use Maildir (not a surprise), but I see that it unconditionally uses mboxrd to write a mbox maildrop. >> I don't

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

Hi Ken, > But AFAICT all MTAs store their maildrops in mboxo format (at least > the ones that use mbox format do). I couldn't find one that used > mboxrd format Not qmail? http://qmail.org/man/man5/mbox.html describes mboxrd by default, and then describes how qmail-local locks the file. > > I

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

>> I realize this wouldn't happen for likely a while, but would people be >> happy with just mboxo and mboxrd support in terms of maildrop parsing? > >Those two seem sufficient, but the user would have to state which their >system used? Well, yeah? I mean, I don't see how you could configure it

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

Hi Ken, > I realize this wouldn't happen for likely a while, but would people be > happy with just mboxo and mboxrd support in terms of maildrop parsing? Those two seem sufficient, but the user would have to state which their system used? > And does anyone see Content-Length headers in their

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

Ken Hornstein writes: >>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

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

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

Date:Tue, 23 May 2017 20:23:54 -0400 From:Ken Hornstein Message-ID: <20170524002355.1f76b6b...@pb-smtp1.pobox.com> | I remember that; it was the Content-Length header, right? That is as I remember it (for what that is worth) yes. | It occurs to

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

>There was one attempt to use (essentially, though as I recall, not quite >implemented that way) out of band data for mail collection files - that >is, adding a header and length field (much like tar format, or cpio, etc, >but much simpler) but which was a spectacular failure, and hated much more

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

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 separator is a bad idea, Like most generalizations, that

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

>> I suppose that's a reason, but it just seems like mbox has been the >> standard for approximately forever and MMDF is one of those weird relics >> like UUCP that I only hear about once in a million years. > >Which is a shame. One of the first things I learnt was that >using in-band data as a

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

>I used to come across it on sendmail-using AIX quite a lot IIRC. AIX? You are SO not selling me on this :-) >> I had vague plans on writing a mail message parser using lex/yacc, and >> I was NOT planning on putting MMDF support in it. > >Wouldn't it just affect the top level? What's wrapped

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

Hi Ken, > > Lack of From munging? > > I suppose that's a reason, but it just seems like mbox has been the > standard for approximately forever and MMDF is one of those weird > relics like UUCP that I only hear about once in a million years. I used to come across it on sendmail-using AIX quite a

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

Ken Hornstein writes: >>Lack of From munging? That was indeed the reason that I chose it. The thing about archives is that they are supposed to hang around for a long time. I’ve been using some form of mh since the 1980s, and the script that archives my mailboxes hasn’t changed

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

>Lack of From munging? I suppose that's a reason, but it just seems like mbox has been the standard for approximately forever and MMDF is one of those weird relics like UUCP that I only hear about once in a million years. >> I think at this point MH/nmh is probably the only tool left that can >>

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

Hi Ken, > > I use nmh and keep mmdf archives (produced by pack -mmdf). > > I have to ask ... why? Lack of From munging? > I think at this point MH/nmh is probably the only tool left that can > deal with such things. Python's mailbox in the standard library can read them. Unfortunately, a

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

>I use nmh and keep mmdf archives (produced by pack -mmdf). I have to ask ... why? I think at this point MH/nmh is probably the only tool left that can deal with such things. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org

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

Ken Hornstein writes: >>mts.conf(5) says these may be altered from their default. >> >>mmdelim1: \001\001\001\001\n >> The beginning-of-message delimiter for mail drops. >> >>mmdelim2: \001\001\001\001\n >> The end-of-message delimiter for mail drops. >> >>This

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

>mts.conf(5) says these may be altered from their default. > >mmdelim1: \001\001\001\001\n > The beginning-of-message delimiter for mail drops. > >mmdelim2: \001\001\001\001\n > The end-of-message delimiter for mail drops. > >This doesn't seem useful, if it ever was. If

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

Hi, mts.conf(5) says these may be altered from their default. mmdelim1: \001\001\001\001\n The beginning-of-message delimiter for mail drops. mmdelim2: \001\001\001\001\n The end-of-message delimiter for mail drops. This doesn't seem useful, if it ever was. If someone