Re: [Nmh-workers] external MTA (was: nmh @ gsoc?)
On Thu, 28 Jan 2010 11:04:15 +0100, markus schnalke said: Use a simple forwarding MTA (like nullmailer or ssmtp) instead. Still more complicated than the one-line change to one file it took to change the SMTP server in nmh. ;) For the user, shipping an own forwarder is not much different than providing a good tutorial on how to use an external program for the job. And if it is a problem, then this user is hardly a user of nmh anyway. /me looks around and finds some files under ~/Mail that date to 1988... pgpE8GKEzT8Ca.pgp Description: PGP signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] external MTA (was: nmh @ gsoc?)
[2010-01-27 18:01] valdis.kletni...@vt.edu On Wed, 27 Jan 2010 23:21:10 +0100, markus schnalke said: TLS seems to be already solved. However, why does nmh need TLS? Doesn't it delegate mail transfer to an MTA? You may need it to talk to a remote MTA that insists on doing TLS. And there's valid use cases for it. Half the time my laptop is at home, so letting my local sendmail do the delivery isn't workable, lot of sites whinge at the fact that it's a cablemodem address. So if I want my mail delivered, my easiest is to forward through the MTA here at work. And it was easier to just tell nmh to forward rather than have it point at the local sendmail and reconfig that to forward. Use a simple forwarding MTA (like nullmailer or ssmtp) instead. Instead of having one program inside nmh to forward, use one external program to forward. The external program will surely do the job better than the internal one. (Do you need reasons for this statement?) For the user, shipping an own forwarder is not much different than providing a good tutorial on how to use an external program for the job. And if it is a problem, then this user is hardly a user of nmh anyway. meillo ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] external MTA (was: nmh @ gsoc?)
markus == markus schnalke mei...@marmaro.de writes: markus Use a simple forwarding MTA (like nullmailer or ssmtp) markus instead. okay. That would work for me. The work would still be there to essentially: a) rip out everything else. b) adjust packages such that nullmailer/ssmtp is a dependancy. c) provide an interface to collect the user's various relay authentication tokens and configure said mailer. markus For the user, shipping an own forwarder is not much different than markus providing a good tutorial on how to use an external program for the markus job. And if it is a problem, then this user is hardly a user of nmh markus anyway. nmh is the swiss-army knife of mail user agents. We have several graphical MUAs that sit on top of it, and I'd like to see more of them, not fewer. I do not want thunderbird and all the like to have to reinvent everything. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] external MTA (was: nmh @ gsoc?)
Instead of having one program inside nmh to forward, use one external program to forward. The external program will surely do the job better than the internal one. (Do you need reasons for this statement?) Actually, you're going to have to provide some reasons ... I looked at the examples you provided (nullmailer and ssmtp), and they lack functionality that nmh provides, today (that's not to say that nmh can do everything those programs can, but my point is that nmh can do things that they cannot). And I guess I really don't understand your fundamental reasoning about external programs always being better than an internal one. For the user, shipping an own forwarder is not much different than providing a good tutorial on how to use an external program for the job. And if it is a problem, then this user is hardly a user of nmh anyway. So, you don't care about unsophisticated users, then? You need a certain level of Unix configuration knowledge to use nmh? --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] external MTA (was: nmh @ gsoc?)
We have several graphical MUAs that sit on top of it, and I'd like to see more of them, not fewer. I do not want thunderbird and all the like to have to reinvent everything. The problem I see is that if part of your GUI configuration involves setting up a local email forwarder ... well, kinda a non-starter, in my mind. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] external MTA (was: nmh @ gsoc?)
On January 28, 2010 at 11:04, markus schnalke wrote: Use a simple forwarding MTA (like nullmailer or ssmtp) instead. Has anyone got either of these programs to work with nmh? If so, can they share their configuration? IIRC, ssmtp is a command-line replacement of sendmail vs running as a daemon. MH/nmh communicate with sendmail via the -bs option, something ssmtp does not support I believe. I have not looked at nullmailer. First I've heard of it. Does it support -bs mode of sendmail? Can it run as a daemon and accept SMTP connections directly? --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] external MTA (was: nmh @ gsoc?)
[2010-01-28 10:43] Ken Hornstein k...@pobox.com Instead of having one program inside nmh to forward, use one external program to forward. The external program will surely do the job better than the internal one. (Do you need reasons for this statement?) Actually, you're going to have to provide some reasons ... I looked at the examples you provided (nullmailer and ssmtp), and they lack functionality that nmh provides, today (that's not to say that nmh can do everything those programs can, but my point is that nmh can do things that they cannot). I just took two programs that came to my mind. If nmh's mail forwarding code is good, then it might be worth to exclude it into a standalone program, and have it as a dependency for nmh (just like some library). And I guess I really don't understand your fundamental reasoning about external programs always being better than an internal one. As I wrote in the other mail: I assume that you will do one job at a time always better than two jobs at the same time. For the user, shipping an own forwarder is not much different than providing a good tutorial on how to use an external program for the job. And if it is a problem, then this user is hardly a user of nmh anyway. So, you don't care about unsophisticated users, then? You need a certain level of Unix configuration knowledge to use nmh? Unsophisticated users will install nmh with a packaging system. Then the appropriate external tools get installed automatically. If one likes to install nmh from source, then the dependency on an external tool is like the dependency to an external library. meillo ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] external MTA (was: nmh @ gsoc?)
[2010-01-28 09:48] Michael Richardson m...@sandelman.ca markus == markus schnalke mei...@marmaro.de writes: markus Use a simple forwarding MTA (like nullmailer or ssmtp) markus instead. okay. That would work for me. The work would still be there to essentially: a) rip out everything else. b) adjust packages such that nullmailer/ssmtp is a dependancy. Yes. Note, that I don't think that it is good to do this within a day. Changes need time. But generally, this is what I think is good. c) provide an interface to collect the user's various relay authentication tokens and configure said mailer. The needed data for the configuration would be not different from what is needed for the nmh send facility. One needs to write a different file in a different format. We have several graphical MUAs that sit on top of it, and I'd like to see more of them, not fewer. I do not want thunderbird and all the like to have to reinvent everything. But nmh reimplements functionality that is already available in other software (e.g. MTA), that could be used. I'm not quite sure, maybe you mean the transition problems. The ``user'' interface of nmh would not change, thus tools on top of nmh don't need to change. The nmh package would depend on an external tool (like if it would depend on an external library). meillo ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] external MTA (was: nmh @ gsoc?)
[2010-01-28 10:37] Earl Hood e...@earlhood.com On January 28, 2010 at 11:04, markus schnalke wrote: Use a simple forwarding MTA (like nullmailer or ssmtp) instead. IIRC, ssmtp is a command-line replacement of sendmail vs running as a daemon. MH/nmh communicate with sendmail via the -bs option, something ssmtp does not support I believe. I have not looked at nullmailer. First I've heard of it. Does it support -bs mode of sendmail? Can it run as a daemon and accept SMTP connections directly? -bs mode was what I would like to avoid because this is where SMTP is involved. Piping the mail (= the output of `list' in the whatnow prompt) to /usr/sbin/sendmail (= the compatibility interface) is what I would prefer. meillo ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
