On Mon, Feb 23, 2004 at 03:29:55PM -0500, Hector Santos wrote:
|
| 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
|
That is correct. I was a little surprised when Gordon incorporated this
change (which originates in DHVP), because it allows a spammer to say HELO
dmp-always-allow.spammer.com and MAIL FROM:<joe-job(_at_)victim(_dot_)com>.
SPF purposely avoids this scenario; it only checks the HELO machine
domain when the MAIL FROM is null and therefore there is no joe-job
victim.
I originally posted about this here:
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200307/0020.html
|
| 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.
|
That is correct.
| 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.
You've lost me :) ... can you explain to me what the desired benefit is?
I must be missing the value of the HELO machine name.