[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    The SMTP slave and KMail (Re: RFC: TLS default enabled/disabled?)
From:       Michael =?iso-8859-1?q?H=E4ckel?= <Michael () Haeckel ! Net>
Date:       2001-05-20 19:11:01
[Download RAW message or body]

On Sunday, 20. May 2001 02:14, Alex Zepeda wrote:
>
> So it's cleaner to force one global default?  And make each app override
> that speifically?
>
> Or is it cleaner to specify this all on the URL (I'm thinking no)?
>
> What I've setup seems logical to me for a slave that will likely use a
> different configuration for different hosts.
>
> Similarly the slave config thing works wonders for options that would be
> set a certain way for all instances of a slave (like certificate
> handling).

Ok, I try to explain in a different way, why can't KMail use kio_smtp.

The main problem is simply, that kio_smtp is currently a very poor design. It 
currently forces every application that wants to use it to store its 
information about POP and IMAP in a well defined way. Unfortunately this way 
is completely insufficiant for the advanced user.

Therefore the audience of kio_smtp is very limited and kio_smtp is far from 
being able to fit the needs of an advanced mail client for power users like 
KMail.

Looking more closely on the problem it can be found out, that nearly 
everything is alredy in place, only a little thing is still missing.

The slave already supports urls like
smtp://user:pass@host:port/send?to=kde-core-devel@kde.org

Unfortunately the envelope sender address is always takes from these limiting 
profiles and therefore every application that wants to use kio_smtp has to 
use these profiles which indeed appears to be a very nice marketing trick.

With a little change, the slave could be extended to support a url like
smtp://user:pass@host:port/send?from=michael@haeckel.net&to=kde-core-devel@kde.org

Therefore the whole issue definitely seems to be of political nature and not 
of a technical one. Everything can be solved by the attached patch.

Regards,
Michael Häckel

[prev in list] [next in list] [prev in thread] [next in thread]