Re: request for SMTP integration (was Re: Mail using non-local SMTP server.)
> > Mutt doesnt ask for it - and postfix / exim / qmail dont implement DSN at all > > Postfix now supports DNS: > > Major changes with snapshot-2924 > > > DSN formatted bounced/delayed mail notifications, finally. The > human-readable text still exists, so that users will not have to > be unnecessarily confused by all the ugliness of RFC 1894. Postfix does _not_ support DSN. The ChangeLog above is about DNS-like formatting of notification messages! To support DSN, an internal protocol and interface redesign is necessary. This is not going to happen anytime soon.
Re: request for SMTP integration (was Re: Mail using non-local SMTP server.)
On Sat, May 19, 2001 at 02:52:01PM -0700, Monte Milanuk wrote: > I highly recommend the script 'install-sendmail' available at: > > http://cork.linux.ie/projects/install-sendmail/ Well, it may be wonderfull, but it didn't work for me -- I really, do not remember, what was the problem. But certainly, something like that (more robust -- if I recall it well, I created some reall mess by some typo). > This has helped me out _greatly_ over the years, and is by far the easiest method > I know of. Too bad it isn't more popular -- then someone might get around to > making similar facilities for postfix, exim, and qmail. Yes, something like that. Although, things are really much less necessary for postfix. I was able to get working postfix by merely grabbing RH-Postfix-HOWTO (www.redhat.com/support/docs/ -- I have not succeed with the parallel HOWTO on Sendmail). However, ... there are still some glitches, which I am not able to resolve: -- Message Delivery Notification (in both ways: so that I would confirm receipt as well as that I would be able to ask for it), -- etc. (I do not remember exactly, it is not so important and it is late in the night). Thanks for advice, anyway Matej -- Matej Cepl, [EMAIL PROTECTED] 138 Highland Ave. #10 Somerville, Ma 02143 (617) 623-1488
Re: request for SMTP integration (was Re: Mail using non-local SMTP server.)
> oddities. Meanwhile, Fetchmail, which actually exists to fit this role, > works to actually address all these things, and if you want to pop mail to > your machine from a remote account, something like this still makes the > most sense to use. If you don't like Fetchmail, you can use one of the > alternatives, or plug in your own. Why the heck should all those options > be re-implemented in all the individual MUAs, when they are not based on > reading mail, they are based on remote implementations and a transfer > protocol? Hi, I am sorry to contribute to this endless flamewar, but I may be helpfull to you being actuall luser (actually, I am former lawyer, now switching to study of social sciences). I really do not care whether SMTP capability is included in mutt or not. However, what DO I care a lot is an incredible pain in neck, which was to configure my MTA. I haven't found (and I tried) utility which would make configuration of sendmail easy (I have dial-up PPP conection to Internet without BIND). After trying count of them, I found postfix, which was certainly more simple than sendmail to be configured, but still it lages miles behind ease of setting up an account with GUI mailers (I am not using them, because KDE 2.0.1 on my only :-) 64 MB was slow as hell; when was acronym EMACS expanded to "Eight Megabytes And Continually Swapping"? :-). Therefore, what I would like to find is not getting SMTP in mutt (OK, I would love to have HTML mailing, but that's another story), but if there would be some REALLY simple cookbook-style HOWTO about setting up MTA over dial-up (or some WORKING utility to do it for me). BTW, I have asked whether it is possible to receive delivery (reading) notification with mutt & postfix and nobody answered. Would you, please? Have a nice day and happy flaming Matej
Re: request for SMTP integration (was Re: Mail using non-local SMTP server.)
Brendan Cully [mutt-users] : >nail. I've talked to him about IMAP and seen him trying to read his >mail on the road, and at least a couple of years ago he didn't >really seem to understand what IMAP was for. Probably had something >to do with the paucity of decent IMAP clients though... AFAIK, ESR uses mutt - and you can't get a more decent IMAP client than that ... -- 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 [010517 19:15] Mike Schiraldi <[EMAIL PROTECTED]> wrote: > Hey, i'm sick of using external encryption suites like GPG. I think mutt > should absorb all their functionality. And all those external apps in > .mailcap, too. And i'm sick of having to install Unix before i can use > mutt. mutt is unusable without an operating system, and it's foolish and > closed-minded to assume that newbies should have to install an operating > system just so they can use mutt. Why force them to configure both Linux and > mutt when the two can be combined to have one interface? Oh dear ;-). In which case, switch to Gnus would have to be the answer, though even emacs isn't an operating system, *yet*. I know what, though, why bother making them configure mutt, why not just give them a pencil and paper :-). HIBT? Lawrence -- Lawrence Mitchell | http://members.tripod.co.uk/EVSvienna/ [EMAIL PROTECTED] | No one was avoiding him, it was just that an apparent random Brownian motion was gently moving everyone away. -- (Terry Pratchett, Reaper Man)
Re: request for SMTP integration (was Re: Mail using non-local SMTP server.)
Brendan Cully wrote: > IMAP always gets dragged into this, and it's a red herring. Fetchmail > cannot fully replace the functionality of mutt's IMAP code, and > neither can any other tool. IMAP is a mailbox driver, and as such is > the province of the MUA. What confuses me about fetchmail is that if you read the documentation, or just use fetchmailconf, you'll see all kinds of blatant plugs for IMAP--things like IMAP is the best mail server protocal, it's the one the author uses, it's the best tested, etc. But, it seems to me that fetchmail is most useful for popping POP3 mail, and that it shouldn't be necessary to pop IMAP mail. Why the discrepacy? -Nelson
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 (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 (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 (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 (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/
