Received: (from majordom(_at_)localhost)
by above.proper.com (8.12.11/8.12.9/Submit) id i3T21Nvk067821;
Wed, 28 Apr 2004 19:01:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to
owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org using -f
Received: from pacbell.net (adsl-64-168-75-162.dsl.snfc21.pacbell.net
[64.168.75.162])
by above.proper.com (8.12.11/8.12.9) with SMTP id i3T20iKU067750
for <ietf-mxcomp(_at_)imc(_dot_)org>; Wed, 28 Apr 2004 19:01:02 -0700
(PDT)
(envelope-from hkatz(_at_)exchange(_dot_)microsoft(_dot_)com)
<snip>
Too bad exchange.microsoft.com doesn't publish strict C-ID or SPF
information and imc.org doesn't check such stuff. Either one would
have caught this forgery.
Meng correct me if I'm wrong, but I believe that with strict SPF
records published and checked, that the forger would have been forced
to supply a return path that verified.
Adding accreditation to 2821 at least tells you that the domain owner
pays attention to who is doing what on their servers, so this would
presumably have forced the forger to use something unverified or
unaccredited.
But they could still present the from as microsoft.com, and it would
take changing all the MUAs to show and end user that this was
unverified or verified but unaccredited, and an corresponding level or
education to teach people what those two things mean. Is that easier
than preventing 2822 forgeries directly?
Margaret.