-----BEGIN PGP SIGNED MESSAGE-----
On Feb 29, 2004, at 7:59 AM, Hector Santos wrote:
How am I failing to "grasp" this? Can you show how this real world
spoof
is protected by SPF?
Client IP: 206.66.146.23
EHLO santronics.com
MAIL FROM: <root(_at_)remedyus(_dot_)reston(_dot_)tnsi(_dot_)com>
First, remedyus.reston.tnsi.com doesn't appear to have an MX or A
record. That can safely be rejected in compliance with RFC 2821
section 3.6.
If it were to have an A record or an MX record or you were to ignore
that it doesn't you are left with this:
The SPF record says that @remedyus.reston.tnsi.com can send from
206.66.146.23 or it can't. (in this case an non-existance record which
now means ?all and after the adoption would be -all). So, the problem
wouldn't exist after complete adoption unless the spammer added an SPF
record, so let's assume that he did that.
The "Received headers" and the "Return-Path" are part of the RFC
described "trace headers" and are distinctly different from one
another.
Now, you have validated the return path and santronics.com is no where
in it. There is _no_ spoof of the return path.
The Received headers do indeed contain your domain. If you think this
is being spoofed, then you are 100% correct. However, preventing that
with a EHLO check won't help. The sender can simply prepend a
fictitious Received header that "claims" your domain in the return path
before sending it. The EHLO argument as presented in the Received
headers is _never_ safe as it can be mutilated by any byzantine node on
the delivery path. But if you are worried about people spoofing your
domain in headers, I'd be much more worried about people putting
something like "santronics.com [disparaging/embarrassing remark]" in
the subject line. The masses will see and act on that much faster and
more vigorously than your domain name included in the "comments" of one
of the received headers.
There are also a handful of (non-ratware) MTAs out there that use the
domain part of the RCPT TO as the argument to EHLO. This isn't correct
with respect to the RFC, but you will block legitimate mail if sessions
are refused on this basis.
The above example doesn't illustrate the "loophole" as well as a
null-envelope sender. SPF would never act differently on the above
transaction based on the EHLO argument. Which is a good thing as that
can trivially be changed by the spammer. Without changing, sender,
recipient, or sending IP he can "fix" the problem by just specifying
the FQDN... So checking that it is bad doesn't really give us any
protection.
// 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)
iQEVAwUBQEIUHlwyh8czExtlAQEItAf+O7I8sy/i2oJpd/qBym1RTvVL04n4/bIZ
vM/n4Q8itErcCDwrB4qLEHmAHRewG2vyLMqM/P4cVL0ga9/M9lt4l9m2uv0iCuvg
iQ0sMKJo9IU9ynLHNnbobT2w9NUor1Ed5iTtkTNjARYQA6CpF4QEuksyd2PMycjG
EKw+JqisiV6J1iIz1HDnPMzB8ejTfLn+UJtIfCHvdbARuTMhEcAncopaNhirCXKH
2IF7sMbspVLfaKCik6N66dBfUgMs9ltfMD+zSltLdOy85WnP5Jy2LI5bg67zbyY9
oO+01/St5WdG5ymFHG8dUm7HJ7DKD3KVJth3w8HZu5aSg4R4Eoofrw==
=R622
-----END PGP SIGNATURE-----