Re: config.h.in
Well, I did: make distclean autoconf ./configure make Errr ... you didn't run autoheader, as far as I can tell. --Ken
Re: nmh 1.1 release canidate uploaded
Shouldn't this be 1.5? Otherwise, you'll get folks confused. I seem to recall that the last official nmh release was 1.4 Last release was 1.0.4, not 1.4. So I think 1.1 is right. --Ken
Questions about nmh 1.1
Hi, I was wondering if you could list the features and new features (or reintegrated ones) of the 1.1 RC please -- -- === Christophe Prevotaux Email: [EMAIL PROTECTED] HEXANET SARLURL: http://www.hexanet.fr/ Z.A.C Les CharmillesTel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 61 77 72 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center ===
Re: folder-specific defaults? [long]
On July 4, 2002 at 09:45, [EMAIL PROTECTED] wrote: = Allow folder specific component files to be located in a centralized = location. For example, if I wanted a custom scan.monthly format = file for my inbox, I would create a file with a pathname of = `mhpath`/scan.monthly.inbox. It does get ambiguous with sub-folders = since '/' cannot be a pathname (maybe tranlate '/' to '.'). = = The only real reason I bring up this alternative is it protects a user = from losing custom format/component files when using the rmf command. There's another really good reason for this alternative. One of the strong features of [n]mh is that every mail message is a file, conversely, every fil e in a directory is presumed to be a mail message. Throwing meta-files into dat a directories will have side effects on things like glimpse indexing and any custom scripts that do things with every mail message in a directory. There is already precedence of meta files existing in folder directories in MH/nmh. Typically, if doing your own custom programming on message files, you restrict the set of files to numeric filenames. = Placing things in mail folders directly also breaks data abstraction. = I.e. A user of nmh can use nmh without even really caring if a folder = is a directory with files, a single file (aka mbox), or some kind of = fancy database. Sometimes the user cares--and assumes--that the folder is really a directory of files. The abstraction does not conflict with this. If an abstraction level is ever implemented, the default implementation would have to be capatible with the existing model or you have alot of upset users that have to muck with some upgrade process and breaking alot of their custom scripts. Of course, all implementation should be documented so savvy users could do custom programming as many do now. --ewh
Re: Questions about nmh 1.1
I was wondering if you could list the features and new features (or reintegrated ones) of the 1.1 RC please In short: - A bunch of new shit - A bunch of bug fixes But seriously ... that's a good question. I haven't had time to come up with a set of release notes. The one new feature I know about (because I worked on it) is SASL support for POP and SMTP, so inc and comp can use SASL to authenticate to POP and SMTP servers supporting SASL. --Ken
Re: Questions about nmh 1.1
I had hoped to see APOP in this list among other things and the ability to download only headers of messages in order to be able to delete only the message that we don't want (AntiSPAM like , well it is more like anti download huges unwanted files ) On Mon, 08 Jul 2002 11:21:25 -0400 Ken Hornstein [EMAIL PROTECTED] wrote: I was wondering if you could list the features and new features (or reintegrated ones) of the 1.1 RC please In short: - A bunch of new shit - A bunch of bug fixes But seriously ... that's a good question. I haven't had time to come up with a set of release notes. The one new feature I know about (because I worked on it) is SASL support for POP and SMTP, so inc and comp can use SASL to authenticate to POP and SMTP servers supporting SASL. --Ken -- -- === Christophe Prevotaux Email: [EMAIL PROTECTED] HEXANET SARLURL: http://www.hexanet.fr/ Z.A.C Les CharmillesTel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 61 77 72 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center ===
Re: Questions about nmh 1.1
I had hoped to see APOP in this list among other things Well ... shoot. I was under the impression that APOP is on it's way out to be replaced by the CRAM-MD5 mechanism that SASL uses. But I just checked, and it seems like you can enable APOP already with --enable-apop. So that's a non-issue, I think. and the ability to download only headers of messages in order to be able to delete only the message that we don't want (AntiSPAM like , well it is more like anti download huges unwanted files ) That's more of a protocol issue. It's not easy to do that within the context of POP. It _is_ possible just to get the headers within POP and I suppose inc could be changed to just retrieve the headers and make some sort of decision about whether to download the whole message or just delete it. But _that_ work would be complex. Feel free to send patches :-) --Ken
Re: Questions about nmh 1.1
On July 8, 2002 at 18:13, Christophe Prevotaux wrote: That's more of a protocol issue. It's not easy to do that within the context of POP. It _is_ possible just to get the headers within POP and I suppose inc could be changed to just retrieve the headers and make some sort of decision about whether to download the whole message or just delete it. But _that_ work would be complex. Feel free to send patches :-) There are tons of software that let you do this on the net Then why not use what is available? I don't believe it is so hard to do , however this would certainly require to create a new command in nmh and the addition of a few new options in the existing commands If it is implemented with new commands, one might as well use one the freely available tools on the net. If integrated into inc, rmm, et.al., it requires some work to make it seamless to the user. For example, when doing an inc (with some new download only headers when using POP), nmh will have to mark messages that only has header data, properly via some marker at the beginning of a message file. If show is used, nmh would have to download the message from the POP server on-the-fly. This could be a performance issue, requiring some kind of status to the user. With rmm, you have a similiar kind of situtation. Some kind of queuing could be done for rmm so POP commands are only done during the next message retrieval from the server or when some explicit flush operation is invoked. The on-the-fly show performance problem could be mitigated by some command, or option to existing command, to fetch all previously header only downloaded messages. --ewh
Re: Questions about nmh 1.1
On July 8, 2002 at 13:31, Ken Hornstein wrote: I believe the Spam filters that use POP3 simply download the whole message then make a decision, so that's not what you want. I believe I saw a project (Mailfilter?) listed on freshmeat that would work just with the headers. There are quite a few POP mail filter programs listed at freshmeat, so I recommend that the original poster check it out. One could probably roll their own with the Perl and the Net::POP module -- which I have considered doing, but the need has not become deperate enough. --ewh
Re: Questions about nmh 1.1
[In a message on Mon, 08 Jul 2002 15:03:37 CDT, the pithy ruminations of Earl Hood were:] On July 8, 2002 at 18:13, Christophe Prevotaux wrote: That's more of a protocol issue. It's not easy to do that within the context of POP. It _is_ possible just to get the headers within POP and I suppose inc could be changed to just retrieve the headers and make some sort of decision about whether to download the whole message or just delete it. But _that_ work would be complex. Feel free to send patches :-) ... If integrated into inc, rmm, et.al., it requires some work to make it seamless to the user. For example, when doing an inc (with some new download only headers when using POP), nmh will have to mark messages that only has header data, properly via some marker at the beginning of a message file. If show is used, nmh would have to download the message from the POP server on-the-fly. This could be a performance issue, requiring some kind of status to the user. With rmm, you have a similiar kind of situtation. Some kind of queuing could be done for rmm so POP commands are only done during the next message retrieval from the server or when some explicit flush operation is invoked. I have to admit, I kinda like the idea of integrating pop a little more seamlessly into nhm. scan, inc, show and rmm could all be made to work reasonably well with POP/IMAP. OK, yeah, there's the huge startup times compared to what we're used to, but there are time I want to be able to peek into a remote mailbox and twiddle it without downloading all of it (yes, I can use other apps, but I don't want to). As for patches. . . Well, someday. Sean
Re: Questions about nmh 1.1
On July 8, 2002 at 11:21, Ken Hornstein wrote: But seriously ... that's a good question. I haven't had time to come up with a set of release notes. The one new feature I know about (because I worked on it) is SASL support for POP and SMTP, so inc and comp can use SASL to authenticate to POP and SMTP servers supporting SASL. A suggestion: I try to advocate in the development projects I work on to have each developer update the ChangeLog, NEWS, History, whatever file whenever the developer commits changes to the repository that should be noted to end-users of the project. This way, there isn't the mad scramble of trying to remember all the changes that have been done before doing a release. --ewh
Re: Questions about nmh 1.1
On July 8, 2002 at 11:05, Jon Steinhart wrote: And I agree, downloading the entire message is the way to go. Most spam is very small compared to even slow V90 speeds which is what I'm stuck with out in the country here, so it's no big deal. Well, I would have to disagree about spam being small and no big deal over V90 modem. Spam messages have been increasing in size since many are HTML messages and some with attachments or images. Also, if you are flooded with alot of messages, they add up. Of course, the annoyance factor is relative for any given person, but when I was using dialup, I definitely considered writing my own POP filtering tool with interactive capabilities to avoid downloading crap (and sometimes the messages may not be spam but from friends and/or relatives sending huge-assed attachments that I did not care about). However, once I got cable modem, my need for such a tool dropped considerably. A side note: I considering spam filtering, and other filtering needs, mainly delivery issue. Hence, I think it is best solved done before nmh even sees the mail (the boundary is somewhat lose when dealing with automatic filing of messages to different folders). This keeps the filtering job independent of the MUA and prevent developers re-implementing the wheel for every MUA. I have a set of changes that I'll submit at an appropriate time. These changes allow .mh_profile entries that name programs that are executed whenever a piece of mail is incorporated, removed, or refiled. A nice feature. --ewh This has the potential to go way off topic for this mailing list, but... I agree that a fair number of bytes are consumed by spam. It isn't a huge problem for me because even though V90 is the best that I can do out here in the sticks, it's a full time connection so I'm not waiting on mail delivery. I find it hard to see filtering as a delivery issue, but that's probably because I read my mail on my machine which uses sendmail to deliver mail; I'm not dialing in somewhere to pick up mail. If I need to read mail on the road, I ssh into my machine and read it there. The big issue on filtering is that everybody wants to filter different things. Strange as it seems, some people even like to collect spam for study. One of the big difficult issues on filtering is that, while an occasional false positive can be tolerated, false negatives are completely unacceptable. A system that keeps all of your mail and only shows you interesting messages doesn't lose anything, which helps that problem. But it requires sucking down all messages. Another example, I remember Gosling telling me that especially since he's become embroiled in the Sun/MS suits that a mirror copy of all of his incoming and outgoing mail is kept for legal reasons. This wouldn't work if incoming mail was rejected based on headers. Jon
