ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
it is much too late to change the syntax of Received: fields.
And even if it were applied to Received-SPF fields, it does
nothing to keep the Received-SPF ordered relative to
Received: fields.
Let's assume the header fields in fact are reordered, among
them some Received-SPF.
Now you might be able to sort the timestamp lines by their
timestamps, or more likely by "I know what happens behind
my MX". Or you just use `nslookup -q=mx`.
Then you can match these Received: ... by FQDN ... and the
receiver=FQDN in Received-SPF. Then there are two cases:
1 - you get _one_ match for the FQDN of your MX
1.1 - but this MX doesn't check SPF, so this is bogus
1.2 - and this MX used to check SPF, so this is valid
2 - you get more than one match, this must be wrong
Actually "two" is possible for separate HELO and MAIL FROM
results, but let's ignore these SPF details for the moment.
Of course there's an issue for an MX changing its strategy,
e.g. depeding on the route and white lists. The value of
this header field depends very much on local considerations.
SpamCop invented a "mailhost configuration system" last year,
because its general solution was not more good enough for
_all_ odd cases (it's still good enough for _most_ cases).
Now what's the conclusion of what you said so far ? Kick
this header field ? Add some "security considerations" ?
Just keep it as it is, because spammers trying to abuse it
will probably shoot into their own foot ? Maybe move it
to an "informative appendix" with a corresponding caveat ?
Bye, Frank