| Summary: | merge multiply given header fields when only a single one is allowed | ||
|---|---|---|---|
| Product: | [Unmaintained] kmail | Reporter: | Jork Loeser <jork.loeser> |
| Component: | mime | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | wishlist | ||
| Priority: | NOR | ||
| Version: | 1.3.2 | ||
| Target Milestone: | --- | ||
| Platform: | Debian testing | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Jork Loeser
2002-01-09 19:30:53 UTC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 09 January 2002 20:30 jork.loeser@inf.tu-dresden.de wrote: > Package: kmail > Version: 1.3.2 (using KDE 2.2.2 ) > Severity: normal > Installed from: Debian Package 4:2.2.2-8 (2.2) > Compiler: gcc version 2.95.2 20000220 (Debian GNU/Linux) > OS: Linux (i686) release 2.2.19 > OS/Compiler notes: > > Answering with Reply-All to a mail containing > multiple To:-Fields only lists the addresses > of the first To:-Field in the To:-Field of > the created message. According to the new RFC 2822 (from April 2001) which defines the syntax=20 of messages only one To: field is allowed. RFC 822 (the predecessor of=20 RFC 2822) doesn't say anything about multiple To: fields. But it says: This specification permits multiple occurrences of most fields. Except as noted their interpretation is not specified here and their use is discouraged. So obviously the program which generated the two To: fields is broken=20 and must be fixed. Regards Ingo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8PL5DGnR+RTDgudgRAiP1AJ961eBE4Mv1+/FT+MALYu61CEGSLACgwlQE vPTzsCvr17u6mMWm0QwDvgQ=3D =3DnNPb -----END PGP SIGNATURE----- Don't you think this wish can be closed? The mailer the original mail was generated with was IE. One might stick to the RFCs and ignore reality, or one might pragmatically cover occuring, though unspecified, cases. Given the widespread use of IE, I was tending to the latter. If the behavior of IE changed in between, close the case. Point is that BlackBerry handhelds do generate mails with multiple To:/Cc: fields. when I receive such mails in kmail, only the first occurence (or the last I can't remember) of those fields are : * used to generate the To / Cc fields in the message view * used in a "reply to all" This is really annoying, and has already let me do some silly things because I didn't saw that a mail was in fact sent to more people than just myself. I understand that this behaviour is not RFC-compatible, but since those devices (blackberries) cannot easily change their mailer (euphemism) ... kmail should be able to undrstand that. another point is that in MMS, the To: and Cc: fields can appear multiple time (it's clearly specified in the spec). I expect most of the MMS <--> email gateways to wrongly generate mails with multiple To:/Cc: fields, and again, a user has no mean to change the gateway he uses for MMS. And again, for those users, kmail should be tolerant enough to understand multiple To: and Cc:-fields You might want to write a Perl filter script which does the job of merging improperly duplicated headers. Then you could create a filter in KMail and pipe your incoming messages through this script. I actually see no reason to increase the KMail sources with tons of code which only works around errors produced by non-compliant mail programs. I might, but the standard user that don't know what perl is or mean, won't write such a script. Moreover, I'm rather confident such a change won't bloat kmail sources that much ... |