On Mon, 2004-01-19 at 09:57 -0500, pkm wrote: > Regarding using "sendmail", I never meant that I wanted to use the crappy > old sendmail, I mean <quote>sendmail</quote>; whichever one you use (I use > esmtp).
I don't understand. Evo uses whatever's at _PATH_SENDMAIL, and just about every sendmail replacement works identically, as far as Evo is concerned. What precisely would you _want_ it to do? It'll also connect to localhost:25 and submit mail to your own MTA if you ask it to. The only thing I can imagine you want is for it to use the '-f' option to $SENDMAIL to set the SMTP reverse-path. But that's a privileged option normally anyway, isn't it? I cannot comprehend a problem which would be solved by this ... although actually I _would_ like to configure the command used, since I'd like to make it run 'ssh mail.$DAVES_EMPLOYER.internal exec /usr/lib/sendmail' instead of running it locally in certain circumstances, since some internal mailing lists won't accept mail from the outside. > > > I am a little dissappointed that I can not have fetchmail run > > > when I press the 'Send/Receive' button, or have any control over the > > > options passed to sendmail. > > > > Why use fetchmail at all? It's an MTA utility (a bit like an artificial > > limb, actually), not an MUA utility and Evo doesn't need it... > > > One of my key goals for email management (and I don't think I'm in the > minority here) is to separate which app is doing what. I don't want to > depend on having an X display with evolution running in order to check my > email. I often ssh in and check my mbox's with mutt. I'd say this justifies > having fetchmail and whichever sendmail variant I use. Absolutely. You can run fetchmail in daemon mode, and Evo will use your local SMTP server. AFAICT the only thing you're actually missing is the ability to run a configurable command (i.e. fetchmail) when you click Evo's Send/Receive button. That would be cute, I agree. > > smtp deals transparently with *every* rfc-compliant MTA. > And if my ISP's MTA isn't rcf-compliant (M$ Exchange)? What then? Then they're probably guilty of false advertising. > I totally agree with you, *nix needs to be more user friendly, and those > who 'know better'/'know how' can use the particular 'MTA Utility'. My > primary point is that these functions have already been coded by someone > else at some point, and I just don't see the logic in having developers > spend their valuable time re-inventing the wheel just to make it look a > bit better. I don't see the logic in it either -- but they seem to want to do it. Who are we to stop them? All I care about is that they don't inflict braindamage on sane users. Stuff like the gratuitous 'Trash' and 'Junk' folders is an example of where the strangeness has leaked and can't be disabled for those who don't want it. I don't see why you have a problem with sending/receiving mail though. That is fairly much crap-free in Evo 1.4, and even in 1.5 once bug #53109 is fixed. > I think it'd be great if I could configure > procmail/spamassassin from a nice looking settings gui like the one > evolution has. Not sure about procmail, but it would be cute to set up sieve scripts in a pretty GUI. I probably wouldn't bother to use it myself, but it's the kind of feature which I wouldn't actually think is crack-inspired :) -- dwmw2 _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
