[Top] [All Lists]

Re: FW: I-D Action: draft-kucherawy-received-state-00.txt

2011-11-18 04:35:40

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

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.


Hector Santos
jabber: hector(_at_)jabber(_dot_)isdg(_dot_)net