Closed ietf-svn-bot closed 2 years ago
@alexey.melnikov@isode.com commented
Ned Freed wrote:
And this turns out to be harder than I thought, because there's no actual definition of a trace field in either RFC 5321 or RFC 5322. They simply list Return-Path: and Received: as the trace fields and stop.
Going back to RFC 822, we have this definition:
Trace information is used to provide an audit trail of mes-
sage handling. In addition, it indicates a route back to the
sender of the message.
It's a starting point, I guess, but only that.
Now that I've researched this, I think we need to have a better definition of trace field, irrespective of what we end up with in regards to message modification.
For one thing, the definition in RFC 822 calls into question the legitimacy of classifying Authentication-Restuls as a trace field. All of the other fields I'm aware of that warranr this status are either added at a specified point during message processing (final delivery) or contain a timestamp. A-R pesses neither property, instead depending on location alone - which doesn't really fit with the notion of an audit trail, at least not as I understand it.
There's also the issue that neither RFC 8098 nor RFC 3461 say that Original-Recipient is a trace field, but I guess this can be fixed with a registration update, once that's possible.
@alexey.melnikov@isode.com commented
Ned Freed wrote:
There's the even more fundamental issue of the criteria for declaring something a trace field.
@alexey.melnikov@isode.com commented
Dave Crocker wrote:
Does it help to use the word "handling" rather than "trace"?
@alexey.melnikov@isode.com commented
Ned Freed wrote in response to Dave Crocker:
Maybe a little.
The problem is we now have other specifications talking about trace fields. Dealing with that substantially increases the cost of any wording change.
I don't think the benefits measure up to the costs.
@alexey.melnikov@isode.com set owner to resnick@episteme.net
@alexey.melnikov@isode.com set component to email-format
@alexey.melnikov@isode.com commented
It looks like this issue is also affecting rfc5321bis, so the same ticket will be used to address both.
@alexey.melnikov@isode.com commented
Based on IETF 111 discussion:
Proposed ABNF for trace:
trace = [return] *(received/optional-field)
@alexey.melnikov@isode.com commented
Suggested changes to rfc5321bis:
https://mailarchive.ietf.org/arch/msg/emailcore/mjqqTjF6Rlc6suNNaz6nycEsY-Y/
@alexey.melnikov@isode.com commented
draft-ietf-emailcore-rfc5321bis-05 incorporates all necessary changes for SMTP.
dougfoster.emailstandards@gmail.com commented
I suggest that all additions to a message should be added at the top, and above the Received header. This adds clarity about which entries are added at which point in the process. I am frustrated by one particular MTA which adds some entries above the Received header, some entries below the Received header, and some entries at the end of the header section.
draft-ietf-emailcore-rfc5322bis-03 addressed remaining issues related to this ticket.
keyword_rfc5322
owner:resnick@episteme.net
type_enhancement
| by alexey.melnikov@isode.comVarious documents define trace header fields which can be added during SMTP relay and final delivery. RFC 5322 defines ABNF (and list 2 header fields) in Section 3.6.7 ("Trace Fields"). Other RFCs added other trace header fields, e.g. Authentication-Results (RFC 7601) and more esoteric SIO-Label-History (RFC 7444).
Issue migrated from trac:7 at 2022-01-31 12:33:38 +0000