(Sorry about the tardy reply)

On Fri, 2004-01-16 at 05:33, Tony Earnshaw wrote: 
> tor, 15.01.2004 kl. 17.18 skrev pkm:
> 
> > I do have one comment regarding the whole mail sending/retrieval
> > strategy. I don't understand why evolution (and many other mail clients)
> > try to take on the role of the MTA. fetchmail and many sendmail clones
> > have been around for quite some time, and work well when configured
> > properly.
> 
> There's no such thing as a Sendmail clone, luckily. There are several
> MTA dropins that use a surrogate sendmail binary; I use Exim 4 and
> Postfix 2, which can both be called as 'sendmail'. But both are utterly
> different to configure and don't have many of Sendmail's disadvantages.

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 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. It all has to do
with separating the mail reading/writing apps from the mail
getting/sending apps so that I can read/write email remotely.

> 
>  As to any
> "options passed to sendmail", I fear you're getting things mixed up. Evo
> uses smtp as originally defined in rfcs 821 and 822 - and since extended
> and improved with myriads of other rfcs, to most of which Evo adheres
> far better than do many other clients.

Which ones of the 'myriads' is it adhering to, and you're assuming too much
of my ISP.

> Passing options to Sendmail has
> nothing to do with smtp - why should everybody use Sendmail anyway? I
> don't.

You can't tell me that there you never use command line options and actually
have a working *nix box. And I'm not telling everyone to use 'sendmail', it
sounds more like you're telling everyone to use evo.

> smtp deals transparently with *every* rfc-compliant MTA.
And if my ISP's MTA isn't rcf-compliant (M$ Exchange)? What then?

On Fri, 2004-01-16 at 04:14, David Woodhouse wrote: 
> On Fri, 2004-01-16 at 09:43 +0100, Ludek Safar wrote:
> > That's such a true. We're fighting to spread Linux as wide as possible
> > and unfortunately most of potential end users are just scared about
> > these things. I'm not telling it's OK, it's just a fact.
> 
> More to the point, it doesn't _have_ to be a problem. Those of us who
> _are_ aware that an MUA has no business trying to filter or spam-check
> incoming mail don't _have_ to use these 'features'. 
> 
> You can do spam checking and filtering into separate folders at delivery
> time as $DEITY intended, and Evolution will be quite happy with that
> too.

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 think it'd be great if I could configure
procmail/spamassassin from a nice looking settings gui like the one
evolution has.

-Pete =)
_______________________________________________
evolution maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/evolution

Reply via email to