ksmurchison
commented
1 month ago As John Klensin has stated, further specification of Received headers is out of scope for the base documents. I'd suggest that you propose some text here that specifies the conventions used by deployed software. This would be a good starting point for discussion by the WG and we can hopefully reach consensus on text to add to the A/S.
The Received header has a standard format, and it needs to be documented. Failure to do so is to ignore one of the needs of the SMTP Email community.
Apparently the group (and past documents) have been afraid to document the Received header format because a gatewayed mail system may pass content with the same header and different content. This is an error on multiple levels. If we must be constrained by the possibility of non-compliant content introduced by a foreign environment, then we cannot have any structured fields, because any header is at equal risk of inconsistent foreign content. The purpose of these documents is to define the content needs of SMTP participants. By failing to do so, it is a disservice to the SMTP community and simultaneously a disservice to foreign system gateways, since it fails to define how foreign gateways can ensure that a gatewayed message is SMTP-compatible.
A second objection is evident in language that talks about the Received headers being used for forensic purposes, as if the message is only intended to be human readable. Again, this has multiple mistakes. Firstly, the human reader needs useful content, and these documents do not even define what that content should be. A Received header could provide a weather report or a news update and still be consistent with the minimal definitions provided in these documents. In fact, Received header interpretation is a difficult but important part of spam filtering, and is useful both in real-time as a message is being evaluated, and in retrospect. Current Received headers ARE machine-readable, with difficulty, and the goal of these document rewrites should be to promote practices that increase machine readability.
A third objection is that any new language, by definition, will mean that some implementations are not compliant, and evaluators will need to decide how to handle that incompatibility. This is spurious, as evaluators must deal with imperfect compliance all the time. I can easily find examples in the wild of missing semicolons before the Received time stamp and missing spaces after the protocol name. It would be foolish for an evaluator to reject a message simply because of a difficulty parsing one Received header, and it is also unlikely. The possibility of innocent non-compliance is not a reason to avoid documenting what compliance looks like.
A final objection is that Received headers are easily spoofed, and therefore of no real importance. This is also a mistaken objection because trust is not symmetrical. When a message element provides evidence which increases distrust, the evidence does not generally require verifiability, and spammers have no incentive to provide that evidence. On the other hand, if a message element provides evidence which increases trust and becomes justification for lowered defenses, that evidence needs to be from a trusted source. The present situation is that Received headers are consistently trustworthy because evaluators do not use them recklessly as a basis for whitelisting, so attackers have little hope that fraudulent message chains will increase deliverability.
In short, none of the objections hold water. Received headers currently have a highly standardized format which needs to be documented, for the benefit of both SMTP participants and foreign gateways.