ietf-svn-bot
commented
3 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.
aamelnikov
keyword_rfc5322owner:resnick@episteme.nettype_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