Why does RT alter the mail header ordering? If we get spam sent to
RT I’d like to build a Scrip to report the spam, but it appears that
RT is so misordering the mail headers that this becomes impossible.
They aren’t alphabetical… or really anything I can find. They
appear to be completely random.
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source
and other randomness
Why does RT alter the mail header ordering? If we get spam sent to
RT I’d like to build a Scrip to report the spam, but it appears that
RT is so misordering the mail headers that this becomes impossible.They aren’t alphabetical… or really anything I can find. They
appear to be completely random.
Last time this came up, I found the reference in RFC822 or 2822 that
said that headers weren’t technically an ordered list.
RT doesn’t intentionally massage the header order, but either MIME::Tools or
RT, stores them as a hash at some point…
Last time this came up, I found the reference in RFC822 or 2822 that
said that headers weren’t technically an ordered list.
Yes, but in practice everyone has shifted away from this. Received
header ordering is absolutely necessary for proper spam reporting.
RT doesn’t intentionally massage the header order, but either
MIME::Tools or
RT, stores them as a hash at some point…
I’ll dig into this.
Is there any place that RT stores the original, unaltered message?
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source
and other randomness
Is there any place that RT stores the original, unaltered message?
Not by default, no. The first thing RT does when it gets its mitts on a
mesage is split it into seperate MIME bodies and normalize them to UTF-8.
Were I going to start from scratch today, I’d make a different decision.
Following up on my own post:
RFC 2822, 3.6:
…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.
So, if we’re reordering the received lines, it’s a bug I’d like to see fixed.
Assuming they don’t otherwise compromise the system (which is really, always the case),
patches would most certainly be welcome.
Best,
Jesse
Jesse, I now have some time to dig into the code and/or docs. Have
you already tackled this, or would a patch be welcome?On Jan 27, 2009, at 12:39 PM, Jesse Vincent wrote:
Following up on my own post:
RFC 2822, 3.6:
…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.So, if we’re reordering the received lines, it’s a bug I’d like to
see fixed.
Assuming they don’t otherwise compromise the system (which is
really, always the case),
patches would most certainly be welcome.Best,
Jesse
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source
and other randomness
Jesse, I now have some time to dig into the code and/or docs. Have you
already tackled this, or would a patch be welcome?
I’d love the patch.
-jesse