ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
Of course it is impossible to prove a negative.
In that case (Received-SPF) it's also unnecessary, unlike
SID's Resent-* it's not very critical. Of course spammers
try to forge timestamp lines.
Of course they will try the same with a Received-SPF. But
what will they get for it ?
If the receiver is very sure that he never inserted this
header field with its own receiver=FQDN parameter, he has
a good spam indicator.
Otherwise he SHOULD add his result above old results. If
that works, and it's a setup where nothing shuffles header
fields between MX and final delivery, it's fine.
Otherwise don't believe it (and don't submit it to SpamCop,
it would fail in Spamcop's chain test).
A note about this in the "Security Considerations" maybe ?
Bye, Frank