On Thu, 2004-04-29 at 09:06, Olson, Margaret wrote:
<snip>
What happens if you add accreditation to this scenario, and imc.org
has a way to check if pacbell.net validates from address identities?
In other words, is pacbell.net letting it's users type in any from
address they want, or only ones that pacbell believes they have a
right to use? This strikes me as a fairly trivial level of
accreditation that most server operators ought to be able to meet. In
this example I'm assuming that there is 2821 authentication, so you
know that this is a pacbell authorized server.
Access providers would be reluctant to impose such a restriction just as
they are reluctant to block ports, but it could offer advantages to mail
services (domains) that impose such a policy that can be affirmed. This
same domain may also make statements they do not use third-party relay
nor allow forwarding, but that would be harder to enforce as a policy.
It would allow safely rejecting mail with such a domain prior to a
common practice of rewriting envelopes. Once outbound domain checking
is ubiquitous, such statements become meaningful even before something
like SPF is in full effect.
If IMC finds that the origin is not trust worthy, it can either flag
that (a negative flag) so that recipients know that IMC may be
accredited but it is disowning this message, or it IMC can drop the
message. (Negative flags have no spoof value).
I see adding an X- header to allow assessing path conformance to newer
recommendations to facilitate a transition to full reliance.
X-Verification: Domain <> not verified. The use could elect to expose
that information and newer MUA may offer an icon the status bar.
This would (eventually) allow an MUA to display "not trustworthy" if
the edge decides to accept untrustworthy messages. This may be as big
a hurdle as getting the MUA to display the on behalf of, but it does
remove some level of required analysis from the end user.
I'm not sure if this helps or just moves the problem, but I thought I
would throw it out there. It in essence throws the 2822 validation
responsibility onto the shoulders of the originating server's domain,
but in a very explicit way.
Margaret.