http://bugzilla.spamassassin.org/show_bug.cgi?id=3409
------- Additional Comments From [EMAIL PROTECTED] 2005-01-24 07:30 ------- Subject: Re: need to modify header rewriting for DomainKeys compatibility On Mon, Jan 24, 2005 at 04:14:08AM -0800, [EMAIL PROTECTED] wrote: > * As everybody noted till now, it won't fix anything as there's just too > much > software out there which appends headers -- actually every piece of mail > software, including formail and every MUA I know. Just because everyone does it ... > * It feels wrong. Traditionally new headers were always appended to the > existing ones and only the routing information was prepended. That's basically what RFC 2822 says: It is important to note that the header fields are not guaranteed to be in a particular order. They may appear in any order, and they have been known to be reordered occasionally when transported over the Internet. However, for the purposes of this standard, header fields SHOULD NOT be reordered when a message is transported or transformed. More importantly, the trace header fields and resent header fields MUST NOT be reordered, and SHOULD be kept in blocks prepended to the message. See sections 3.6.6 and 3.6.7 for more information. Where the trace headers are the Resent-*, Received, etc, ones. So it's not clear if "reorder" means transposition and/or shifting, but my view tends to be: append to the whole header section, or append to the trace header section, and that's it. > All not very technical reasons which boil down to: Why should we change it > and "play nice" if it won't change anything on the big picture anyway? DK > still faces the old problem, they can't force anybody to change the whole > mail > transfer software out there, so this problem has to be solved in the DK draft > and working around the problem on our side won't change anything. I'm not arguing for or against DK here, since I actually don't know much about it, but my response is: if you never support something because you think it might fail, then it is much more likely to fail. If DK looks like the right way to go, then we should support it. If it doesn't look like the right way to go, then we should probably wait and see what happens before supporting it. We had the same issue with SPF. I would also say that our DK code would do something like: append unless DK is used, then prepend the DK header. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
