-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ***^\ ."_)~~ ~( __ _"o Was another beautiful day, Tue, 26 Oct 2004, @ @ at 18:19:22 +0200, when Roelof Otten wrote:
MM>> Netscape Messenger is an example having such feature, and it is quite MM>> simple, normal, and standard one. > Actually, telling me that some other client has the same feature won't > mean that it is something TB should do too. Although I didn't mention NM in that sense, you should perhaps re-think about added notepad (in a *mailer*!), then "scheduler"... to mention just the two. (: > TB doesn't rewrap a message before sending either even though there > some clients that do so. NM is mentioned just as an example, and strictly related to the topic, to illustrate that it's nothing that special, nor a de-luxe feature. > When I save a message, that's the one that gets sent and the > message that gets sent is the message that is stored in 'Sent mail' > (or whatever folder you're filtering it too), that's a feature of TB > and a major one too. That is simply a mess. The message you have *saved* is NOT the message you have *sent*. It's only that TB is not able to distinct these two. And it cannot do that because of lack of information (the lack of the feature which will record the time of *sending*). So, you in your Sent folder actually have a message you have sent, but you have no a slight idea *when* you have sent it. You know only when this message is last time *saved* on your machine. So, you are not able to administrate your correspondence correctly. The elementary thing. Much, much, much more elementary than a notepad built-in in a mailer. MM>> It is a moment when your message lives your computer/MUA. > Let's use the moment the message leaves the mua (with all those > proxies scanning for viruses and I don't what else it's rather hard to > say when it leaves your computer). And leaving should be defined as > the time that the smtp server has acknowledged receipt, not the > beginning of the transfer. Scanners, proxies, midgets and gadgets... What about *servers* then the message has to undergo and survive? Please focus. It is very simple: you write a message and you have sent it. "Sent", in the simple meaning "it is gone", "the message has left the mailer", "the message is/has(been) sent". What will your message experience passing through the cruel world is not anymore your concern - you have *sent* it, and you have the record when you did it. Where is the problem with this definition? But, because such reasoning which try to complicate very simple things, one have to use external helpers, as Xray eg., because an elementary feature is not present in the mailer itself. (-: MM>> What duplicated messages? When the message is sent, the "stamp" is MM>> written in headers, and the copy with the identical headers is MM>> delivered to your sent folder as well, so that you have evidence MM>> where it is sent, without complicating things by sending to MM>> yourself the copies. > Not sure whether I follow you completely. Do you want two copies of > the message, one as it was sent and one with a time stamp? The very same as now is the noble case, with the only difference that the message will have sending time in headers. (: This one which is sent, has the sending time stamp, and its copy is in Sent folder. (: It's nothing new in the mailers' world. MM>> *If* adding such a simple feature to TB would be "a departure from MM>> current way of thought behind TB", then it is simply badly considered MM>> way. There is nothing more normal and logical than putting a stamp on a MM>> letter's cover. The date of creating is in the letter itself, and date MM>> of sending is on its cover. > Yeah, but what you're suggesting isn't quite the same. Of course is not same - this is just a *comparison*, for making things easier for understanding. (-: > You send a message and keep a copy and now you're talking about adding > a date to that copy in a way that it's indistinguishably what has been > added to your copy and what was their originally. No, it is definitely silly. I do not talk about something like that. > When you want a date stamp on the envelope, ask for an additional > column, that would be saved in the .tbi file. I can imagine that I'd > support such a wish. The envelope and the letter were just comparison to "created time" and "sent time". Like this: envelope - sent time letter - created time TB lacks sent time. So, you could send a message using a pigeon (or a condor) as well, since pigeons (nor condors) do not stamp envelopes, and the result, for administration, is identical: You have no idea when the message is sent. MM>> "Way of thought" should be in accordance with factual processes of MM>> mailing. Well, if we are dealing with mailing. > The way of thought behind TB is that a received or sent message should > not be altered without altering the message-id. Message is not altered at all. MID belongs to headers, message content belongs to the message body. And MID is not altered when it passes through numbered servers and contraptions, when the bunch of headers are added, stripped, altered. A header line which records sending time will change nothing in this procedure, except that it will give a *useful* and *missing* (elementary) information. > You don't have to agree with that, but that's the way TB is written > and it is in full accordance with the relevant RFC's that say that no > two different messages should carry the same message-id. Alas... What TWO different messages? RFC also says that even a MID is not *needed* at all. Shell we use then a healthy and simple reason, or we shall try to find reasons why something is not done well? (-: Disagreeing or not, I do not see here as an issue. It is just very strange to me that adding of such an elementary and obviously missing feature might be followed by such an irrational resistance. But, the full moon is very near, and even in a sign which is not prone to think a lot, so the situation perhaps is not *that* strange. (-: I guess when the moon enter Taurus, will be much more consistency and much less of pure confusion. - -- Mica PGP key uploaded at: <http://pgp.mit.edu/> once just before breakfast <>o<> [Earth LOG: 55 day(s) since v3.0 unleashing] OS: Windows 98 SE Micro Lite Professional IVa Enterprise Millennium with nestled ZipSlack(tm) 9.1 UMSDOS Linux; and, for TB sometimes Libranet (Linux) 2.8.1, via Cross Over Office -----BEGIN PGP SIGNATURE----- iD8DBQFBfo139q62QPd3XuIRAiQXAKCZyggENgnUcfWfvrdQ8plHg98FUQCgkZWv BpFjc/k0ZS0d91NIoa//Gf0= =SSZw -----END PGP SIGNATURE----- ________________________________________________ Current version is 3.0.1.33 | 'Using TBUDL' information: http://www.silverstones.com/thebat/TBUDLInfo.html
