<snip>
I suggest we should introduce a new assertion by the MTA that
id did indeed validate the origin. Put this in a new RFC 822
header or as an extension to some existing header.
This seems to imply that you trust the MTA on the sending server (even if it
publishes SPF & is accredited) but it doesn't mean that you can trust the
message headers that it is giving you.
For example, if the sending MTA had an SMTP AUTH conversation with a prior
MTA/MUA, and it tells you this during am unsecure SMTP connection, how can
you be sure that you are not talking to a spambot that is faking its
authenticated prior connection in an attempt to give more weight to the
message?
I'd worry that without a much deeper web-of-trust (or chain-of-trust), you
can only have a meaningful dialog with the sending MTA because the only piece
of information that you can reliably trust from the connection is the IP
address.
-Gary