spf-discuss
[Top] [All Lists]

Re: Possible SPF machine-domain loophole???

2004-02-23 13:29:55

----- 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