Hi there!
On 4 Feb 00, at 12:58, Nick Andriash wrote
about "Re: Show <from> during download":
> > Confirmed, I had not tried this feature for a while, so I just tested
> > it, it seems once the header is downloaded that the message is gone
> > from the server. I personally don't mind this, I will not download any
> > large messages no matter who they are from, sending large files by
> > mail is very inefficient and I prefer an ftp link.
>
> But this should be a bug and a serious one... it's certainly not a
> feature! TB seems to be imposing your preferences on everyone. You should
> be able to download the header, and any number of lines you want with the
> header (to get an idea of what the large message is about)... BUT... you
> should also have the option of then either downloading or deleting the
> message from the Server.
Nick, this bug (yeah, this *is* a very serious bug) has been there for a long
time, and RIT labs programmers are certainly aware of what's happening
when one uses this feature. It's been pointed out as a bug on numerous
occasions, and the formal bug reports have been sent to RIT... Just wait till
they fix it, but meanwhile _do_not_ use the "do not download messages larger
then" in conjunction with the option "delete messages from the server" if you
don't like to loose some of the messages addressed to you. I understand that
this is not a workaround, but at least this will save your mail which is likely to
just perish otherwise;-(
> I've set my download options so that only the headers and a few lines of
> text in the large messages are downloaded, but I never thought that doing
> so also deleted the original message from the Server. It's interesting to
> note RITLabs logic on this:
>
<snip>
>
> I don't agree with that logic... not at all.
The logic is all right, it's the code that is buggy;-)
> Please RITLabs... correct this bug and turn it into a feature by allowing
> a little flexibility insofar as leaving what happens to the message, up to
> me. The message was addressed to me, not you, so don't _you_ decide what
> happens to it.
Actually, no other option is needed: if one *really* wants to wipe the messages
overblowing the limits off the server w/out even downloading them, one might
just use the killfilters IMHO. The message size is there in the headers...
Therefore the feature "don't d/load messages larger then" is just plain broken
and needs to be fixed, or _at_least_ explained in _full_details_ in the docu,
since it's really dangerous and the cation cannot be undone.
--
SY, Alex
(St.Petersburg, Russia)
http://mph.phys.spbu.ru/~akiselev
---
Thought for the day:
In every organization there will always be one person who
knows what is going on. This person must be fired.
---
PGP public keys on keyservers:
0xA2194BF9 (RSA); 0x214135A2 (DH/DSS)
fingerprints:
F222 4AEF EC9F 5FA6 7515 910A 2429 9CB1 (RSA)
A677 81C9 48CF 16D1 B589 9D33 E7D5 675F 2141 35A2 (DH/DSS)
---
--
--------------------------------------------------------------
View the TBUDL archive at http://tbudl.thebat.dutaint.com
To send a message to the list moderation team double click here:
<mailto:[EMAIL PROTECTED]>
To Unsubscribe from TBUDL, double click here and send the message:
<mailto:[EMAIL PROTECTED]>
--------------------------------------------------------------
You are subscribed as : archive@jab.org
