alan wrote:
At 21:52 10/07/2009 Friday, Stuart D. Gathman wrote:
In my "best-guess" algorithm, a validated HELO (that resolves to the connect ip)
is added to the collection of validated PTR records for the PTR mechanism.
I propose to make this a MUST behaviour for spfv3.
To check if I understood, assume the client said
HELO mta.example.com
MAIL FROM:<me(_at_)example(_dot_)com>
Now, if rDNS is correct, "ptr:%{h}" matches. If rDNS is not set up,
but you add the helo name, it obviously matches. The ptr mechanism
checks that each lhs _ends in_ the rhs, a somewhat crude form on DNS
names relationship.
While SPF macros can select the rightmost parts of HELO, and it is
possible for SPF to verify that HELO matches the connect ip (somewhat
kludgily), I haven't hit on a way to check that the rightmost parts
of HELO match the MAILFROM domain using spfv1.
I have some doubts about the meaning one can derive from that, in
particular for virtual domains. In general, one cannot deduce
administrative relationships: mta.example.com may be unrelated to
example.com, just like the latter is unrelated to .com.
A literal compare operation added to spfv3 could serve the same purpose,
but I don't have any concrete syntax proposals.
If helo name addition were mandatory or rDNS correct, ptr:%{o} would
match in some cases. We could add a "ptrhelo" mechanism to mean ptr +
helo, and/or a "helo" one to mean only the added helo name. Thus,
helo:%{h} would be a tautology. Is that (sort of) what you meant?
the checking of ptr > name > ip
is a method of validating the ip's identity not the helo or the spf records
It has been standardized as The "iprev" Authentication Method in
http://tools.ietf.org/html/rfc5451#section-3
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com