Murray S. Kucherawy wrote:
I agree with Bill McQuillan's remarks. If the server knows at the time
it receives the message that there is going to be a delay then it can
include the new clause in its usual Received: header. Otherwise it'll
have to add a new header. Would it be OK to edit the previously-added
header?
I think RFC5321 says clearly that you're not supposed to do that ever.
Adding another one is more appropriate.
I feel like chop liver here.
Of course, you can edit it. It depends on when the message become, oh
whats a good word, "live" again for the next process, or outside the
network when you can't touch it again.
Read my initial response. Its a chicken and egg redesign issue - A.K.A
Code Change.
Half the problem with many proposals is that they are based on one's
idea of how code is written with their own software. Not always the case.
Again, depending on your ware or the mode of the mail processor, the
initial Received may be added immediately. This memo is written more
like its geared towards a non-SMTP receiver mail processors, where it
would be a 2nd header.
For a SMTP receiver MTA that may be doing rejection at the transport
level, I personally have trouble adding a second Received field for
the same process. So to me, for our own implementation consideration,
it would require a delay of the initial Received added by the receiver
MTA for the purposes of appending the proposed state clause.
What I am saying is this:
Making this a proposed standard carries weight for developers mindful
of being uptopar standards to consider it. The conflict is what I
described in my original response.
I personally think a different header is ideal and its make it easier
for all implementations. Like Received-SPF, this could be
Received-State or Received-Status, and I also think it might carry the
same ID clause from the last or top Received line. That will allow
for existing tracking where the receiver SMTP MTA could be recording
the ID for tracking. When the initial ID is already strong for
auditing and tracking in operations, the alternative approach would be
to delay the initial Received field to add the state clause to it.
--
Sincerely
Hector Santos
http://www.santronics.com
jabber: hector(_at_)jabber(_dot_)isdg(_dot_)net