Note that we are discussing removing orthogonal programs from MH only to
clarify the focus of the program and to simply the build environment. We
are not discussing killing anything. If there is still interest, it
would be easy enough to package these items separately.
Mike O'Dell m...@ccr.org
On 2013-01-03, at 16:24 PM, Ken Hornstein wrote:
That wasn't UREP by any chance, was it?
He speaks the name of false idols.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
I don't use any of the things you mentioned
(I even ran UUCP (over TCP) until last summer)
I'm fine with UUCP as a transport protocol; it's the damn bang addresses
that I hate. And it sounds like no one uses them, or the % stuff either.
--Ken
___
Ken Hornstein wrote:
I don't use any of the things you mentioned
(I even ran UUCP (over TCP) until last summer)
I'm fine with UUCP as a transport protocol; it's the damn bang addresses
that I hate. And it sounds like no one uses them, or the % stuff either.
when we did use them, we handled
I wonder if our current support is busticated. I've looked at this
code in uip/mhbuildsbr.c:
That's a good question ... like I said, AFAICT we're the only ones who
generate or check a Content-MD5 header, so we have no other MUAs to test
interoperability with.
--Ken
Ken Hornstein k...@pobox.com writes:
Greetings all,
I'm been thinking about Markus's master's thesis, and it's motivated me to
remove some old crud sitting around in nmh. I'd like to get some feedback
about it.
I've started reading it too, and thus far I do not have any objections
to the
I still use slocal because it does what I need easily and simply.
procmail is hardly a poster child for great software
UI design or implementation, and I would look very
dimly upon the prospect of re-implementing a
many-hundred-line .maildelivery file as the goo
required by procmail.
as for the
On 2013-01-04, at 11:18 AM, Ken Hornstein wrote:
That's a good question ... like I said, AFAICT we're the only ones who
generate or check a Content-MD5 header, so we have no other MUAs to test
interoperability with.
I will look at it later this week. My internet pipe has been down
Stop it! Now I will be having nightmares about running BITNET gateways on SunOS
:-P
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Ken == Ken Hornstein k...@pobox.com writes:
Ken I'm been thinking about Markus's master's thesis, and it's
Ken motivated me to
Ken remove some old crud sitting around in nmh. I'd like to get
Ken some feedback
Ken about it.
I don't use any of the things you mentioned
(I
(I even ran UUCP (over TCP) until last summer
I still use UUCP over TCP to submit mail from my laptop during road trips. It
neatly bypasses all the moronic hotel proxies that break port 587 submission.
But you don't need bang paths for UUCP mail, and haven't for decades.
On Thu, 03 Jan 2013 19:24:58 -0500, Ken Hornstein said:
Stop it! Now I will be having nightmares about running BITNET gateways on
SunOS :-P
That wasn't UREP by any chance, was it?
For a *real* horrorshow, UREP on a Gould UTX/32 box (for starters, the
bisync card was busticated, and didn't
we should make this functionality optional ... that would make things
easier for Paul Fox, if no one else :-)
yow! that's a 9 year old thread you're referring to!
Heh, well ... this actually came up last Feburary right after the
conversion to Automake, and in your email you referred to
I mentioned that utmpx is not required by POSIX, and you replied that it's
more complicated than that. Could you expand on that? I'm interested to
hear more, because I personally am not very familiar with this stuff.
Okay. In short, when when you say utmpx isn't required by POSIX, it all
depends
the entire jive about EBCDIC-safe was never
anything other than insanely bizarre. the concept
made no sense because there are keypunch patterns
defined for every byte value 0x00 through 0xff.
OS/360 object decks used those routinely.
they even had a way to quote a deck image such
that a // in the
the entire jive about EBCDIC-safe was never
anything other than insanely bizarre. the concept
made no sense because there are keypunch patterns
defined for every byte value 0x00 through 0xff.
I don't disagree with you; I only report the news, I don't make it.
FWIW, EBCDIC-safe characters are the
On Wed, 02 Jan 2013 20:57:03 -0500, Ken Hornstein said:
I don't disagree with you; I only report the news, I don't make it.
FWIW, EBCDIC-safe characters are the usual printable ones in ASCII,
but excluding odd choices like !, , #, $, @. , =, .
Those characters are, oddly enough, not
On Tue, 01 Jan 2013 11:56:41 -0500, Ken Hornstein said:
it lasted that long). Also, it looks like to me that no RFC describes
how UUCP addresses are supposed to be formatted, so it's not even clear
to me how a correct address parser are supposed to handle those things.
The real problem
Greetings all,
I'm been thinking about Markus's master's thesis, and it's motivated me to
remove some old crud sitting around in nmh. I'd like to get some feedback
about it.
- Remove ALL the traces of UUCP support. I'm assuming that the only response
here will be, nmh still has UUCP
- Remove rcvtty completely. This works in conjunction with slocal or
I would not be happy with that, I use slocal and rcvtty for
(user-configurable) new message notification.
My .maildelivery is:
#Field Pattern Action Result String
X-Spam-Flag NO qpipe R
I would like to see the Content-MD5 bits stay. I can import a license-friendly
set of MD5 routines to eliminate the external dependency.
The rest can go in the bin.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
- Remove rcvtty completely. This works in conjunction with slocal or
I would not be happy with that, I use slocal and rcvtty for
(user-configurable) new message notification.
Wow, ok ... I didn't think anyone used that, but I stand corrected. It
looks like what we did for OpenBSD was simply
Wow, ok ... I didn't think anyone used that, but I stand corrected. It
looks like what we did for OpenBSD was simply make rcvtty not work. Are
you fine with that? I'm not really interested in dealing with OpenBSD's
brokenness here.
Fine with me, I usually run some flavor of Linux.
Although it
I would like to see the Content-MD5 bits stay. I can import a
license-friendly set of MD5 routines to eliminate the external
dependency.
Well, it's not an external dependency exactly (but there is one for
the test suite). We have the library routines already. My real question
is: why keep it?
I have used it in the past, and plan to again on an upcoming project. It is a
fast and simple way to identify identical content when scanning large message
archives.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
Jerrad Pierce writes:
Wow, ok ... I didn't think anyone used that, but I stand corrected. It
looks like what we did for OpenBSD was simply make rcvtty not work. Are
you fine with that? I'm not really interested in dealing with OpenBSD's
brokenness here.
Fine with me, I usually run some
I have used it in the past, and plan to again on an upcoming
project. It is a fast and simple way to identify identical content when
scanning large message archives.
Fair enough; as long as someone's using it, that's good enough for me.
Although ... how does that work, exactly? You add
...
Ken Hornstein
Tuesday, January
01, 2013 8:56 AM
Greetings
all,...- Remove dbm/ndbm dependency. The ONLY reason
nmh has a dependency on a db library is for duplicate suppression
in slocal; if slocal finds a duplicate Message-ID, it discards it.
I didn't think
Please don't remove rcvtty -- I use it too -- and on OpenBSD no less,
with a tiny patch that brings back utmp support (so few lines, was it
really necessary to remove it?).
Yes. We made a decision to migrate to POSIX, and I wouldn't call the
amount of code removed small (look at the revision
ken wrote:
- Remove dbm/ndbm dependency. The ONLY reason nmh has a dependency on
a db library is for duplicate suppression in slocal; if slocal finds
a duplicate Message-ID, it discards it. I didn't think getting a dbm
library was so hard, but apparantly it is under Linux; the
Ken Hornstein writes:
Please don't remove rcvtty -- I use it too -- and on OpenBSD no less,
with a tiny patch that brings back utmp support (so few lines, was it
really necessary to remove it?).
Yes. We made a decision to migrate to POSIX,
I mentioned that utmpx is not required by POSIX,
31 matches
Mail list logo
