RE:TB's EXE changed every time?
Hello Dierk, Tuesday, October 19, 2004, 7:00:58 PM, you wrote: On Tuesday, October 19, 2004 at 10:00:40 AM you wrote: And then contact F-Secure support. Done. I am currently investigating this further. BTW, waking Windows from hibernation (the Shift+leftmost button) abd starting the program also does not give me a warning. This thread is already a little bit old, but today I got the same thing, upon starting TB! I got the message from Panda that TB! has been changed and if I want to allow connection to internet. Haven't had that in the few days before, since I installed Panda (maybe 2 weeks ago). -- regards, :eu-flag3: :de-bw: :safaribears: Never hit a man with glasses. Use your fist! Using The Bat! v3.0.2.1, Opera v7.54.3865 on WinXP Home v2600 SP2 * PGP key available on request: send mail with subject 'PGP key request' pgppNVkCVioBn.pgp Description: PGP signature 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/
Re: TB's EXE changed every time?
Hello Jurgen! On Sunday, October 24, 2004 at 8:35:28 AM you wrote: This thread is already a little bit old, but today I got the same thing, upon starting TB! I got the message from Panda that TB! has been changed and if I want to allow connection to internet. Haven't had that in the few days before, since I installed Panda (maybe 2 weeks ago). Points more and more to The Bat! With F-Secure it happens every time I start TB after a complete start of XP, never during a session even after hibernating. After FS told me this behaviour is unknown I wrote them back that it is reproducible. I hope they have a look into since this definitely is way over my head. Still, RL should have a look into the issue, too, as we now have three firewalls doing this: Your Panda, someone reported McAfee 6 and my brand new F-Secure Internet Security 2005. -- Dierk Haasis :Dierk: Copy 'n' Concept The Bat 3.0.2.1 on Windows XP 5.1 2600 Service Pack 2 Chat info for ICQ, AIM, MSN, Yahoo, Jabber upon request Military Intelligence is a contradiction in terms. 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/
AVs and filter problem
Hæ! Today, I stumbled on a filter which normally only was set up as an incoming filter, but which also appeared in the Kill filter section as an Ignore filter. Deleting this one gave me AVs and I had to manually kill TB via Task Manager. After restarting TB, both filters were not present anymore. Anybody else encountered this? -- Kveðja, Thorvald Neumann | http://www.aesir.de/ | The Bat! v3.0.2.1 Professional PopFile v0.22.0 | Windows 2000 SP4 (v5.0.2195) +---+ | Get Firefox - Take back the web! | | http://www.spreadfirefox.com/?q=affiliatesamp;id=22411amp;t=1 | +---+ 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/
Color coding in 3.0.2.1 does not work
Hi, since I've installed the latest beta, the filter based color coding does not work in 3.0.2.1 any more. When I execute filtering manually from the sorting office then it works fine and I see the correct color groups assigned. Can somebody confirm this ? -- Michael The Bat! 3.0.2.1 Professional on Windows 2000 SP 4 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/
Re: rss2mail 1.2 sample plugin is now available.
Dear Stuart, -- Mittwoch, 20. Oktober 2004, 12:24:13: MM for me, TB displays error -ERR Server returned code 404 when is MM IE setting selected. Bizzare isn't it? Our setup here requires no separate authorization to access either the proxy or the firewall; logging in to the network is sufficient. Yes it is. It works fine on my side. Also with IE settings on. But, The first time when RSS is downloading from the server it should actually retrieve 20 post. It only does 10. At this moment I thought it was related to the fact that only 10 post are displayed on the Site itself. I changed the value for displaying post to 30 so as all will be shown on one site. No chance to get all post downloaded. Further: I just posted a test msg on the site and made a fetch mail (F2). But it wont download it so I'm quit curious why. Can someone please give me a tip how to get the rest downloaded? To try out get this feed (its in German only and the English one is coming later): http://www.eddiecastelli.com/duneblog/_xmlsrv/rss2.php?blog=2 Many thanks till later -- best regards | Using The Bat! v3.0.1.33 www.EddieCastelli.com | on Windows 2000 5.0 Eddie | Build 2195 Service Pack 3 on Tour | 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/
Re: Idea: PGP enabling with address book entry
Hello Dierk, On Sat, 23 Oct 2004 at 21:17:54 [GMT +0200] (which was 21:17 where I live) you wrote: DH Hello Zygmunt! DH On Saturday, October 23, 2004 at 8:49:22 PM you wrote: %IF:%ABToMemo=PGP:%NoUseSMIMEUsePGP%SignComplete DH Yes, that is a work-around, would have to add %ENCRYPTCOMPLETE. Two DH drawbacks, the condition has to be a bit more complicated to allow for DH independent signing and encryption. And you couldn't use the Memo DH field for other purposes anymore. Why ?, I still use it for some macro that search for a word at the beginning of the line and return the end of the line or a default value, they all look like those 2 ones: ,- [ GreetMemo ] | %If:'%SETPATTREGEXP=(?is)^Greet (.*?)$%REGEXPMATCH=%ABOFromMemo'='':'%- | Bonjour %ABOFromFirstName,%- | ':'%- | %SETPATTREGEXP=(?is)^Greet (.*?)$%REGEXPMATCH=%ABOFromMemo'%- `- ,- [ QuoteStyleMemo ] | %If:'%SETPATTREGEXP=(?is)^Quote (.*?)$%REGEXPMATCH=%ABOFromMemo'='':'%- | %QInclude=Initiales%- | ':'%- | %SETPATTREGEXP=(?is)^Quote (.*?)$%REGEXPMATCH=%ABOFromMemo'%- `- I think that with a few more work and some delimiters, we can add everything we want in this field ;) -- Regards, Alain :aggy: :flag-france: L'humour est une tentative pour décaper les grands sentiments de leur connerie. - Raymond Queneau The Bat! 2.12.03 Windows 2000 5.0 Build 2195 Service Pack 4 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/
Re: Color coding in 3.0.2.1 does not work
Hi Michael, on Sun, 24 Oct 2004 09:42:49 +0200GMT, you wrote: M since I've installed the latest beta, the filter based color M coding does not work in 3.0.2.1 any more. When I execute filtering M manually from the sorting office then it works fine and I see the M correct color groups assigned. M Can somebody confirm this ? I cannot confirm. My color groups (automatic filters of the inbox, placed before the other filters and set to continue with the other filters) work pretty fine. -- Cheers Peter The Bat! v3.0.2.1 on Win2K, SP4, 5, 0, build 2195, AMD Athlon 2200+ at 1800MHz, 512 MB RAM 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/
Re: Color coding in 3.0.2.1 does not work
Hello Michael, since I've installed the latest beta, the filter based color coding does not work in 3.0.2.1 any more. When I execute filtering manually from the sorting office then it works fine and I see the correct color groups assigned. I confirm this. I can't even assign a color group manually via right click context menu. -- Best regards Jonas Koopmann using The Bat! 3.0.2.1 on Windows XP 5.1 2600 Service Pack 1 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/
Re: Color coding in 3.0.2.1 does not work
Hi Jonas, on Sun, 24 Oct 2004 15:32:50 +0200GMT, you wrote: since I've installed the latest beta, the filter based color coding does not work in 3.0.2.1 any more. When I execute filtering manually from the sorting office then it works fine and I see the correct color groups assigned. J I confirm this. J I can't even assign a color group manually via right click context menu. I can do that too. So it doesn't seem to be OS-related... -- Cheers Peter The Bat! v3.0.2.1 on Win2K, SP4, 5, 0, build 2195, AMD Athlon 2200+ at 1800MHz, 512 MB RAM 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/
Re: TB's EXE changed every time?
Hello Dierk, Sunday, October 24, 2004, 3:01:47 AM, you wrote (at least in part): upon starting TB! I got the message from Panda that TB! has been changed I use DiamondCS Process Guard 3 public beta 2 which detects changes in .exe files but has not detected them with the bat. I also use Jetico Personal Firewall which detects changes as well but same thing has not detected any changes with The Bat! They have detected changes with The Bat! of course when I upgrade though. -- Thanks, Chris Using The Bat! v3.0.2.1 on Windows XP 5.1 Build 2600 Service Pack 1 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/
Re: Color coding in 3.0.2.1 does not work
On Sunday, October 24, 2004 at 8:32:50 AM [GMT -0500], Jonas wrote: I confirm this. I can't even assign a color group manually via right click context menu. This smells of being an issue of setup of the actual colour groups. For each colour group, you have to configure the colour for when the message is read and when it's unread. Quite often, users change the colour only for unread status. They try to apply the colour group to a read message. It's applied. However, there's no change since, for the assigned colour group, the colour for the read message is still configured as the default colour. -- -= Allie =- . One way to better your lot is to do a lot better... __ 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/
Create message filter action broken
Hi TB Beta list members, I am unable to use 3.0.2.1 any longer. Filters that are supposed to create new messages don't. That's a show stopper for me, having many complex management filters in place that require this functionality. https://www.ritlabs.com/bt/view.php?id=3975 I am also suffering the can't close TB bug. -- Cheers -- //.arck D Pearlstone -- List moderator and fellow end user TB! v3.0.1.33 on Windows XP 5.1.2600 Service Pack 2 ' pgpvJ9kMpl1oQ.pgp Description: PGP signature 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/
Re: Create message filter action broken
Hello Marck! On Sunday, October 24, 2004, 9:19 AM, you wrote: MDP I am unable to use 3.0.2.1 any longer. Filters that are supposed MDP to create new messages don't. That's a show stopper for me, MDP having many complex management filters in place that require this MDP functionality. MDP https://www.ritlabs.com/bt/view.php?id=3975 I went there and read your filter. Later today I will try to put something like that in Sorting Office/filters to test whether I can write a confirming note to your report. MDP I am also suffering the can't close TB bug. Thanks very much for the note you added here, Marck! : https://www.ritlabs.com/bt/view.php?id=3944 -- Best regards, Mary The Bat 3.0.2.1 on Windows XP 5.1 2600 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/
Re: Color coding in 3.0.2.1 does not work
Hi Allie Martin, AM This smells of being an issue of setup of the actual colour groups. AM For each colour group, you have to configure the colour for when the AM message is read and when it's unread. Quite often, users change the AM colour only for unread status. They try to apply the colour group to a AM read message. It's applied. However, there's no change since, for the AM assigned colour group, the colour for the read message is still AM configured as the default colour. I checked the assigned color groups with a right click on the message header in the message pane. But it's definitely no color group assigned. Therefore, it seems to be a filter issue. When I roolback to 3.01, the same simple filters work without any problems. And I can reproduce it. It seems that we have a filter bug again. -- Regards Michael The Bat! 3.0.2.1 (Professional Edition) on Windows 2000 SP 4 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/
Re: Color coding in 3.0.2.1 does not work
Hi Jonas, J Hello Michael, since I've installed the latest beta, the filter based color coding does not work in 3.0.2.1 any more. When I execute filtering manually from the sorting office then it works fine and I see the correct color groups assigned. J I confirm this. J I can't even assign a color group manually via right click context menu. Yep, exactely the same here. In the meantime I've recreated some filters but no change. -- Regards Michael The Bat! 3.0.2.1 (Professional Edition) on Windows 2000 SP 4 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/
Re: Create message filter action broken
Hi Marck, on Sun, 24 Oct 2004 15:19:32 +0100GMT, you wrote: MDP I am unable to use 3.0.2.1 any longer. Filters that are supposed to MDP create new messages don't. That's a show stopper for me, having many MDP complex management filters in place that require this functionality. I haven't exactly tried it with a new message, but I have a filter that forwards mails of a certain account to another address with a polite addressing and the original mail attached. It works flawlessly in this version. MDP I am also suffering the can't close TB bug. I had a few of those too. Also some AVs... hmm Still, this version isn't unusable for me... *S* -- Cheers Peter The Bat! v3.0.2.1 on Win2K, SP4, 5, 0, build 2195, AMD Athlon 2200+ at 1800MHz, 512 MB RAM pgpHuNsVinxBc.pgp Description: PGP signature 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/
Re: Create message filter action broken
Hello Marck! On Sunday, October 24, 2004, 9:19 AM, you wrote: MDP I am unable to use 3.0.2.1 any longer. Filters that are supposed to MDP create new messages don't. ... Confirmed. MDP https://www.ritlabs.com/bt/view.php?id=3975 I have added a confirming note to the above BT report. -- Best regards, Mary The Bat 3.0.2.1 on Windows XP 5.1 2600 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/
Re: Color coding in 3.0.2.1 does not work
On Sunday, October 24, 2004 at 9:26:00 AM [GMT -0500], Michael wrote: I checked the assigned color groups with a right click on the message header in the message pane. But it's definitely no color group assigned. Therefore, it seems to be a filter issue. When I roolback to 3.01, the same simple filters work without any problems. And I can reproduce it. It seems that we have a filter bug again. Sorry for the confusion, but I was not not referring to filtering. I was referring to Jonas' comment that he cannot apply a colour group throught the right click context menu. I can't confirm that. Applying colour groups through filtering is another issue. I haven't been using that since I use IMAP and colour group assignments aren't easily maintained since they aren't stored server side. -- -= Allie =- . Graduate Of The Uncle Fester Keith Moon School of hair styling __ 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/
Cannot Close The Bat! confirmations [was Re: Create message filter action broken]
Hello Peter! On Sunday, October 24, 2004, 9:41 AM, you wrote: MDP I am also suffering the can't close TB bug. PM I had a few of those too. Also some AVs... hmm Then please confirm, would you, at: https://www.ritlabs.com/bt/view.php?id=3944 It's my understanding from what Stefan said, that the more confirming notes added to a BT report, the higher priority for fixing it will receive. :) -- Best regards, Mary The Bat 3.0.2.1 on Windows XP 5.1 2600 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/
Re: Color coding in 3.0.2.1 does not work
Hello Jonas everyone else 24-Okt-2004 15:32, you wrote: I can't even assign a color group manually via right click context menu. Works fine here. -- Best regards, Alexander (http://www.neurowerx.de - ICQ 238153981) using v3.0.2.1 on Windows XP Pro Service Pack 2 Progress isn't always for the best. Smoke signals never got an Indian out of bed at 3:AM to answer a wrong number. -- Mack McGinnis 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/
Re[2]: Color coding in 3.0.2.1 does not work
Hello, M since I've installed the latest beta, the filter based color M coding does not work in 3.0.2.1 any more. When I execute filtering M manually from the sorting office then it works fine and I see the M correct color groups assigned. M Can somebody confirm this ? PM I cannot confirm. My color groups (automatic filters of the inbox, PM placed before the other filters and set to continue with the other PM filters) work pretty fine. I can't manually filter on color codes unless the messages are in the Inbox. If the messages are in the Inbox, it works fine. If the messages are in a different folder that I've created, the filter examines all the messages in the folder but doesn't pick up any hits on the color coded messages. I can move a couple messages from my other folder to the inbox and it works, move it back to my other folder and it stops working. This worked in previous versions of TB. I've reported this Mantis but so far it seems to be hung up in can't confirm status. -- James There are 10 types of people in the world. Those who understand binary, and those who don't. -- Unknown 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/
Re: Idea: PGP enabling with address book entry
Hello Dierk, Saturday, October 23, 2004, 6:23:54 PM, you wrote (possibly edited): Most people may only need these options and the Privacy menu, but I can still imagine some more flexibility with the macros for much more experienced users. I support the suggestion too, exactly for the above reason: Give to the users an easy way to encrypt on a per user basis, but at the same time allow more experienced people to do more advanced tasks using macros or other means. -- Best regards, Costas 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/
Re: Idea: PGP enabling with address book entry
Hello Mary! On Saturday, October 23, 2004 at 4:52:57 PM you wrote: If you'll write a wish in BT, I'll put a supporting note. https://www.ritlabs.com/bt/view.php?id=3976 I hope the wish is explained lucidly enough ... -- Dierk Haasis :Dierk: Copy 'n' Concept The Bat 3.0.2.1 on Windows XP 5.1 2600 Service Pack 2 Chat info for ICQ, AIM, MSN, Yahoo, Jabber upon request If you give up drinking, smoking and sex, you don't live longer. It just seems like it. 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/
Bug: Common filters
Hello TBBETA Members! Today I transferred all my filters from my accounts to Common Filters to save me double filters in different accounts. Unfortunately it doesn't work, TB's Sorting Office forgets my check marks under Share with ... upon closing. Not good - show stopper - should be addresses ASAP! -- Dierk Haasis :Dierk: Copy 'n' Concept The Bat 3.0.2.1 on Windows XP 5.1 2600 Service Pack 2 Chat info for ICQ, AIM, MSN, Yahoo, Jabber upon request When things go right, God will be thanked. When things go wrong, he will be thanked that they are not worse. (Richard Dawkins) 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/
Re: Bug: Common filters
Hello Dierk! On Sunday, October 24, 2004 at 6:10:01 PM you wrote: Not good - show stopper - should be addresses ASAP! And on we go: One filter mysteriously lends its properties (name and contents) to another one. First I thought I inadvertently deleted a filter but upon recreation and renaming I now find that another filter miraculously has the same name and the same criteria. When we are at it, I tried to delete the mysterious double and got an AV, which forced me to kill TB through the Task Manager. Still, it would also be a good idea to have an easier way to check the accounts, at least for nested filters (like inheriting them from the parent, or the possibility to highlight all filters at once and then set common options). -- Dierk Haasis :Dierk: Copy 'n' Concept The Bat 3.0.2.1 on Windows XP 5.1 2600 Service Pack 2 Chat info for ICQ, AIM, MSN, Yahoo, Jabber upon request Every garbage-removal system - whether Zen, skepticism, or existentialism - generates garbage; the best you can hope for is to find a system that removes more garbage than it generates. (John Horgan) 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/
Re: Bug: Common filters
Hello Dierk! On Sunday, October 24, 2004 at 6:23:43 PM you wrote: Still, it would also be a good idea to have an easier way to check the accounts, at least for nested filters (like inheriting them from the parent, or the possibility to highlight all filters at once and then set common options). After first cut 'n' pasting everything from the accounts over to CF and now the other way round, I'd also like to see an easier way to bring filters from one set to the other. But that has been asked before, IIRC. -- Dierk Haasis :Dierk: Copy 'n' Concept The Bat 3.0.2.1 on Windows XP 5.1 2600 Service Pack 2 Chat info for ICQ, AIM, MSN, Yahoo, Jabber upon request Asking dumb questions is easier than correcting dumb mistakes. 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/
PGP enabling BT Wish, Address Book entry [was Re: Idea: PGP enabling with address book entry]
Hello Dierk! On Sunday, October 24, 2004, 10:51 AM, you wrote: MB If you'll write a wish in BT, I'll put a supporting note. DH https://www.ritlabs.com/bt/view.php?id=3976 DH I hope the wish is explained lucidly enough ... Just added my note of support here. I found the explanation in your wish report to be lucid, concise, and fully descriptive of what's needed. -- Best regards, Mary The Bat 3.0.2.1 on Windows XP 5.1 2600 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/
Re: Idea: PGP enabling with address book entry
Hello Costas! On Sunday, October 24, 2004, 10:17 AM, you wrote: Most people may only need these options and the Privacy menu, but I can still imagine some more flexibility with the macros for much more experienced users. CP I support the suggestion too, exactly for the above reason: Give CP to the users an easy way to encrypt on a per user basis, but at CP the same time allow more experienced people to do more advanced CP tasks using macros or other means. So could you please add your supporting note to the wish at: https://www.ritlabs.com/bt/view.php?id=3976 It will be much appreciated. -- Best regards, Mary The Bat 3.0.2.1 on Windows XP 5.1 2600 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/
Re: Color coding in 3.0.2.1 does not work
On Sunday, October 24, 2004, 15:32, Jonas wrote: I can't even assign a color group manually via right click context menu. What if you switch to another folder and then back? This does sound like the known update bug 3.0.2.1 suffers from. -- Regards, Marcus Ohlström Using The Bat! v3.0.1.33 on Windows 2000 5.0 Build 2195 Service Pack 4 PGP Public Key at http://www.canit.se/~marcus/pgp.asc 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/
Re[2]: Feature wish- allow user to permanently permit session with incomplete SSL/TLS server certs
Hello Allie, Saturday, October 23, 2004, 4:36:00 PM, you wrote: AM Not to worry. You'll not be admonished for bringing this up more than AM once. this is good :) 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... 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 If you know where I can find this standard (will/must versus may/should), please point me in the general direction. AM It doesn't really have to do this. It's the server admins who really AM aught to get their act together. However, I'm pragmatic on issues as AM these and understand that in the end, it's the users comfort and not AM standards conformation battles that do matter at the very end. I do AM realize that conformation to standards and user comfort do go hand AM in hand, so the clients and servers really aught to remain AM compliant. 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... (but I will always hold out on TB! giving the User the power of choice in any email matter;) perhaps I just want TB! to sell me the gun and ammo- allow me to pull the trigger when I want to. AM Providing workarounds is a really sensitive issue. Though it makes the AM user less frustrated in the end, one wonders what it will do to those AM who keep breaching the agreed on standards and getting away with it. AM They'll breach it again, and again, and again. Should this be allowed AM for security standards, especially when the breach is clearly not in the AM spirit of good security? 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'. Spirit, perhaps the intent of the law- vice the letter of the law, is what my feature wish really is (if indeed these servers are in direct violation of the standard). If the standard says may or should- well then there is no real violation rather only a hardline approach to strict protocols that TB! refuses to permit any deviation from. 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. Discussion- Whenever the POP/IMAP/SMTP server fails to provide the root/CA certificate or full chain with the server certificate TB! pops up an Unknown CA certificate warning. AM Shouldn't it? Yes it should. However, I would further desire TB! allowing the user to hash/fingerprint the accepted cert for more than one session, if the user so desires, and not have to manually OK this action each time. In this warning dialog box is a few buttons with OK and CANCEL always selectable, giving temporary/session permission, but View Certificate and Add to Trusted are not selectable unless the server provides a full certificate chain. AM Well, the certificate cannot be viewed without all the information. How AM can it be trusted without the full cert chain? So these are greyed out. Not true. A certificate should always be viewable how else can I even begin to know what TB! is warning me about in the first place? I cannot verify anything- simply know that TB! doesn't like something- not sure what it is, but that I should trust TB! on making the choice for me and allow me to initiate a single connection- again with encryption established with an unverifiable certificate. Does that really make any sense at all? TB! allows me to start a SSL or TLS session with an unverified certificate? Not being able to view and or add to trusted forces the user to manually OK the session each and every time a connection is made to these servers. On accounts where this is true and automatic checking for new mail is set this dialog box can be hidden behind other windows and even hang the client and/or system if not answered in a timely fashion. AM So you're wishing for a trust anyway button? :) YES!! well, sorta- hitting OK is the trust anyway button. Allowing me to import what I want to import to my trusted certs is the Trust Anyway button I seek! Recommendation- The Unknown CA Certificate
Feature Request: periodical mail checking only when connection is available
Dear all, When I'm Online I very much like to have the Option set to 'periodical check' my Server after a few minutes automatically. When I go off line and work on other places without Internet TB! is continuing checking eMail. THis is not only filling the Log with unnecessary entries but also uses System capacity for nothing. Now you could say 'ok switched it of'. Your right and it's really easy if you only do this with one account. So my suggestion is: - to have the function programmed that when there is no connection TB! is ignoring the 'periodic mail checking'. May I have your view on it? Many thanks. -- best regards| Using The Bat! v3.0.1.33 www.EddieCastelli.com | on Windows 2000 5.0 Eddie | Build 2195 Service Pack 3 on Tour | 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/
Re: Feature Request: periodical mail checking only when connection is available
Hello all, Sunday, October 24, 2004, Eddie Castelli wrote: When I'm Online I very much like to have the Option set to 'periodical check' my Server after a few minutes automatically. When I go off line and work on other places without Internet TB! is continuing checking eMail. THis is not only filling the Log with unnecessary entries but also uses System capacity for nothing. Now you could say 'ok switched it of'. Your right and it's really easy if you only do this with one account. So my suggestion is: - to have the function programmed that when there is no connection TB! is ignoring the 'periodic mail checking'. check option No automatical for periodical checking in Network and Administration dialog. -- Bye Marek Mikus Czech support of The Bat! http://www.thebat.cz Using the best The Bat! 3.0.2.1 under Windows XP 5.1 Build 2600 Service Pack 1 Notebook Acer, Pentium4-M 2.2 GHz, 512 MB RAM, ADSL line 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/
Re: Bug: Common filters
Hello Dierk Haasis everyone else 24-Okt-2004 18:10, you wrote: Today I transferred all my filters from my accounts to Common Filters to save me double filters in different accounts. Unfortunately it doesn't work, TB's Sorting Office forgets my check marks under Share with ... upon closing. Odd. I did the same a while ago when using one of the 3.01 betas and it works fine. I did not convert all my filters however. -- Best regards, Alexander (http://www.neurowerx.de - ICQ 238153981) using v3.0.2.1 on 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/
Re: Feature wish- allow user to permanently permit session with incomplete SSL/TLS server certs
Hello hggdh, Saturday, October 23, 2004, 6:16:44 PM, you wrote: h An user should *always* be allowed to View a certificate, mostly h when there is an issue regarding it's validity (like an incomplete h root chain). If this does not happen nowadays, then it is a bug on TB!. h No questions about it. absolutely, if it can not be viewed we will never know the details of what was used to establish the SSL/TLS session and whether it should be trusted in the first place. h One might even go ahead and allow the user to add a certificate with h an incomplete root chain to the base. No big deal here. Which is what I have done, but it makes no matter as each session/connection must be manually approved still. h But, here, we must draw the line. If the user succeeds in finding out h the missing intermediate roots, and adds them to the base, then h everything is OK, and life goes on. Otherwise -- i.e. there are still h missing intermediate roots --, then TB! *HAS* to refuse using the h certificate. If this is not an option for the user, then I humbly h suggest the user to stop using SSL (or other schema in the same line). Here is where you lose me. You say it's ok to add the incomplete cert to the base earlier then here you say TB! has to refuse using the incomplete cert and even user, such as I, should stop using the security/privacy afforded by an encrypted session to transport email to and from the mail server? h When you receive a certificate (on SSL negotiation) you do NOT trust h this certificate. What you trust, want it or not, is that it's h signature can be verified by a known authority -- known to you, and h accepted as such by you. This known authority is represented by the h root certificates you accepted to use. Your trust on the certificate h you received is transitive: you trust it because a know root confirms h it. And *THIS* root is trusted by you not to mess up. As such, if h there are missing intermediate root certificates, then there is no h trust transitivity, and the certificate you received is, by default, h tainted. This is not *always* so. If I was concerned with the entire PKI or hierarchy of it- then yes. If all I want to do is communicate via secure transport with a mail service and can verify the servers cert, as well other factors like the IP of the server, published info about the cert on the website, etc then I can be satisfied. My personal standard has been met in this case- and it may not always *require* having placed my trust completely in the CA or Intermediaries. Why must I trust them anyways? My trust is in the server. The certificate is there to afford me the opportunity to establish the security and privacy provided by an encrypted transport with this trusted server... Nothing can force me to trust the entire chain in a formal PKI and certainly shouldn't be a forced requirement when my trust is established in the server only, in some cases. As you mention below, self signed certs will always be a factor. Simply due to the cost associated with the mainstream CA's, especially with those roots included in OS and browsers. Once my standards heve been met then I should be the decision maker, imnsho, not TB!. h This is not paranoia (although, I have to say, I *am* paranoid). This h is simply the rules of the game. I am interested in where you have read these rules of the game, falling under the broad umbrella of paranoid myself. RFC, FAQ, Internet Draft, Protocol Specification, Standard, other? h Allie, you are absolutely correct when you wonder about the security h of this. There is none. I beg to differ. The user, regardless of what any one entity says, is the *final* approving authority on what is acceptable in regards to what level of security and privacy that user desires. There is no security afforded, whatsoever, when TB! refuses to allow me to even view an incomplete certificate chain. All I am permitted to do is say OK or Cancel... I further feel this is a *very* reasonable request, to the point of being a no-brainer- when it comes to giving the user the decision making authority and allowing the user to satisfy his/her own security and/or privacy standards- rather than have them dictated and forced. h Another option here is that this server is using a self-signed h certificate. If this is the case, all that is needed to do is add the h certificate itself to the trsuted root. 0bviously, there is then the h problem of trust, back to haunt: you *can* trust a self-signed h certificate, as long as you can positively confirm it. Since you h cannot use a trusted root anymore, the only way to confirm it is by h direct contact with the other party. Only after such confirmation h should you add the certificate to the trusted root. Agreed! TB! allows for no user decision here, which falls back on it doesn't matter if it is a self signed job or not... Simply allow the user to decide when their personal trust standards have been met. Thanks for the feedback,
Re: Color coding in 3.0.2.1 does not work
Hello Allie, For each colour group, you have to configure the colour for when the message is read and when it's unread. Quite often, users change the colour only for unread status. They try to apply the colour group to a read message. It's applied. However, there's no change since, for the I checked this, it`s not the case for me. -- Best regards Jonas Koopmann using The Bat! 3.0.2.1 on Windows XP 5.1 2600 Service Pack 1 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/
Re: Color coding in 3.0.2.1 does not work
Hello Allie, Sorry for the confusion, but I was not not referring to filtering. I was referring to Jonas' comment that he cannot apply a colour group throught the right click context menu. I can't confirm that. I re-checked this, sometimes assigning of color groups work, most times it doesn´t. No question of settings -- Best regards Jonas Koopmann using The Bat! 3.0.2.1 on Windows XP 5.1 2600 Service Pack 1 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/
Problem signing messages using GPG 1.2.5
Hello tbbeta, I cannot get the beta to sign messages using GPG Sean -- Sean Rima [EMAIL PROTECTED] ICQ: 679813 YAHOO: thecivvie O2 +353863868343 Vodafone +353872628431 Transvestite: A guy who likes to eat, drink and be Mary! Using TheBat! 3.0.2.1 and BayesIt! 0.7.4 Windows XP (NT 5.1Build 2600 - ) :irl-flag: 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/
Re: Problem signing messages using GPG 1.2.5
Dear Sean, @24-Oct-2004, 22:29 Sean Rima [SR] in mid:[EMAIL PROTECTED] said: SR I cannot get the beta to sign messages using GPG Although I stopped using the beta, I didn't have any such problems myself. You appear to be double-addressing your postings - a folder template? -- Cheers -- //.arck D Pearlstone -- List moderator and fellow end user TB! v3.0.1.33 on Windows XP 5.1.2600 Service Pack 2 ' pgpyfT03Wiq2B.pgp Description: PGP signature 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/
TB won't close with CC hidden
Hallo tbbeta, Recently I started testing an IMAP account next to my pop3 account to the same server. On checking my mail the CC stays active, what isn't surprising, after all the point of IMAP is to stay in contact with the server. As long as I check mail automatically everything is ok, but on checking manually, the CC comes in focus and doesn't leave because of IMAP. That's why I set the CC to hide in stead of automatically (what I was using before) After me doing this TB didn't collect mail after one manual check (not automatically, nor manually) and it didn't close because of active tasks. Behaviour is reproducible both with 3.0.2.1 as with the regular release. Any confirmations? -- Groetjes, Roelof Cats are the proof of a higher purpose to the Universe The Bat! 3.0.2.1 Windows XP 5.1 Build 2600 Service Pack 2 1 pop3 account, server on LAN pgpFjL6IxGvr2.pgp Description: PGP signature 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/
Re: Feature wish- allow user to permanently permit session with incomplete SSL/TLS server certs
Hello Redleg, Sunday, October 24, 2004, 8:09:21 PM, you wrote: AR Hello Allie, Discussion- Whenever the POP/IMAP/SMTP server fails to provide the root/CA certificate or full chain with the server certificate TB! pops up an Unknown CA certificate warning. AM Shouldn't it? AR Yes it should. However, I would further desire TB! allowing the user to AR hash/fingerprint the accepted cert for more than one session, if the AR user so desires, and not have to manually OK this action each time. Indeed! I support this because I can use other methods to establish trust separate to the certificate. What I need TB! to do is tell me that a certificate is identical to the one I trusted yesterday. AR Does that really make any sense at all? TB! allows me to start a SSL or AR TLS session with an unverified certificate? Not being able to view and or add to trusted forces the user to manually OK the session each and every time a connection is made to these servers. On accounts where this is true and automatic checking for new mail is set this dialog box can be hidden behind other windows and even hang the client and/or system if not answered in a timely fashion. AM So you're wishing for a trust anyway button? :) AR YES!! AR well, sorta- hitting OK is the trust anyway button. Allowing me to AR import what I want to import to my trusted certs is the Trust Anyway AR button I seek! Yes exactly! When I contact my brother, I have an encrypted connection that can be used as a conduit to exchange pointers to jointly known silent secrets. Or in an extreme a voice p2p call will verify the contents of an incoming mail so that in future the non-rooted certificate can be trusted for future correspondence. AM Interesting. Seems reasonable, though one wonders about the security of AM it. I guess you're more interested in transmission encryption more than AM strict authentication of the certificates? Quite right. My https: BBS uses a certificate signed only by the provider of my server software. Users are very happy to add my certificate without a CA root because they know they need encryption perhaps against a suspect ISP and having established trust (via a well known trusted server company) they need to know that in future when my IP changes that they are still talking to the same BBS. I understand the issues put forward in these mailinglists for only trusting CA rooted certificates, and challenge that when I use my work company's CA rooted certificate that this same certificate is used by a great number of people. Then contrast to me contacting a friend at home on a fixed IP DSL line with a non-rooted cert, which is more trustworthy in knowing the security of the delivered message ? Lastly can someone please tell me does TB! use certificates during 'chat' sessions ? I'd have thought that most users would not have traditional full certificates. Please support the 'Trust this certificate' change in TB! by keeping controls in place to protect the casual user as in the past and continue to flag immediately any certs not installed as trusted. James 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/
Re: Problem signing messages using GPG 1.2.5
Sean, Sunday, October 24, 2004, 10:29:51 PM, you wrote: Hello tbbeta, I cannot get the beta to sign messages using GPG Sean Just sorted it, now to get it to use a front end as the key manager :) Sean -- Sean Rima [EMAIL PROTECTED] ICQ: 679813 YAHOO: thecivvie O2 +353863868343 Vodafone +353872628431 An error? Impossible! My modem is error correcting. Using TheBat! 3.0.2.1 and BayesIt! 0.7.4 Windows XP (NT 5.1Build 2600 - ) :irl-flag: pgp4GfzX8yP4V.pgp Description: PGP signature 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/
Re: Feature wish- allow user to permanently permit session with incomplete SSL/TLS server certs
On Sunday, October 24, 2004 at 2:09:21 PM [GMT -0500], Army Redleg wrote: Hello Allie, Saturday, October 23, 2004, 4:36:00 PM, you wrote: AM Not to worry. You'll not be admonished for bringing this up more than AM once. this is good :) 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... 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 If you know where I can find this standard (will/must versus may/should), please point me in the general direction. AM It doesn't really have to do this. It's the server admins who really AM aught to get their act together. However, I'm pragmatic on issues as AM these and understand that in the end, it's the users comfort and not AM standards conformation battles that do matter at the very end. I do AM realize that conformation to standards and user comfort do go hand AM in hand, so the clients and servers really aught to remain AM compliant. 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... (but I will always hold out on TB! giving the User the power of choice in any email matter;) perhaps I just want TB! to sell me the gun and ammo- allow me to pull the trigger when I want to. AM Providing workarounds is a really sensitive issue. Though it makes the AM user less frustrated in the end, one wonders what it will do to those AM who keep breaching the agreed on standards and getting away with it. AM They'll breach it again, and again, and again. Should this be allowed AM for security standards, especially when the breach is clearly not in the AM spirit of good security? 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'. Spirit, perhaps the intent of the law- vice the letter of the law, is what my feature wish really is (if indeed these servers are in direct violation of the standard). If the standard says may or should- well then there is no real violation rather only a hardline approach to strict protocols that TB! refuses to permit any deviation from. 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. Discussion- Whenever the POP/IMAP/SMTP server fails to provide the root/CA certificate or full chain with the server certificate TB! pops up an Unknown CA certificate warning. AM Shouldn't it? Yes it should. However, I would further desire TB! allowing the user to hash/fingerprint the accepted cert for more than one session, if the user so desires, and not have to manually OK this action each time. In this warning dialog box is a few buttons with OK and CANCEL always selectable, giving temporary/session permission, but View Certificate and Add to Trusted are not selectable unless the server provides a full certificate chain. AM Well, the certificate cannot be viewed without all the information. How AM can it be trusted without the full cert chain? So these are greyed out. Not true. A certificate should always be viewable how else can I even begin to know what TB! is warning me about in the first place? I cannot verify anything- simply know that TB! doesn't like something- not sure what it is, but that I should trust TB! on making the choice for me and allow me to initiate a single connection- again with encryption established with an unverifiable certificate. Does that really make any sense at all? TB! allows me to start a SSL or TLS session with an unverified certificate? Not being able to view and or add to trusted forces the user to manually OK the session each and every time a connection is made to these servers. On accounts where this is true and automatic checking for new mail is set this dialog box can be hidden behind other windows and even hang the client and/or system if not answered in a timely fashion. AM So you're wishing for a trust anyway button? :) YES!! well, sorta- hitting OK is the trust anyway button. Allowing me to import
Re: Feature wish- allow user to permanently permit session with incomplete SSL/TLS server certs
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/
Re: Feature wish- allow user to permanently permit session with incomplete SSL/TLS server certs
Hello Army RL, Sunday, October 24, 2004, 14:58:59, you wrote: (snip) h But, here, we must draw the line. If the user succeeds in finding out h the missing intermediate roots, and adds them to the base, then h everything is OK, and life goes on. Otherwise -- i.e. there are still h missing intermediate roots --, then TB! *HAS* to refuse using the h certificate. If this is not an option for the user, then I humbly h suggest the user to stop using SSL (or other schema in the same line). AR Here is where you lose me. You say it's ok to add the incomplete cert AR to the base earlier then here you say TB! has to refuse using the AR incomplete cert and even user, such as I, should stop using the AR security/privacy afforded by an encrypted session to transport email to AR and from the mail server? OK. Let me rephrase this. First of all you can add a rootless public certificate in the base. The expectation is that you will, eventually (and before actually using this certificate) add in the missing roots. Secondly, the security/privacy attained by the use of encryption is also dependent on guaranteeing the integrity of the certificate (and, by extension, of the public/private key pair it uses). On a production environment, the risks of using a rootless public certificate are unacceptable. The reason here is you cannot distinghish a 100% real-honest-I-swear-over-whichever-grave-you-want-me-to-use BUT rootless from a counterfeit, identical in the identification data, one. Encryption has many issues, but one of them, a very important one, is: *Key managament distribution* This is the part of using encryption that worries about storing encryption keys, and safely distributing them. An encryption algorithm can be the best out there in the market but, if the key is compromised... it does not really matter if you are using encryption or not! TLS/SSL adresses the key MD by using a public key algorithm. The TLS/SSL certificate is actually composed of two parts -- the private key, which is never distributed, and the public key. The public key is encapsulated in what is, by abuse of language, called the certificate and, more strictly, the public certificate. It's the public certificate that gets send over the wire when a TLS/SSL session is being negotiated. Now, TLS/SSL will negotiate one symmetric encryption key at every start of session (and, probably more during the session), by using the asymmetric keys (the private and public ones) to establish an ephemeral encrypted session. When the symmetric encryption key has been generated, the ephemeral session is ended, and both parties start using the newly-generated symmetric key. THIS is the key that is used to encrypt the session data -- in our case, to download/upload e-mails to the server. If you cannot safely confirm the public certificate, it follows that you cannot trust the resulting generated symmetric keys, and encrypted sessions using them. h When you receive a certificate (on SSL negotiation) you do NOT trust h this certificate. What you trust, want it or not, is that it's h signature can be verified by a known authority -- known to you, and h accepted as such by you. This known authority is represented by the h root certificates you accepted to use. Your trust on the certificate h you received is transitive: you trust it because a know root confirms h it. And *THIS* root is trusted by you not to mess up. As such, if h there are missing intermediate root certificates, then there is no h trust transitivity, and the certificate you received is, by default, h tainted. AR This is not *always* so. If I was concerned with the entire PKI or AR hierarchy of it- then yes. If all I want to do is communicate via secure AR transport with a mail service and can verify the servers cert, as well AR other factors like the IP of the server, published info about the cert AR on the website, etc then I can be satisfied. My personal standard has AR been met in this case- and it may not always *require* having placed my AR trust completely in the CA or Intermediaries. Why must I trust them AR anyways? Please let me give you an example of an issue here. Let's say your mail server is at address 10.10.10.10, and it's fully qualified name is mail.dummyserver.info. This means that you could query DNS on 10.10.10.10, and would get mail.dummyserver.info as a response, or query DNS on mail.dummyserver.info, and get an IP address of 10.10.10.10. So far, so good. Now, in comes a bad guy. This bad guy can: (a) poison the DNS to re-route all your sessions requests to a different server; (b) physically cut the wire and insert his system in between you and your connection, or between your mail server and your connection. In both ways, it is easy to set up things such as the bad guy has a session to your mail server (using the real mailserver certificate), and another session to you, using a fake mailserver certificate (for which, guess what: no root is available...).
Re: Feature wish- allow user to permanently permit session with incomplete SSL/TLS server certs
Hello hggdh, Monday, October 25, 2004, 12:46:31 AM, you wrote: h Secondly, the security/privacy attained by the use of encryption is h also dependent on guaranteeing the integrity of the certificate (and, h by extension, of the public/private key pair it uses). Agreed, however integrity also must include physical security, in this context a CA is irrelevant. A past employer MD had his CA cert in a dummy name on his own locked private directline server in his office, you would need private trust that using the server implied that even his PA had no access. If I send Redleg a post at work dozens of people may have access to the message - via CA cert. Then I send to his home fixed IP, I only need worry about his family or his laxness in preventing them getting to his mail - self cert and fingerprint. In practice I am happy to trust the IP, but encryption gives us privacy. h On a production environment, the risks of using a rootless public h certificate are unacceptable. The reason here is you cannot distinghish h a 100% real-honest-I-swear-over-whichever-grave-you-want-me-to-use BUT h rootless from a counterfeit, identical in the identification data, one. Right, if you rely on the cert alone. Other methods can be used to validate a cert, as per my earlier post - provided that you can safely check fingerprint the cert every use. What I am asking for is notionaly the same as two PGP users each self signing their own key and not each others in a private web of two. h Encryption has many issues, but one of them, a very important one, is: h *Key managament distribution* This is the part of using h encryption that worries about storing encryption keys, and h safely distributing them. This is not an issue when people already know each other. h When you receive a certificate (on SSL negotiation) you do NOT trust h this certificate. What you trust, want it or not, is that it's h signature can be verified by a known authority -- known to you, and h accepted as such by you. I request the option to be the known authority myself and do the external validation myself. AR This is not *always* so. If I was concerned with the entire PKI or AR hierarchy of it- then yes. If all I want to do is communicate via secure AR transport with a mail service and can verify the servers cert, as well AR other factors like the IP of the server, published info about the cert AR on the website, etc then I can be satisfied. My personal standard has AR been met in this case- and it may not always *require* having placed my AR trust completely in the CA or Intermediaries. Why must I trust them AR anyways? OK, this is what I mean also but I've been more verbose! h Also, I fail to understand a site that publishes it's public h certificate, but does not provide pointers to the roots (i.e., to h where you can get the roots, and it better be a completely different h place!). A spammer/bad guy connects to my private server and can get my name/company or other private details from the cert. AR My trust is in the server. The certificate is there to afford me the AR opportunity to establish the security and privacy provided by an AR encrypted transport with this trusted server... h As shown above, you cannot trust your server. And... you cannot h trust a rootless certificate. You can swallow it, but not trust. I disagree, I control my local server and DNS, Redleg controls his local server and DNS. We could happily exchange messages in clear but for privacy would like the option to choose to validate each others certs by external methods. h The whole idea of root certificates on TLS/SSL is to allow you to h *confirm* that a public certificate received has been verified by h someone. For private use, personal private verification works fine. Browsers happily let you import a non-CA cert and allow a user an option to do their own choice of verification first. h The idea here is similar to the web of trust in PGP/GNUPG. You do not h know me, but you know someone that signed my PGP key stating I am who h I say I am. However this arguement assumes that I have not met my brother or friend and do not have another method of validation such as voice p2p. Also another thought, I may want to exchange mails with someone I do not trust - however I'd prefer the option to reduce the chance of someone else listening in at least for most of the journey. AR As you mention below, self signed certs will always be a factor. Simply AR due to the cost associated with the mainstream CA's, especially with AR those roots included in OS and browsers. Once my standards heve been AR met then I should be the decision maker, imnsho, not TB!. h OK. OK. I accept it. The *final* user should have a *final* say on h whether the rootless certificate will be accepted or not. On further h thinking, I consider your approach valid, albeit the result is a h potentially compromised session. h But, the user assumes all risks. Caveat emptor.
