Version: (using KDE Devel) Installed from: Compiled sources OS: Linux I noticed that both Outlook express and kmail 1.5.9 send mail where the cc look like these (I don't know if it illegal or correct): .... cc: bla@foo.net cc: foo@bla.net cc: "For developer's discussion about KOffice" <koffice-devel@mail.kde.org> Subject: Re: [Uml-devel] Re: karbon/umbrello .... When receiving such mail kmail only displays one CC line. I beleive this is due to mimelib only returns the body for the first cc header it finds. The real problem for me isn't that I don't see the complete CC line, but that the filters doesn't work correctly since sometimes the mailing list is at the end of the cc list (like the example above) and thus not filtered == very annoying :=) When we search for a header we return the body once the header is found. What if we continue searching for more duplicate headers and append their body to the first one we found... Or would that screw things up elsewhere?
Subject: Re: New: mimelib can't parse several "cc:" lines in a message Multiple To: and Cc: headers violate RFC 2822 (Internet Message Format). Does KMail really create multiple Cc: headers? On Thursday 05 June 2003 13:08, Per Winkvist wrote: > When we search for a header we return the body once the header is > found. What if we continue searching for more duplicate headers and > append their body to the first one we found... Or would that screw > things up elsewhere? I don't think that this would break anything. Regards, Ingo
Subject: Re: mimelib can't parse several "cc:" lines in a message > Multiple To: and Cc: headers violate RFC 2822 (Internet Message Format). > Does KMail really create multiple Cc: headers? ------------------------------------------------------------ User-Agent: KMail/1.5.1 References: <157240-2200353718482709@M2W093.mail2web.com> <200305120939.22680.asutton@cs.kent.edu> <200305130242.40592.lparrab@gmx.net> In-Reply-To: <200305130242.40592.lparrab@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200305131018.34480.asutton@cs.kent.edu> X-Spam-Status: No, hits=-25.4 required=5.5 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_KMAIL version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) cc: "For developer's discussion about KOffice" <koffice-devel@mail.kde.org> cc: uml-devel@lists.sourceforge.net Subject: Re: [Uml-devel] Re: karbon/umbrello ------------------------------------------------------------ And here too (though it would be less surprisingly if this wasn't following the standard ;=) ) ------------------------------------------------------------------------ X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2014.211 X-Spam-Status: No, hits=-1.0 required=5.5 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) cc: lparrab@gmx.net cc: kudling@kde.org cc: rwlbuis@xs4all.nl cc: "For developer's discussion about KOffice" <koffice-devel@mail.kde.org> Subject: Re: [Uml-devel] Re: karbon/umbrello ------------------------------------------------------------------------ > > When we search for a header we return the body once the header is > > found. What if we continue searching for more duplicate headers and > > append their body to the first one we found... Or would that screw > > things up elsewhere? Should we just add a comma between the appended bodies? Hmm... What would happen to "Received" field if we modify mimelib accordinly? Perhaps it would be better to just extend the fields::Cc function to traverse the linked list and append additional cc fields so we'll be on the safe side? (I don't have the code here atm so maby it was the Headers::Cc function)
Just to be sure, does this happen at all when koffice-devel@mail.kde.org is not envolved? Try generating the same problem without sending into any mailing lists. We have to find the culprit here and I actually think it might be the Mailing List Manager.
I just came across #53321. Apparently it happens that cc headers are split. Even if the mailing list manager is to blame, in this particular case, shouldn't kmail be able to cope?
Subject: Re: mimelib can't parse several "cc:" lines in a message Like Thiago already wrote it's most like the mailing list software that breaks the CC header in multiple headers. KMail definitely doesn't do this (it always uses DwHeaders::AddOrReplaceField and never DwHeaders::AddField). The change has to be made in DwHeaders::Cc (resp. in a new function which would also be used by DwHeader::To).
*** Bug 53321 has been marked as a duplicate of this bug. ***
*** Bug 63381 has been marked as a duplicate of this bug. ***
I want to have this bug fixed. Raising priority for now :)
*** Bug 63447 has been marked as a duplicate of this bug. ***
*** Bug 62395 has been marked as a duplicate of this bug. ***
Created attachment 2970 [details] patch
Fixed without Coolo's evil hack.