In <F976D4E7-99D3-11D8-93EE-000A95BC6A7E(_at_)margaretolson(_dot_)com> Margaret
Olson <margaret(_at_)margaretolson(_dot_)com> writes:
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.
Correct.
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.
Yes.
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?
Yes, with SPF only, the From: line could be anything, including
Harry's email address. The validated envelope-from would show up in
the Return-Path: header, but few, if any, MUAs show it.
With Caller-ID, the forger would simply have had to add a Resent-From:
header and then the From: could have been anything. The Resent-From:
header is about as visible in most MUAs as the Return-Path: header is.
S/MIME may have helped some, but see the following two InfoWorld web
pages:
http://weblog.infoworld.com/udell/2004/03/23.html
http://weblog.infoworld.com/udell/2004/03/19.html#a948
What needs to happen is something very similar to how I determined
that email was almost certainly a forgery. I said:
Yeah, right. When was the last time Harry Katz posted from a pacbell
DSL connection?
That is, I compared RFC2821 information (IP address, envelope-from)
with previous examples of the hkatz(_at_)exchange(_dot_)microsoft(_dot_)com in
the
From: header.
In this particular case, the envelope-from matched the From: header,
but that is because LMAP (RFC2821) records were neither published nor
checked. Had something like SPF checking been available, imc.org
could have checked to see if the unverifiable domain name was on an
RHSBL. If the envelope-from that the forger used wasn't on any
RHSBLs, imc.org could have checked if the envelope-from matched the
envelope-from that Harry normally used. A mismatch would have
singled a problem.
Oh, as as a final comment: I originally CC:'ed in Paul Hoffman of
imc.org and the co-chairs for this WG to make sure they were aware of
the abuse. I'm not sure that Paul Hoffman, in particular, is
interested in any the details of MARID and probably should not have
been CC:'ed in any of the replies.
-wayne