TB! with shared message folders on a network drive: has version 2 got any file locking?
Hello, I've sent the same message to TBUDL, but now I think it's worth submitting on the techie list, too. (Hope I'm not _terribly_ wrong in doing that - this is my first day on this list, unlike TBUDL which I used to read long ago. Still, I don't consider myself as a 100% newbie, with 20 years of computer experience, IT translations, etc.:)) I'm now curious to know whether version 2.x has any sort of locking implemented. I've read some discussions on that subject by Thomas Fernandez and others on TBUDL back in March 2003; now I'm trying version 2.02.03CE, and you probably know better than I do whether anything has changed (or if not, then whether anything _is_ going to change) in those terms. Hope somebody would enlighten me on that. -- Maksym Kozub, MK881-UANICmailto: [EMAIL PROTECTED] http://www.silverstones.com/thebat/TBUDLInfo.html
Bug (maybe wrong understanding of RFCs): an encoding selected by the user sometimes silently replaced with 7-bit US-ASCII
I recently submitted this as a bug (https://www.ritlabs.com/bt/bug_view_advanced_page.php?bug_id=0002349); decided to also report on the list though - it would be interesting to hear what other people think. If you choose an 8-bit encoding for your outgoing messages, but the message actually does not contain any symbols with decimal values higher than 127, then TB! would just make it "Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit", when queuing that message in Outbox. Some people think this is the corrrect behaviour, and they refer to RFC2045 et al. Somebody even reported a bug https://www.ritlabs.com/bt/bug_view_advanced_page.php?bug_id=0002343 - "Possibility to leave definition of 8 bit charset in case of message with 7-bit only without resetting to "us-ascii"" I still consider it definitely a logical mistake, and a serious one, since RFCs say octets with decimal values of 127 and up are not allowed in 7-bit data, but no one RFC says 0-127 should never be encoded as 8-bit - characters themselves are not intrinsically "7-bit" or "8-bit". As a result of this behaviour combined with some other MUAs' (e.g. Microsoft-made ones) improper behaviour, there is the following problem reported. Suppose I send a message to my Ukrainian friend in Canada, and he replies in Russian. I know his MUA would try and put in the headers of his reply the same encoding as my message had. To save him time on checking, I would indicate I want _every message of mine_ (even if it's plain English only!) to be "Content-Type: text/plain; charset=koi8-r / Content-Transfer-Encoding: 8bit", _which is perfectly legal in my view, as explained above. I compose my message indicating "KOI8-R" as the charset to be used, but... looking in the Outbox, I see "Content-Type: text/plain; charset=us-ascii / Content-Transfer-Encoding: 7bit" there! Hope you get my point. www.livejournal.com uses UTF-8 for all those webpages, even though I do not use any Chinese or other double-byte characters in my blog there. I consider this to be a good example: characters, be they English, Ukrainian, Chinese, or whatever, are not "7bit", "8bit", "double-byte", etc. They _can_ be _encoded_ in various ways; and other than for those cases where it is just plainly impossible to encode them in a specific way (like it is impossible to encode Russian as 7bit), - standards do not prohibit us from using anything. So, seeing a good, standards-compliant, mail client like TB!, which calls itself "mail servant" :), I would like it to respect my will, _or_ at least to produce a warning when it changes (again, without a valid, standards-based reason!) what I've set as my default charset. Would you agree?.. My apology for this letter being rather long, - at least I hope it is not 100 boring for everybody :). Maksym. -- Maksym Kozub, MK881-UANICmailto: [EMAIL PROTECTED] http://www.silverstones.com/thebat/TBUDLInfo.html
Changing SMTP server "on the fly": is the "%SMTP" macro worth introducing?
Hello, There had been some questions already about using the same SMTP server for different accounts. For some people, however, the situation is the other way round. I would sometimes use different SMTP servers for the same account. Same "From:", same "Reply-to:", same POP3 mailbox - and two different SMTP servers used in different times. One of the reason is the following. The ISP which I use allows sending through their SMTP for those clients only who are connected to their modem pool. (And yes, they are one of the biggest ISPs here, a good one, and not the only one with such policy in place. And yes, I asked them "Could you please just introduce a good system of SMTP authentication, which would authenticate me from anywhere instead of limiting my ability to use it when calling through my mobile". They are reluctant to do this, just like many other ISPs here. And no, setting up my own SMTP server locally is not an option at the moment for reasons beyond my control. Just answering your questions in advance :).) Therefore, when I'm on the trip and connect through my mobile for example, I use my mobile operator's SMTP server (they also act as an ISP for their customers, and allow to use their SMTP to everybody who connects to their access numbers from their mobile phones). To do that, I have to change manually the setting in "Account properties -> Transport -> SMTP server". So, what I would think about is probably some sort of "%SMTP" macro. I would then assign two hotkeys to "%SMTP=smtp.my-regular-isp.com" and "%SMTP=smtp.my-mobile-provider.com", respectively, and invoke one of those when creating a message. I understand there is a workaround, which is rather inconvenient however. That would be to create two accounts (with the respective %ACCOUNT macros) which are exactly the same except for their SMTP settings, - one for my-regular-isp, and the other for my-mobile-provider, - and to filter all mail messages from those two to common folders. It _is_ inconvenient however; suffice it to say it would need duplicating the whole lot of filters set up in my Sorting Office (which I have to change sometimes), and, more generally, simply looks as a dirty hack rather than a good clean solution :). I am interested in whether anybody else thinks of that as a useful feature worth posting as a wish on bugtrack. Regards, Maksym. -- Maksym Kozub, MK881-UANICmailto: [EMAIL PROTECTED] http://www.silverstones.com/thebat/TBUDLInfo.html
Re[2]: Changing SMTP server "on the fly": is the "%SMTP" macro worth introducing?
>> There had been some questions already about using the same SMTP server >> for different accounts. For some people, however, the situation is the >> other way round. I would sometimes use different SMTP servers for the >> same account. Same "From:", same "Reply-to:", same POP3 mailbox - and >> two different SMTP servers used in different times. MAU> I use three accounts for this purpose, one main and two alternatives. MAU> The 3 accounts are the same except the SMTP server. I always write MAU> messages from the main account and, if I need to use an alternative MAU> server, before clicking Send (or Put in Outbox) I right click on the MAU> account name that appears in the status bar at the bottom of the editor MAU> window and select the appropriate alternative accounts (server). This MAU> works fine for me. Yes, that's sort of workaround I described. Do you also _check_ mail from that one account only? (I didn't think of that in the very first place; of course, it would eliminate the need for common folders,.) Still, this is a workaround anyway: you have to have _three accounts_ (with all addresses etc. being exactly the same) _for the only reason of using alternative SMTP servers_. Wouldn't it be more logical and clean if we were able just to change SMTP when sending (or putting to Outbox)? Regards, Maksym -- Maksym Kozub, MK881-UANICmailto: [EMAIL PROTECTED] http://www.silverstones.com/thebat/TBUDLInfo.html
Re[2]: Changing SMTP server "on the fly": is the "%SMTP" macro worth introducing?
Hello, Andrew. 15 апреля 2004 г., 11:50:04 you wrote: >> Wouldn't it be more logical and clean if we were able just to change >> SMTP when sending (or putting to Outbox)? AA> Well, no, not really. By definition, an "account" is really just a AA> particular POP and SMTP server. All the rest, IMHO, is optional. Well, my HO differs a bit from your HO :), in that I think the _main thing_ which defines an account is still POP settings (or IMAP, where relevant). Look, we call it "a POP3 account". What we get from our ISPs, as far as e-mail is concerned, is, first of all, a POP3 mailbox. Well, they provide us with SMTP servers, too, but somehow I don't feel it to be such an "integral part" of an account. _SMTP server is also optional._ (One thing to support it is the fact that you can create a POP3 account _without_ any SMTP server at all - e.g. to receive some mailing lists to a POP3 mailbox created with that single purpose, etc.) Hope you get my point, even though you certainly may disagree with it :). AA> If you want to change the SMTP server, set up another account and AA> select it by right-clicking on the account name in the status bar. AA> I change accounts in TB! all the time and find it very easy to do. AA> Also, as you undoubtedly well know, the account name is a macro AA> (%ACCOUNT). As I said already, I know how to do that (since long ago :) ). I simply found it not very convenient, logical, etc. (See above.) Best regards, Maksym -- Maksym Kozub, MK881-UANICmailto: [EMAIL PROTECTED] http://www.silverstones.com/thebat/TBUDLInfo.html
Re[2]: Changing SMTP server "on the fly": is the "%SMTP" macro worth introducing?
Hello, Andrew. April 15, 2004, 12:45:04 you wrote: AA> Hello Maksym, >> I think the _main thing_ which defines an account is still POP >> settings AA> You're certainly entitled to your HO, but I challenge you to find a AA> single e-mail client that defines an account without a field for the AA> SMTP server (and associated authentication). Firstly, I didn't say there shouldn't be a field. I just said it's optional. Secondly, look at Pegasus Mail for example. I wouldn't say it's any better than TB!; however, it is a not-so-bad mail client, and it works for many people. It has "users" rather than "accounts". When you create a user, it has POP and SMTP settings for that user. Then, there are "IMAP profiles" - without any SMTP settings in them. You can create several "IMAP profiles" for a user. When you start it as say user 1, you have your folder list. When you connect to an IMAP profile, the root folder of your IMAP mailbox is "mounted" in your folder list. I must say I found that sort of organizing things in Pegasus a bit clumsy, but it works, and it _is_ an example of a well-known e-mail client which does not have even the "SMTP settings" field itself at least for IMAP "accounts". AA> For that matter, I challenge you to find a single ISP that AA> provides e-mail client configuration settings without specifying AA> both POP3/IMAP _and_ SMTP server names. I will have a look when I have time (maybe later today - leaving for simultaneus interpreting assignment right now), but I vaguely remember seeing cards for anonymous access, sold here by some ISPs, which either provide you with a POP mailbox and _do not_ allow you to use their SMTP for obvious spamfighting reasons. WHat I know for sure even now is that some ISPs (again, those who provide anonymous card-based access) allow you to use their SMTP (safeguarding themselves against possible spam complaints by identifying you e.g. via your phone number which they call back), but do not provide a POP mailbox. All this shows that an "account = (POP or IMAP) _plus_ SMTP" paradygm is in fact not so obvious and without any variations. (What is an "account", anyway? Of course if you _define_ it as "(POP or IMAP) _plus_ SMTP", then it is just what it says, but you hopefully get my point :).) AA> For that matter, I challenge you to find another e-mail client that AA> allows you to change the account used via a macro. IOW, the level of AA> detail to which we have access in templates is (already) excellent I agree, but even excellent things are always subject to improvement. I am an Orthodox Christian and I know everything the man makes cannot be ideal :). Regards, Maksym. -- Maksym Kozub, MK881-UANICmailto: [EMAIL PROTECTED] http://www.silverstones.com/thebat/TBUDLInfo.html
Lost message from this list
I just noticed that I received the "Re: Moving off" message by Dierk on Septwember 4, but _never_ received the original "Moving off" message by Jan Rifkinson. I received it on TBUDL though. For the record, I seem to have received just fine all the other messages from TBTECH immediately before and after that one. Jan seems to have sent the message in question to TBUDL and CCed it to TBBETA, and probably sent a separate copy to TBTECH (which I have never got as I have already said, but I see it in the list archive at http://www.mail-archive.com/[EMAIL PROTECTED]/msg04338.html ). I suspect it might have something to do with my ISP's excessive "spam blocking". (RANT MODE ON. Sigh... They kept blocking all SMTP servers of the _whole_ comcast.net domain for two months _silently_. Not just rejecting mail sessions, but simply blocked them by a firewall. "We were getting tons of spam from there", etc. I found it just by chance, when it turned out that I could not receive a (quite important) message from my colleague who is @comcast.net... Sent a message to ukr.nodes, where most Ukrainian ISPs' admins did not see that as a problem. I almost start crying from time to time: "Let me read my 'spam', please!" RANT MODE OFF) However, before I start checking with them, somebody may give another idea of what happened. Any advice appreciated. Regards, Maksym -- Maksym Kozub(+380 44)424-1792(tel./fax), (+380 67)466-5174(mob.) Translations/Interpreting/Editing (English, Polish - Ukrainian, Russian) MK881-UANIC http://kozub.in.ua [EMAIL PROTECTED] http://www.silverstones.com/thebat/TBUDLInfo.html
Re[2]: Lost message from this list
Peter wrote: MK>> Jan seems to have sent the message in question to TBUDL and CCed it to MK>> TBBETA, and probably sent a separate copy to TBTECH PO> Probably using the BCC field. The TO and CC fields are the same as on PO> the TBUDL and TBBETA list. Maybe, but still unclear why you recieved it, while I and Miguel have not. MK>> I suspect it might have something to do with my ISP's excessive MK>> "spam blocking". (RANT MODE ON. Sigh... They kept blocking all SMTP MK>> servers .. RANT MODE OFF) PO> There are discussions that ISPs should start automatic filtering / PO> deleting spam msgs in order to, as they call it, protect the internet PO> users from unwanted email. (duh...) They started such things here long ago. Big, well-known ISPs, as well as smaller ones. What they say is usually something like "There are 99% of stupid users who cannot protect themselves against spam, and they appreciate what we do. You are an unhappy 1%, and for $30 you pay for dial-up access, nobody will tune up the filters individually. That's OK for mass-scale service", etc. -- Maksym Kozub(+380 44)424-1792(tel./fax), (+380 67)466-5174(mob.) Translations/Interpreting/Editing (English, Polish - Ukrainian, Russian) MK881-UANIC http://kozub.in.ua [EMAIL PROTECTED] http://www.silverstones.com/thebat/TBUDLInfo.html
