-----BEGIN PGP SIGNED MESSAGE-----
I use the term uneducated below -- I am not referring to anyone on this
list. I am referring to "average Joe".
The spoofed return path and spoofed received header path are very
different problems. I am not trying to state that one is more
important that the other. I believe the problems are different enough
in their nature that using a single approach to solve both problems
will require compromises that would be unnecessary using two different
technologies.
SPF is good and sound with respect to validating the return path. It
is doesn't currently validate the EHLO argument which becomes part of
the Received headers of a message.
On Feb 29, 2004, at 11:32 AM, Alex van den Bogaerdt wrote:
All of these: No problem. But there's another one:
o Some systems use spoofed but otherwise correct HELO information
What if
Received: from longsword.omniti.com (ip-66-80-117-3.nyc.megapath.net
[66.80.117.3])
by portent.listbox.com (Postfix) with ESMTP id 53A16B1DF
for <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>; Sun, 29 Feb 2004 10:59:22
-0500 (EST)
would have read
Received: from aol.com (ip-66-80-117-3.nyc.megapath.net
[66.80.117.3])
by portent.listbox.com (Postfix) with ESMTP id 53A16B1DF
for <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>; Sun, 29 Feb 2004 10:59:22
-0500 (EST)
(If this is important to the reader: Substitute aolr-v4.evip.aol.com
for aol.com in all of my examples).
This is a long outstanding problem. There are often several received
headers of which you only control the topmost (the one you generate).
I don't believe that SPF has the facilities to completely and correctly
solve this problem, it is very different in nature.
So, we are assuming that the reader of the header is uneducated and
doesn't know that the aol.com (and the longsword.omniti.com for that
matter) in the header doesn't _have_ to be an FQDN. There are
sufficiently many legacy sending systems out there that use local
labels in their EHLO args (like production_server) that blocking them
would drop a lot of legitimate business mail. Given that, we could
place aol_com or aol-com or -aol.com as our argument to EHLO and still
have a similar problem as all are likely to confuse the uneducated
reader.
Spoofing occurring anywhere but the return path is a much bigger (and
more complicated) problem. It also only effects uneducated users. I
see a spoofed domain name in the Subject like, From address, Reply-to
header and Received headers to all be the same. If you are educated,
it is a non-issue and if you aren't it required an very different
solution than SPF. Solving the Received header problem is just the tip
of the iceberg because the unfair use of that domain name in other
header that a "regular" user can see is just as much a problem.
I agree that this is spoofing... But I don't see how analysis of the
EHLO argument will completely rectify the issue. It only makes sure
that _you_ won't add that spoofed info into the Received header you
create. However, it isn't _you_ we are worried about, it is the "bad
guy" who sent the email. It is trivial and common for spammers to
place bogus Received headers in an email before it every gets to
your/my/final MX. So, if I was malicious, I could put whatever ehlo
argument or IP address in faked pre-existing received headers.
It just seems to me that the Received headers are fundamentally
insecure as they are mutable by any host (including byzantine hosts)
along the delivery path (most notably the original sending machine).
They can't be trusted. While I agree that EHLO checking during SMTP
can be useful, fixing the topmost Received header is of limited
usefulness as the rest were subject to tampering.
The only way I see around this is to require each host that adds a
received header to sign that received header using (perhaps DNS
published) PKI. Again, this is why I think it should be outside of SPF
as the problem really needs its own investigation to lead to a good,
correct and complete solution.
"Received: from aol.com ...".
Hey aol, you have relayed this message. Fix that!
It isn't necessarily aol.com. ARIN has in-addr.arpa delegation for a
reason. The OrgID owning the IP address there has responsibility.
Again, this is the uneducated vs. educated user problem.
In here, "aol.com" presumably is the sender (sending host). Asking aol
if they think ip-66-80-117-3.nyc.megapath.net is allowed to use aol.com
as an HELO parameter, is IMHO worth considering for SPF.
I think it is an imperfect fix as you can't stipulate the correctness
of _all_ the Received headers. While I am all for things that _mostly
work_ (I am a very practical person), I think that SPF's purpose AS IS
is both well defined and it meets the stated purpose without
compromise. It currently excludes EHLO domain name spoofing from it's
charter. As such, it doesn't try to tackle something it can't
completely solved (not to say another technology couldn't solve it).
If it was included, and solved the problem imperfectly, then it weakens
the overall "correctness" of SPF.
I think SPF as is has a great thing going. I think it is worth
considering how to prevent EHLO domain spoofing with SPF, but I think
it would be unwise to incorporate any solutions that aren't complete
and correct.
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Postal Engine -- http://www.postalengine.com/
// Ecelerity: fastest MTA on Earth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
iQEVAwUBQEJOElwyh8czExtlAQGHNAf+LFcgFct8x3VeZ4z+s/lNMpaFeDqE8gbC
2htrM/1S0rcZDxmnu73b3aXSLsLGBXJq8dfVFk6FBhmzRfOmkEzogeajRdsX9hvh
LTWpUor0AVAdanIu/bGAhBDZ/NXC1i5NdPILcrK1IKLBJAVNLOuL2U7OxNr5tJSG
DL1zysXWT5kdLtTLhRGCinnJ4hlDpIttnG5qtAZHd0X9pb3cNJ7lTJumlzSh4X+a
JwA0Ea+vGDd01vqIgpP7o2coWjSnXWcOYsZjl6ZnLVRksZPg5LxlbS9XyGZ33TDK
+nrZV8LYqS/u/R8m8XVc1JhHUzOH2bhOKSm6k+u5ORDgwK9q//hg8Q==
=0I32
-----END PGP SIGNATURE-----