Re: request for SMTP integration
On 2001-05-16 20:22:09 -0400, Rich Lafferty wrote: >You'd be surprised. "Use mutt with -x" is a standard answer to the >(increasingly common) question, "How can I send mail with an >attachment from my noninteractive process?" (Except that they >usually mispel "noninteractive process" as "CGI script".) Why do you use -x for that? It's not needed in batch mode - just give the headers (subject, cc, bcc, ...) on the command line and feed the letter's body to stdin. -- Thomas Roesslerhttp://log.does-not-exist.org/
Re: fetchmail and mutt?
Michael Tatge [mutt-users] : > dave hoye muttered: > > I would like to have fetchmail retrieve my messages from within mutt. > > This way procmail is able to move the messages to the proper folders. > > The way I currently have mutt configured, -all- of the mail goes to my > You mean like: > macro index \ea !fetchmail "run fetchmail" > Configure fetchmail to use procmail as mda or have your MTA call > procmail and you're done. Fetchmail hands off to your local $MTA (which then uses its local delivery agent - lmtp, deliver, procmail, whatever. If you configure your local MTA to handoff to procmail (FEATURE(`local_procmail') and MAILER(`procmail') in sendmail) then this is out of the box. -s -- Suresh Ramasubramanian + Wallopus Malletus Indigenensis mallet @ cluestick.org + Lumber Cartel of India, tinlcI EMail Sturmbannfuhrer, Lower Middle Class Unix Sysadmin
Re: request for SMTP integration (was Re: Mail using non-local SMTP server.)
Thomas Roessler [mutt-users] : > Pine also includes a crappy editor (pico - which is nevertheless > used by some people in order to ruin their configuration files), and > a full-blown file manager (pilot, if I recall this correctly). Pico is a pretty good editor for newbies (at whom pine was originally targeted) :) Plus, it comes in handy when you just want to type text and send out mail, rather than bothering with "esc : foo bar" or "alt meta cokebottle" keybindings - a definite plus which has helped several of my friends start using mutt faster than if they'd have to learn vi / emacs :) And no, it's not used for editing config files - just for basic text editing :) > (OK, we have a directory browser, too, and a tight integration > between editor and mailer has a few pros ;-)) If integration was what they needed, people would use a package that's a browser + mail / news reader + editor + (either netscape communicator or emacs) :) -- Suresh Ramasubramanian + Wallopus Malletus Indigenensis mallet @ cluestick.org + Lumber Cartel of India, tinlcI EMail Sturmbannfuhrer, Lower Middle Class Unix Sysadmin
Re: request for SMTP integration
On Wed, May 16, 2001 at 05:27:44PM -0400, William Park ([EMAIL PROTECTED]) wrote: > On Wed, May 16, 2001 at 11:04:18PM +0200, Thomas Roessler wrote: > > On 2001-05-16 16:39:32 -0400, Mr. Wade wrote: > > > > >Mutt also has a built-in editor, "crappy" or otherwise, not that I > > >make a habit of using it very often. unset $editor or specify > > >"-x" on the commandline, not that I make a practice of using it > > >very often. :o) > > > > It doesn't even have a full-screen mode. ;-) > > > > It's just there in order to add some kind of mailx send-mode > > emulation to mutt. > > Why not just get rid of built-in editor, mailx emulation, and other > silly "backward" compatibility stuffs? Nobody really uses Mutt for > mailx emulation! You'd be surprised. "Use mutt with -x" is a standard answer to the (increasingly common) question, "How can I send mail with an attachment from my noninteractive process?" (Except that they usually mispel "noninteractive process" as "CGI script".) -Rich -- -- Rich Lafferty --- Sysadmin/Programmer, Instructional and Information Technology Services Concordia University, Montreal, QC (514) 848-7625 - [EMAIL PROTECTED] --
Re: request for SMTP integration
On Wed, May 16, 2001 at 11:04:18PM +0200, Thomas Roessler wrote: > On 2001-05-16 16:39:32 -0400, Mr. Wade wrote: > > >Mutt also has a built-in editor, "crappy" or otherwise, not that I > >make a habit of using it very often. unset $editor or specify > >"-x" on the commandline, not that I make a practice of using it > >very often. :o) > > It doesn't even have a full-screen mode. ;-) > > It's just there in order to add some kind of mailx send-mode > emulation to mutt. Why not just get rid of built-in editor, mailx emulation, and other silly "backward" compatibility stuffs? Nobody really uses Mutt for mailx emulation! -- William Park, Open Geometry Consulting, Mississauga, Ontario, Canada. 8 CPU cluster, (Slackware) Linux, Python, LaTeX, vim, mutt
fetchmail and mutt?
All, I would like to have fetchmail retrieve my messages from within mutt. This way procmail is able to move the messages to the proper folders. The way I currently have mutt configured, -all- of the mail goes to my spool file (procmail evidently is not being run on these messages). In order to get around this problem, I've been calling fetchmail through a shell escape. I figure there should be a way to create a macro that does this, but I haven't had any luck in mapping it to mutt. dave
Confirmation of receipt?
Hi, would some nice member of this list tell me, whether I could create %subj%, please (with references to some docs)? I know, that there are some objections about using it, but I kinda like it. I believe that what I need is MDN functionality, but I am not sure how to achieve this with my current MTA, which is postfix-20010228release3rh6. Does anybody help me? Thank you very much Matej -- Matej Cepl, [EMAIL PROTECTED] 138 Highland Ave. #10 Somerville, Ma 02143 (617) 623-1488
Re: request for SMTP integration
On 2001-05-16 16:39:32 -0400, Mr. Wade wrote: >Mutt also has a built-in editor, "crappy" or otherwise, not that I >make a habit of using it very often. unset $editor or specify >"-x" on the commandline, not that I make a practice of using it >very often. :o) It doesn't even have a full-screen mode. ;-) It's just there in order to add some kind of mailx send-mode emulation to mutt. (Anyone interested in doing a line-mode interface for message reading, kind of mailx with MIME? NOT!) -- Thomas Roesslerhttp://log.does-not-exist.org/
Re: request for SMTP integration (was Re: Mail using non-local SMTP server.)
On 2001-05-16 15:24:24 -0400, Brendan Cully wrote: >what would be cool is if you could say >sendmail='securesendmail -u $smtp_user -p $smtp_pass' >ie mutt exposes its config variables, and reevaluates them when >running the command. But I haven't thought about how to do that, >it's certainly invasive and probably would make the config engine >less efficient. Passing passwords on the command line means exposing them to other users on the system running ps. Storing them in mode 600 files is certainly more secure. (Implementation-wise, this would just boil down to yet another format expansion, with the slight problem that sendmail is currently invoked differently from all other child processes: We pass command line parameters in an argv[] array instead of producing a string which is sent to the shell.) -- Thomas Roesslerhttp://log.does-not-exist.org/
Re: request for SMTP integration
Thomas Roessler wrote: > Pine also includes a crappy editor (pico - which is nevertheless > used by some people in order to ruin their configuration files), and > a full-blown file manager (pilot, if I recall this correctly). > > Just don't quote it as an example. > > (OK, we have a directory browser, too, and a tight integration > between editor and mailer has a few pros ;-)) Mutt also has a built-in editor, "crappy" or otherwise, not that I make a habit of using it very often. unset $editor or specify "-x" on the commandline, not that I make a practice of using it very often. :o) -- Linux: The Choice of the GNU Generation
Re: request for SMTP integration (was Re: Mail using non-local SMTP server.)
On 2001-05-16 23:31:03 +0530, Suresh Ramasubramanian wrote: >Pine for instance? It normally delivers to local sendmail, but >will happily deliver to an external delivery server (using >sendmail -bs and talking smtp) Pine also includes a crappy editor (pico - which is nevertheless used by some people in order to ruin their configuration files), and a full-blown file manager (pilot, if I recall this correctly). Just don't quote it as an example. (OK, we have a directory browser, too, and a tight integration between editor and mailer has a few pros ;-)) -- Thomas Roesslerhttp://log.does-not-exist.org/
Re: request for SMTP integration (was Re: Mail using non-local SMTP server.)
Some people wrote: > > Sorry, but Unix is built out of tools. Use them (or use Emacs, which > > has everything built in). > > > You mean mutt should be like emacs and have everything built-in? Not to start another flamewar, but emacs doesn't have everything "built-in". Rather, functionality is extended through external lisp modules. This is significantly different than adding functionality directly to the core program source. Extensibility is cool. Code bloat is not. -Nelson
Re: request for SMTP integration
On 2001-05-16 17:01:16 +0200, Dumas Patrice wrote: >It is my opinion, and I am not a sysadmin, but if I were ;-), I >wouldn't like sendmail or even postfix to be installed on >workstations, as I think it is bad and unusefull in a classical >LAN architecture. sSMTP is a good replacement, but has to be >configured by root. First of all, there may be quite a few reasons why you want to have something like /usr/sbin/sendmail on a Unix workstation, even if no instance of sendmail is listening on port 25. (Actually, I have occasionally been using ssmtp for this.) Second, ssmtp doesn't have to be configured by root - there is nothing in this program which requires privileges, so it should be a trivial exercise to hack ssmtp to read its configuration file from, say, ~/.ssmtprc. -- Thomas Roesslerhttp://log.does-not-exist.org/
macro help
I'm trying to create an index macro to mark all messages as read in all my mailboxes. It will switch to all mailboxes, but isn't changing any flags. Any ideas? Here's the macro... macro index ...c "c=box1\n;T.*\n;WN;^t.*\n;T.*\n;WN;^t.*\n;c=box2\n;c=Inbox\n;T.*\n;WN;^t.*\n;c=box3-users\n;T.*\n;WN;^t.*\n;c=box4\n;T.*\n;WN;^t.*\n;c=box5\n;T.*\n;WN;^t.*\n;c=box6\n;T.*\n;WN;^t.*\n;c=box7\n" "mark all in all as read" Thanks, Dan
Re: request for SMTP integration (was Re: Mail using non-local SMTP server.)
Biju Chacko proclaimed on mutt-users that: > On Wed, May 16, 2001 at 02:40:33PM +0200, Andre Majorel wrote: > > Then you would better serve your agenda by contributing to that > > project than by lobbying for Mutt to bend in that direction. If > > you want to work on an SMTP-aware MUA, more power to you. But > > don't make Mutt users pay for something they won't use. > While I agree with the need to keep one's MUAs and MTAs seperate, I find your > argument flawed. There are literally dozens of features of Mutt that I don't > use. Does that mean I ought to object to development in those areas? I don't > think so. Pine for instance? It normally delivers to local sendmail, but will happily deliver to an external delivery server (using sendmail -bs and talking smtp) -- Suresh Ramasubramanian + Wallopus Malletus Indigenensis mallet @ cluestick.org + Lumber Cartel of India, tinlcI EMail Sturmbannfuhrer, Lower Middle Class Unix Sysadmin
Re: request for SMTP integration (was Re: Mail using non-local SMTP server.)
On Wed, May 16, 2001, Louis-David Mitterrand wrote: > Yes, telling the user "try later" or "postpone your message and fix your > config" is better than injecting the message into a poorly configured > /usr/sbin/sendail that will drop it on the floor without reporting it. What a great alternative... how about not breaking the MTA in the first place? > > Sorry, but Unix is built out of tools. Use them (or use Emacs, which > > has everything built in). > > You mean mutt should be like emacs and have everything built-in? That's what you seem to want, not me. Please read my sentence again. If you want everything in one "program": use emacs. > Either we agree or you contradict yourself. Neither nor. On Wed, May 16, 2001, Louis-David Mitterrand wrote: > Certainly not. Who needs a queue? Either the mail is delivered or the > user will be presented with a failure and invited to postpone his > message and fix his config or ask the admin what's wrong with the relay > MTA. Very useful (NOT). I had the "fun" of having to deal with an "MTA" that didn't queue message in case of temporary failures. It's just plain stupid. This discussion is useless. See my first answer: you can do whatever you want. Use the source, you got it (and even a "patch").
Re: request for SMTP integration (was Re: Mail using non-local SMTP server.)
On Wed, May 16, 2001 at 05:50:34PM +0200, Louis-David Mitterrand ([EMAIL PROTECTED]) wrote: > * On Wed, May 16, 2001 at 07:54:01AM -0700, Claus Assmann wrote: > > On Wed, May 16, 2001, Louis-David Mitterrand wrote: > > > > > > You're going to add an MTA first (reimplement sendmail). Then > > > > > > Huh? Adding a few dozen lines of code to deliver via SMTP is > > > "reimplementing sendmail"? You need a serious reality check. > > > > "a few dozen lines of code"... Did you ever write a SMTP client? > > > > Oh yeah, let's start "simple": no queueing, just EHLO (oops, can't > > use that always, so maybe HELO), MAIL, RCPT, DATA, QUIT. What about > > temporary errors? Do you tell the user: sorry, please try again > > later? Or do you implement queueing? Who runs the queue? When? > > Yes, telling the user "try later" or "postpone your message and fix your > config" is better than injecting the message into a poorly configured > /usr/sbin/sendail that will drop it on the floor without reporting it. Telling the user "try later" is also better than writing it to a disk and dropping the disk into a garbage compactor. What's your point? How'd they get mutt installed if they can't install ssmtp or nullmailer? Does anybody on this list knows of anybody who does not use Mutt because it does not provide SMTP, and refuses to install ssmtp or nullmailer despite the fact that all of the *other* mail-related things (cron, for instance, or their newsreader) on their system will be unable to send mail? I see no evidence that that isn't just a huge red herring. I can't believe that there is a large group of users out there that refuse to allow their Unix system to understand mail. -Rich -- -- Rich Lafferty --- Sysadmin/Programmer, Instructional and Information Technology Services Concordia University, Montreal, QC (514) 848-7625 - [EMAIL PROTECTED] --
Re: request for SMTP integration (was Re: Mail using non-local SMTP server.)
On 2001-05-16 19:31 +0530, Biju Chacko wrote: > On Wed, May 16, 2001 at 02:40:33PM +0200, Andre Majorel wrote: > > But don't make Mutt users pay for something they won't use. > > While I agree with the need to keep one's MUAs and MTAs seperate, I find your > argument flawed. There are literally dozens of features of Mutt that I don't > use. What this argument means is that adding an MTA to Mutt would very likely lead to adding many other features. More features means more doc, making it harder for new users to find their way around it. Said documentation must also be written and maintained, leading to an increased workload on maintainers. It is also very likely to become less accurate as a result. The increased amount of code would probably have similar undesirable consequences. Such as more bugs and longer intervals between releases. Adding features is generally costly because complexity increases more than linearly with features. It should be avoided unless it buys us something truly useful, which is IMHO not the case here. -- André Majorel Work: <[EMAIL PROTECTED]> Home: <[EMAIL PROTECTED]> http://www.teaser.fr/~amajorel/
Re: request for SMTP integration (was Re: Mail using non-local SMTP server.)
On Wed, May 16, 2001 at 04:11:46PM +0200, Louis-David Mitterrand wrote: > * On Wed, May 16, 2001 at 03:50:45PM +0200, Frank Derichsweiler wrote: > > Sorry, but _IMHO_ a person not willing to install / use a MTA separat > > from Mutt will not use mutt either. He want to use some software with > > a polished GUI with some buttons to click and press and all that suff ... > > Installing a very tiny one should be no problem. > > Step down from your high horses for a minute and consider: It is not easy to convince somebody to use a textual-only MUA. _IMHO_ some people would like to get the ultimate tool which can solve all theirs problems. What is wrong about "separation of concerns". Just keep different things different. Producing mail with an MUA and delivery of a mail by a MTA are definitely two different things. Therefore I do not see _any_ _good_ reason for a _tight_ integration of SMTP-features into mutt. > - many windows users have dear memories their DOS sofware and > (Wordperfect 5.1 anyone?) and would welcome a Cygwin mutt, but not at > the price of configuring some additional software, Then the cygwin mutt should also provide a tiny SMTP server, but _separate_ from the mutt executable. > > Developers, please keep all that SMTP-stuff out of mutt. > > In what way can you be inconvenienced by an _optional_ feature you are > _not_ required to use? That baffles my ass to no end. Optional features make it in some sense harder to maintain the software. In case of _tight_ integration _into_ mutt the mutt developers have to take care of the SMTP part of the programm, too. _I_ _personally_ do not have a problem, if you can download a mutt++ package, which includes the "core" mutt, a tiny SMTP send-only server and some scripts to configure and build both togehter. But keep the two things separate. > > As already posted the suggestion to add a small MTA as a separate > > program with separate options and separate configuration should be an option. > > Half-measure. Integrate the damn patch already and make it a > compile-time option. > _You_ might want to provide such a patch. I ask the mutt developers to focus on the _core_ _MUA_ functionality. Frank
Re: request for SMTP integration
On Wed, May 16, 2001 at 05:01:16PM +0200, Dumas Patrice wrote: > When users haven't root privileges, it isn't possible to configure > any MTA I know. Maybe there exits such a MTA, but I don't know it. sendmail may be invoked from the command line by any user. In fact, you can use it in place of a MUA if you're *really* strange. I guess the point is that you don't have to be running an SMTP service to make use of sendmail. > It is my opinion, and I am not a sysadmin, but if I were ;-), I > wouldn't like sendmail or even postfix to be installed on > workstations, as I think it is bad and unusefull in a classical LAN > architecture. Not at all. My organisation (guess?) has sendmail installed on *every* workstation, although most of the deployed MUAs don't use it. The stock configuration relays to smarthosts only. This isn't at all unusual. Kinda like running a caching-only instance of named on every workstation, it can be useful. Especially for someone such as myself, who isn't keen on the deployed MUAs. cheers j -- .sigbot at contact-j @ bast.corp.sun.com for phone/address etc ++---+ | ECHELON Fodder | CCSQ IDP Corporate Security stakeout | || NADDIS AIEWS | ++---+
Re: request for SMTP integration
On Wed, May 16, 2001 at 05:01:16PM +0200, Dumas Patrice ([EMAIL PROTECTED]) wrote: > Hi, > > I think there is an argument in favor of including rough support of > MTA in mutt, which is that MTA handling should be a system > administrator (root) task and not a user's task. It is especially > true with MTA which listens on the SMTP port. Then you've been misreading pretty much everyone's point thus far. Sending mail is the task of an MTA, whether it be something that someone who has the root password installed, or something that someone who has a user's password installed. Listening on the SMTP port has absolutely nothing at all to do with sending mail. > When users haven't root privileges, it isn't possible to configure > any MTA I know. Maybe there exits such a MTA, but I don't know it. An MTA that is there to *send* mail does not have dto listen to *receive* mail. > It is my opinion, and I am not a sysadmin, but if I were ;-), I > wouldn't like sendmail or even postfix to be installed on > workstations, as I think it is bad and unusefull in a classical LAN > architecture. sSMTP is a good replacement, but has to be configured > by root. This is not correct. Please try it before claiming it can't be done. And you're right, you're *not* a sysadmin, because you seem to have forgotten that there is much on a Unix system that sends mail other than a full-screen MUA -- cron, for example. What's it going to use? -Rich -- -- Rich Lafferty --- Sysadmin/Programmer, Instructional and Information Technology Services Concordia University, Montreal, QC (514) 848-7625 - [EMAIL PROTECTED] --
Re: request for SMTP integration
Hi, I think there is an argument in favor of including rough support of MTA in mutt, which is that MTA handling should be a system administrator (root) task and not a user's task. It is especially true with MTA which listens on the SMTP port. When users haven't root privileges, it isn't possible to configure any MTA I know. Maybe there exits such a MTA, but I don't know it. It is my opinion, and I am not a sysadmin, but if I were ;-), I wouldn't like sendmail or even postfix to be installed on workstations, as I think it is bad and unusefull in a classical LAN architecture. sSMTP is a good replacement, but has to be configured by root. Notice that it isn't a request, but only an thought. And notice also that my example come from a real life situaton, where a 'courageous' user in a NT environment use linux, with sysadmins having no time to bother with that singularity, but also picky on security. Pat
Re: request for SMTP integration (was Re: Mail using non-local SMTP server.)
On Wed, May 16, 2001, Louis-David Mitterrand wrote: > > You're going to add an MTA first (reimplement sendmail). Then > > Huh? Adding a few dozen lines of code to deliver via SMTP is > "reimplementing sendmail"? You need a serious reality check. "a few dozen lines of code"... Did you ever write a SMTP client? Oh yeah, let's start "simple": no queueing, just EHLO (oops, can't use that always, so maybe HELO), MAIL, RCPT, DATA, QUIT. What about temporary errors? Do you tell the user: sorry, please try again later? Or do you implement queueing? Who runs the queue? When? What about SMTP AUTH, STARTTLS, DSN, DELIVER-BY, ... ? Sorry, but Unix is built out of tools. Use them (or use Emacs, which has everything built in). Or the other answer: you got the source, you can add the functionality as you like. Publish it and see what happens.
Re: request for SMTP integration (was Re: Mail using non-local SMTP server.)
On Wed, May 16, 2001 at 02:40:33PM +0200, Andre Majorel wrote: > Then you would better serve your agenda by contributing to that > project than by lobbying for Mutt to bend in that direction. If > you want to work on an SMTP-aware MUA, more power to you. But > don't make Mutt users pay for something they won't use. While I agree with the need to keep one's MUAs and MTAs seperate, I find your argument flawed. There are literally dozens of features of Mutt that I don't use. Does that mean I ought to object to development in those areas? I don't think so. If somebody wants SMTP support -- well he is free to maintain a patch to do so... or if he is unable to do it himself, to lobby for somebody to do it. Biju -- - Biju Chacko| [EMAIL PROTECTED] (work) Exocore Consulting | [EMAIL PROTECTED] (play) Bangalore, India | http://www.exocore.com -
Re: request for SMTP integration (was Re: Mail using non-local SMTP server.)
On Wed, May 16, 2001 at 11:45:51AM +0200, Louis-David Mitterrand wrote: > Seriously, installing, configuring, running, administering a simple MTA > like ssmtp may be not much to ask but it's still another piece of > software to deal with, concepts to master, docs to read, precious time > people don't have. Sorry, but _IMHO_ a person not willing to install / use a MTA separat from Mutt will not use mutt either. He want to use some software with a polished GUI with some buttons to click and press and all that suff ... Installing a very tiny one should be no problem. BTW Many Linux distributions (yes, mutt is used on many other OS, too, _no_ OS-war) provide a preconfigured MTA. The user has just to configure it. Using all those graphical frontends that should be no problem. Therefore I do not see the direct profit for integrating SMTP into mutt. Developers, please keep all that SMTP-stuff out of mutt. As already posted the suggestion to add a small MTA as a separate program with separate options and separate configuration should be an option. Just my 2 cents, Frank
Re: request for SMTP integration (was Re: Mail using non-local SMTP server.)
On 2001-05-16 11:45 +0200, Louis-David Mitterrand wrote: > Purists and > Cassandras that cry out each time a user asks for SMTP delivery in mutt > are out of touch. No they're not. They're very much in touch with what they need and want. > Mutt should be accessible out of the box. It should work immediately > without any need for external utilities. You're going to add an MTA first (reimplement sendmail). Then someone is going to say "what about filtering" ? So you're going to reimplement procmail, badly. And then somebody else is going to say "wouldn't it be nice if it read HTML ?" or "hey, where is the GUI ?" or "but it's not integrated with KDE !". And so on. If you want Netscape or OE, you know where to find them. Please leave Mutt alone. > Let's try to bridge the gap between "us" and "them". Why not but not at our expense. > PS: see nail's home page at http://omnibus.ruf.uni-freiburg.de/~gritter/ > for a minimalist, hard-core Unix MUA that thinks SMTP if good idea Then you would better serve your agenda by contributing to that project than by lobbying for Mutt to bend in that direction. If you want to work on an SMTP-aware MUA, more power to you. But don't make Mutt users pay for something they won't use. -- André Majorel Work: <[EMAIL PROTECTED]> Home: <[EMAIL PROTECTED]> http://www.teaser.fr/~amajorel/
