From kmail-devel Fri Apr 27 12:25:45 2001 From: Don Sanders Date: Fri, 27 Apr 2001 12:25:45 +0000 To: kmail-devel Subject: Re: Bug#24532: integration of kmail with knode X-MARC-Message: https://marc.info/?l=kmail-devel&m=98837442402974 On Friday 27 April 2001 03:01, Neil Stevens wrote: > On Wednesday 25 April 2001 07:49 pm, Don Sanders wrote: > > If you (or anyone else) would like to contribute to KMail adding smtp > > auth support to KMail would be a nice way to start. I guess that > > requires changing the KMail configuration dialog to add an smtp > > authentication checkbox, and kmsender.* to implement a third sendProc > > based on the smtp ioslave. Then this sendProc should be used when auth > > smtp is selected. > > You know, I didn't have a chance to do the GUI, but that's exactly what > I did, that you reverted. :-) I reverted the commit not because of problems with the code but because the code was unfinished and it didn't look like anyone had time to finish it. We can't just switch KMail over to using the smtp slave before the smtp slave is trusted. It took many months before we changed from the blocking pop3 system to the pop3 slave. A gui option to provide smtp authentication, and then only using the smtp slave when that option is selected is a nice way to make the transition from smtp.cpp to using the smtp slave. On Thursday 26 April 2001 19:07, Aaron J. Seigo wrote: > i think Neil already did this.. > > is this the best way though? why keep kmail's own smtp methods when > kio_smtp exists? why require kmail to even know about special features such > as smtp auth if the ioslave can just pull these options out of kcmemail and > have it occur whenever its used to send email (which is actually how it > works w/kio_smtp as i understand it). it seems that hacking in support for > smtp auth to kmail itself seems contrary to the ioslave concept and that > kmail ought to simply use the ioslave and the slave should know what it > needs to do (e.g. send w/authentication) based on settings the user > provides in kcmemail. When the smtp slave proves it stuff then we can drop the smtp.cpp code completely. Indeed it appears that smtp.cpp has problems with dns lookup sometimes so there are definitely benefits to dropping it. One final point I don't think kcmemail should be relevant to the issue of using the smtp slave. I hope the smtp slave doesn't rely on kcmemail, and I think the kcmemail issue, should be dealt with separately from the smpt slave issue. If the smtp slave needs information to perform the authentication then that information should be passed as arguments to the slave. BFN, Don. BTW this new select text in the reader window that you want to reply to feature is very cool! _______________________________________________ Kmail Developers mailing list Kmail@master.kde.org http://master.kde.org/mailman/listinfo/kmail