On Sunday, October 24, 2004 at 2:09:21 PM [GMT -0500], Army Redleg wrote: AM>> However, the technically oriented members here tend to be sensitive AM>> about TB! being accused of buggy behaviour when it simply fails to AM>> cater to non-standard behaviour by servers.
> Understood, *if* these servers are indeed in violation of the > "Standard"... Yes. This is the question for which I don't have an answer. Unless we know the answer, we cannot really make a strong claim either way. > Which now begs the question, after searching through various FAQs, > standards and proposals (IETF, ANS.1, ISO, etc)- I simply ended up with > a headache- swimming eyes and reeling mind... <g> I know how you feel. I've tried looking up technical information like that and rarely come up feeling enlightened. I usually feel exhausted and frustrated. > If you know where I can find this standard (will/must versus > may/should), please point me in the general direction. I can't. :) This is why I didn't want to put a foot in too deep. > Although I feel TB! is the best client on the planet- and certainly > the most flexible and powerful in configuration, I fail to see why it > refuses to allow the user to make the choice in this circumstance. > *If* these servers are in direct violation of published standards then > I will humbly agree with everything folks say about killing my > 'feature wish' and start begging the US Army/military and Cotse to get > their act together and get in compliance with a referenced published > standards and requirements... Ok. > (but I will always hold out on TB! giving the User the power of choice > in any email matter;) Yes. I can agree with that, especially provided that standards compliance remains from the client side. > perhaps I just want TB! to sell me the gun and ammo- allow me to pull > the trigger when I want to. Yes. Security software generally does this. The good ones will provide you with all means of disabling various components and loosening security measures to fit your situation. However, GnuPG has some inflexible quirks as well. For example, you can't encrypt to a key that you haven't assigned some degree of trust to. I squawk at such a restriction personally and usually get purist responses. I do understand where you're coming from. :) This is one of the reasons why I prefer using PGP which enforces no such restriction. > I would probably not bother this good group again if I could start > arguing with those server admins on how they are breaching standards. > But would argue your point here where you say it is not in the 'spirit > of good security'. I meant it only in so far as the current standards being formulated from a position on security and what makes good security. One's position or the position of a panel of experts must come from a common spirit. Standards do change as borne by this spirit. Or it may offer flexibility as well. > If the standard does say will or must, then it is back to simply a > feature wish by a lazy user who desires security and privacy afforded > by this protocol with servers he/she trusts to transport his/her mail > to and from the server. Okay. > Let me worry about what is the definition of 'strict authentication of > the certificate'. Even if issued by Thawte, Comodo, US Army, etc. > there is nothing telling *me* that *I* must trust these issued certs > anyways- it will always be my decision. I just want TB! to allow me > to make that decision on a permanent basis, if/when I feel my own > standards have been met. I lean towards agreeing with this. The software really should just warn you and that's it. You then have the power to go ahead despite the warning. If it allows you one check, then it should allow checking all the time. :) -- -= Allie =- ..... Oxymoron: Science Fiction. __________________________________________________ IMAP [ Client: The Bat!™ v3.0.1.33 | Server: MDaemon Pro ] OS: Windows XP Pro (Service Pack 2) ________________________________________________________ Current beta is 3.0.2.1 Beta/1 | 'Using TBBETA' information: http://www.silverstones.com/thebat/TBUDLInfo.html IMPORTANT: To register as a Beta tester, use this link first - http://www.ritlabs.com/en/partners/testers/
