Quote:
Originally posted by macquigg
... folks who can read email headers, but are not necessarily email experts.
|
I think no one ever devised a better characterization of us here!
I really don't have an opinion one way or the other, and the RFCs probably allow you to add headers in any order as long as they are prepended and one of them is the correct "Received header. However, I have a slight tendency to agree with the opinion of the "experts", and it seems to me to agree with the "chronological order".
When one sees a "Received" header, one assumes that everything below that is exactly what has been received from the sender listed in the "Received" header. In your example the topmost line below the "Received" header (the "X-Authent" header) was not part of the received message, but instead it has been prepended to the received message. So logically what I see here is that you:
1. make a test, and record the result (in a form that you can prepend to the email message)
2. you receive the message, and record the details is a standard way ("Received header")
3. you prepend the info from 1,
4. you prepend the info from 2.
Your logic says that 3 should happen before 4 because perhaps you are actually doing the prepending internally by appending the message received at stage 2 to the line created in stage 1, so it happens before you have the "Received header". My logic is that the way you are expected to do it is as part of stage 2 you finish it by immediately prepending the "Received" header, and only then you have finished the process of receipt and can apply other processes such as adding info about the authentication that justified the receipt. The fact that internally you append the message to the header and not prepend the header should not matter. The end result shouild be as if there was a complete message received and only then headers prepended. Another point of view: if you internally "prepend headers" by first puting them and then appending the received message (perhaps line by line as it is being received) then following this logic the first step in receiving an email message is putting a "Received" header recording the details of the transaction, and then appending the rest of the message. If you work this way then you have the header from stage 1, then the "Received" header from stage 2, and then the received message (unless the delivery fails and then everything including the two intial headers are dumped). Doing it this way probably means that the time stamp signifies the start of the "data" stage and not the completion of this stage of the SMTP session.
To sum it up, I think the "experts" point of view is based on the reasonable assumption that the string that is the message received by the DATA command is a single object, the result of the DATA command is a single object that is the previous object "wrapped" by adding a single "Received" header, and then this object is "wrapped" by adding addtional headers providing optional info, and this becomes the object that is the message reseived by the next server in the chain.