KMail 3.2.2 (Mandrake) - partial messages (was: kmail probelms)

Alexander Nordström alexander.nordstromNOSPAM at tpg.com.au
Thu Jun 24 05:44:12 BST 2004


On Thursday, 24 Jun 2004 04:53, Zé wrote:
> This is how receive many emails in kmail, as blank emails, is only possible
> to see some when is clicked to see the code of the message.
> These same email is well displayed well in Evolution.

Displayed correctly or downloaded correctly? It is important to make this 
distinction. Does an e-mail downloaded with Evolution display correctly in 
KMail? Conversely, and less likely, does an e-mail downloaded with KMail 
display correctly in Evolution?

> Like many people know, i have sended emails to this mailing list to alert
> how kmail treats many emails, that haves  a problematic bug.

Really? That's interesting -- I read this list regularly and I have *not* seen 
other posts about the problem you are describing. Let's assume for a moment 
that you did not just make these other users up: how are their configurations 
similar or different to yours?

> So far no one was worried in resolving this bug, but i know there is
> someone out there like me that worry like me.

Bullshit. As someone who has tried to help you pin down this issue, I strongly 
take offence to that statement.

You have failed to read http://www.catb.org/~esr/faqs/smart-questions.html

It would seem you enjoy pushing your luck, but please, for your own sake, do 
read it. Highlights include:

"Never assume you are entitled to an answer. You are not; you aren't, after 
all, paying for the service."

"A good convention for subject headers, used by many tech support 
organizations, is 'object - deviation'. The 'object' part specifies what 
thing or group of things is having a problem, and the 'deviation' part 
describes the deviation from expected behavior."

"- Describe the symptoms of your problem or bug carefully and clearly.
- Describe the environment in which it occurs (machine, OS, application, 
whatever). Provide your vendor's distribution and release level (e.g.: 
'Fedora Core 1', 'Slackware 9.1', etc.).
- Describe the research you did to try and understand the problem before you 
asked the question.
- Describe the diagnostic steps you took to try and pin down the problem 
yourself before you asked the question.
- Describe any recent changes in your computer or software configuration that 
might be relevant."

"Don't claim that you have found a bug

When you are having problems with a piece of software, don't claim you have 
found a bug unless you are very, very sure of your ground. Hint: unless you 
can provide a source-code patch that fixes the problem, or a regression test 
against a previous version that demonstrates incorrect behavior, you are 
probably not sure enough.

Remember, there are a lot of other users that are not experiencing your 
problem. Otherwise you would have learned about it while reading the 
documentation and searching the Web (you did do that before complaining, 
didn't you?). This means that very probably it is you who are doing something 
wrong, not the software.

The people who wrote the software work very hard to make it work as well as 
possible. If you claim you have found a bug, you'll be implying that they did 
something wrong, and you will almost always offend them -- even when you are 
correct. It's especially undiplomatic to yell 'bug' in the Subject line.

When asking your question, it is best to write as though you assume you are 
doing something wrong, even if you are privately pretty sure you have found 
an actual bug. If there really is a bug, you will hear about it in the 
answer. Play it so the maintainers will want to apologize to you if the bug 
is real, rather than so that you will owe them an apology if you have messed 
up."

"Describe the problem's symptoms, not your guesses"

"Courtesy never hurts, and sometimes helps"

In addition to that, *halt, cease, and desist* creating new threads for every 
followup. It is not helpful when trying to follow the issue. Your new habit 
of posting to multiple mailing lists with the same question is a big step in 
the *wrong* direction.

With respect to the problem, the following is *still* outstanding:

On Wednesday, 9 Jun 2004 20:35, Denis Vlasenko wrote:
> tcpdump -nli<ethN> -s0 -Xx port 110 will reveal full POP3 session.
> Post it here, gzipped if it is large.

On Friday, 11 Jun 2004 18:02, Robin Rosenberg wrote:
> Although I usally use ethereal to sniff, or in some cases dump the traffic
> with tcpdump -i eth0 -w dumpfilename -s0 and later view the traffic in
> ethereal. Then the pop session can be viewed in clear text by right
> clicking on a pop session packet and selecting "Follow tcp stream".
>
> Another is to just telnet the server on port 110 and enter the commands
> necessary.
> telnet mailserver 110
> user <username>
> pass <password>
> list
> retr <number>

On Sunday, 13 Jun 2004 03:14, Denis Vlasenko wrote:
> We need a dump which actually does show how mail download
> takes place.

So post a (gzipped if appropriate) dump *downloading a message that shows up 
broken in KMail*.

If you take the above advice, someone *might* be able to help you further. If 
so, be very, very grateful and consider yourself very, very lucky, but don't 
count on it.

-- 
Alex Nordstrom
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.




More information about the kde mailing list