----- Original Message -----
From: "Meng Weng Wong" <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Monday, February 23, 2004 2:51 PM
Subject: Re: [spf-discuss] Possible SPF machine-domain loophole???
On Mon, Feb 23, 2004 at 02:14:53PM -0500, Hector Santos wrote:
| Meng (or anyone else who wish to comment),
|
| Please correct me if I am wrong here, but I believe I found a loophole.
|
| Having added support for both DMP and SPF. The key difference seems to
be
| DMP checks both; return path and machine domains, SPF only fallbacks to
the
| machine domain when the return path domain is NULL.
|
| With DMP, the logic is to check for the return path domain first of a
| DENY=ALLOW/DENY and fallback to the machine domain for possible
spoofing.
|
| With SPF, if I read the specs right, the logic is to check only the
| machine domain iff (if and only if) the return path domain is a null
| address.
Can you explain what you mean by
- "machine domain", and
- "check"
"Check" = Lookup
"machine domain"
Sorry, my bad. I use the term "machine domain" to refer to the client
domain name as provided at the HELO/EHLO stage. There was a discussion the
IETF-SMTP mailing list regarding the RFC 2821 ABNF for "HELO/EHLO domain"
and the RFC 2822 "domain" ABNF that supports an option string field. Since
HELO does not support the optional string, my input was to make the
distinction with a new ABNF:
Clip from IETF-SMTP thread/message...
"Since it is only meant to help in the logging/tracking on the helo/ehlo
domain literal and for maximum backward compatibility, do not have the
[string] element in the domain ABNF, and If possible, to be clear and
specific, add a new "machine-domain" ABNF:
helo = "HELO" SP Domain CRLF
ehlo = "EHLO" SP Machine-Domain CRLF
Machine-Domain = domain [ string ]
This way, there would be no confusion with other ABNF specifications
requiring the domain element."
Using machine-domain has stuck with me since for distinction. My fault. :-)
Anyway, the domain provided by the client at HELO/EHLO.
The DMP logic is to:
1) lookup reverse-ip.in-addr._smtp-client.return-path-domain
return path domain = null -> goto #2
deny=allow -> exit pass
deny=deny -> exit fail
none -> goto #2
2) lookup reverse-ip.in-addr._smtp-client.helo/ehlo-domain
deny=allow - exit pass
deny=deny - exit fail
exit unknown
As I understand it, the SPF logic is:
1) lookup return-path-domain
return path domain = null -> goto #2
follow SPF processing with no provision to go to #2 at this point.
2) lookup helo/ehlo-domain
follow SPF directive processing
So as I see if, the only way to check for a helo/ehlo domain spoof is when
the return path is a NULL address.
I guess the smart SPF host who see this potential can implement a SPF macro:
v=spf1 ........ ptr:%{h} -all
Does that make sense?
However, if the return path domain is spoofed (points to another site), you
won't get this policy information.
I have some ideas. But I want to hear your thoughts first since I might be
reading the specs wrong. At the minimum, the specs will need to point this
out.
Thanks
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com