Re: The Bat! choosing authentication method
Hi CEEJOE, First let me please you to _NOT_ CC me when replying to a mail of mine on this list. I am, as everybody else who writes to this list, subscribed here and do get all the mail via this list. I don't need a private carbon copy. Second I want to ask why you do change the subject in such a strange manner? Neither the square brackets are useful to keep an overview, nor does any arbitrary time appended to the subject make any sence to me. Is there a special reason why we should have an eye on this time? On Thu, 2 Jan 2003 04:08:06 + CEEJOE <[EMAIL PROTECTED]> wrote: > A lot of theory. That's the basics of e-mail working in practice. > However, TheBat cant handle secure IMAP4/secure > POP3 connections flawlessly It can handle SSL-secured POP3 and SMTP connections. With some SSL versions on server side there still are problems, but in general The Bat! can handle SSL for SMTP and POP3. The only thing it still ain't capable to do is: IMAP-over-SSL. > That's what counts to me. AFAIR this thread wasn't about "what counts to you", neither was my response. My mail was about "what authentication and security mechanism are present in The Bat! and how are they chosen to be used". If you don't like The Bat! not fully supporting some functions you'd need that's a different story. _I_ just wanted to clear the confusion about CRAM-MD5 vs. SSL. > In fact, I am not sure whether they will ever waste their time again > on this matter. If even _you_ call this "waste of time" they surely will not. If IMAP and IMAP-over-SSL are implemented and working (according to what Beta-testers and daily use brings to daylight) they wouldn't "waste" time, IMHO ... > TB is still the best mailer I have ever seen. It is (IMO) a > result of brilliant programmers - but hey, > we need this secure thing to fly flawlessly: just "click here to > exchange certificates" and all is done "automatically". There's a big difference between "SSL working flawless" and "automatition of certificate exchange". The former statement is correct: it _has_ to work flawless, _absolutely_ flawless. Into this category belongs the fixing of "unable to connect" errors that are coused by a specific SSL-version on server side (which works with every other MUA). The latter postulation can open a big security hole if not handled carefully. These "Click here once and everything is done automatically" buttons are always possible intruders of security issues. I don't even know how to "exchange certificates" could be done, but the whole certificate problem has a two step solution: Step one requires RITLabs to provide a generic interface for an institution / system administrator to add a "Trusted Root CA" to the appropriate AB automatically. Either by being able to put the "Trusted Root CA" AB on a server for a central administrator being able to modify it (and _only_ the admin being able to do so) and import an own Root-certificate into this AB; or by providing an automatic "post installation import" of a "Trusted Root Certificate" into this AB. This could, just for being sure, expanded to "Trusted Intermediate CA" AB. No user would have problems anymore connecting to a server using a certificate signed by this Root certficate or any derived intermediate certificate. Step two would be to introduce a new dialog box: ,-[ ] | "Accept this self signed certificate?" | | Fingerprint: XXX | Please compare the fingerprint with information the servers | administrator provided to the used certificate to make sure this is | the correct server | | [ ] Always accept (import to "Trusted Root CA") | `- Which pops up if a connection is established and the used certificate is a self singed not yet in "Trusted Root CA" AB. could reveal more details about the certificate for the user being able to compare this with information provided e.g. on a web site, to make sure there's no "man in the middle" attack. All this are semi-automatic solutions, but from a "Security POV" this should be preferred over one of these "Click here once to do it all without you even knowing _what_ is done" buttons. But all this stuff wasn't topic of this thread and therefore should be discussed in a different one. Even better it should be discussed on TBTECH or TBBETA, it's nothing that's yet implemented and therefore these basic discussion of possible solutions is not a problem of "The Bat! Users" but a "How to improve future use?" problem. > [Original message, 31/12/2002, 21:39] > > Peter Palmreuther <[EMAIL PROTECTED]> wrote: > > PP> 1.) The Bat! uses the authentication method it is configured > PP> to us ... Three quesions still left: 1.) Why did you quote this paragraph of my mail? I can't see the correlation to your response. 2.) Why did you quote if _below_ your response? If you refer to it in your post it's more wise to quote it at top, if you don't refer to it it should be left out to avoid confusion
RE:[The Bat! choosing authentication method (was: emptysubject)][02/01/2003-3:55 GMT]
A lot of theory. However, TheBat cant handle secure IMAP4/secure POP3 connections flawlessly (as Outlook and Netscape do). That's what counts to me. I still have to use another mailer (which I really dislike) to handle my university account from home and within campus (because TB wont handle this IMAP thing until v 2.). I have read all of the IMAP related archives. Nothing works and this issue is very important both for our functionality in mailing+security matters *and* the success of TheBat (everyone is going IMAP+secure). This is one story: I recommended TB to the top 2 system guys to find out it couldnt connect to the IMAP4 server ... it was a shame. And they left the program aside like a potato chips bag when it is empty. In fact, I am not sure whether they will ever waste their time again on this matter. TB is still the best mailer I have ever seen. It is (IMO) a result of brilliant programmers - but hey, we need this secure thing to fly flawlessly: just "click here to exchange certificates" and all is done "automatically". This thing of going to IE, exporting/importing certificates, etc. cannt be handled by 90% of the academic users. And nobody has an army of system guys to go around "n" users desks to configure this. That's why Netscape and Outlook are selected for this matters (while they are much worse mailers). Cheers, [EMAIL PROTECTED] [Ø©Eªnº - þªT®iª - NØsT®ª] Las Palmas, Canary Islands [02/01/2003, 3:55 GMT] Using The Bat! v1.62 Christmas Edition on Windows 2000 5.0 Build 2195 Service Pack 3 [Original message, 31/12/2002, 21:39] Peter Palmreuther <[EMAIL PROTECTED]> wrote: PP> 1.) The Bat! uses the authentication method it is configured PP> to us ... Current version is 1.62 | "Using TBUDL" information: http://www.silverstones.com/thebat/TBUDLInfo.html
Re: The Bat! choosing authentication method (was: empty subject)
Hello Peter, On Tue, 31 Dec 2002, at 22:39:28 GMT +0100 (12/31/2002, 3:39 PM -0500 GMT here), you wrote in <[EMAIL PROTECTED]">mid:[EMAIL PROTECTED]>: PP> Hope this sorts the whole stuff out a little bit Good explanation, thanks! PP> "Happy new year" to all list members and all they know :-) Happy new year to you as well. -- Best regards, Greg Strong TB! v1.62 Beta/17 on Windows XP Service Pack 1 PGP public keys: mailto:[EMAIL PROTECTED]?subject=0xB1FE63FA&Body=Please20send20keys Current version is 1.62 | "Using TBUDL" information: http://www.silverstones.com/thebat/TBUDLInfo.html
The Bat! choosing authentication method (was: empty subject)
Hello CEEJOE,
On Tuesday, December 31, 2002 at 5:14:29 PM you [C] wrote (at least in
part):
C> As you see, you dont get clear answers. That's so because this
C> issue is __very_fishy_ (or shall I say "batty" ?) in
C> TheBat.
It ain't. And your mail additionally mixed up some things :-(
1.) The Bat! uses the authentication method it is configured to use.
2.) Exception was: it on SMTP-level "CRAM-MD5" was activated, but
_NOT_ enforced ("Require secure (MD5) authentication"
deacktivated) _AND_ the SMTP-server sent "AUTH CRAM-MD5" in it's
EHLO-greeting The Bat! tried to use CRAM-MD5 a second time even if
it failed in the first instance. It didn't fall back to "normal"
authentication. But as I wrote: only on SMTP-level.
This should be fixed, IIRC. I think I remember having read
something about this being fixed in a Beta-announcement.
3.) For POP retrieval The Bat! uses _exactly_ the configured
authentication method. As one can see: in cofiguration dialog
they're all _exclusive_, so if one checks "Regular" The Bat! does
not try to use CRAM-MD5. This is simple because POP3-servers don't
have a greeting that allows to figure out which authentication
methods are supported and The Bat! does not "wild guessing and
probing". It's up to the user to decide what should be taken, a
POP account could be locked on server side with to many "failed
logins" and a probing of The Bat! could trigger this error.
4.) SSL has _NOTHING_ to do with The Bat! set to a dedicated
authentication method.
(SSL) and (CRAM-MD5/APOP/Regular/Plain) are two different pairs of
shoes. SSL secures the _connection itself_ by encryption. This
encryption is applied to _ALL_ data exchanged in this session,
from a possible login until the "QUIT" command. The different
authentication methods only describe the way the authentication
data are sent: Regular/Plain authentication sends username and
password in plain text, while APOP and CRAM-MD5 encrypt the
password (plus username for CRAM-MD5) and _ONLY_ the password
(plus username for CRAM-MD5). The rest of communication, means:
mail retrieval or mail sendout, is done unencrypted.
5.) Yes, The Bat! is _not yet_ capable of using a SSL-secured
IMAP-connection, albeit configuration dialog pretends something
similar. If IMAP is selected and STARTTLS or TLS the latter is
simply ignored and the connection is done as if "Regular" for
"Connection" would have been chosen.
Hope this sorts the whole stuff out a little bit and a "Happy new
year" to all list members and all they know :-)
CYa next year :-)
Pit
--
Regards
Peter Palmreuther
(The Bat! v1.62 Beta/17 on Windows 2000 5.0 Build 2195 Service Pack 1)
"There is no statute of limitations on stupidity."
Current version is 1.62 | "Using TBUDL" information:
http://www.silverstones.com/thebat/TBUDLInfo.html
