On Sat, 11 Jul 2009, Alex van den Bogaerdt 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.
It seems a newline is needed here. Your next line talks about HELO which
cannot be validated.
HELO is "validated" in the same way a PTR record is - by checking for
a match with connect ip.
as a PTR record, and is already available. PTR lookups are a waste
of bandwidth (for authentication purposes) when HELO is available and
valid.
Here you mean DNS PTR lookups, not the SPF ptr mechanism, right?
I mean the DNS PTR lookups caused by the SPF ptr mechanism.
While SPF macros can select the rightmost parts of HELO,
Why would one do this?
To match it to the mail domain like with the SPF ptr mechanism.
and it is
possible for SPF to verify that HELO matches the connect ip (somewhat
kludgily),
Am I missing something? You seem to be describing the following:
You are missing something. Think of HELO as a PTR record that is
supplied via SMTP instead of a DNS lookup.
I haven't hit on a way to check that the rightmost parts
of HELO match the MAILFROM domain using spfv1.
The ptr mechanism, which should be abandoned IMHO, does this. But indeed
that needs a properly setup DNS. It seems that you propose something like
"heloptr" which would use the HELO parameter instead of what is found in the
in-addr.arpa part of the DNS tree. Those who are unable or unwilling to
setup DNS correctly, won't understand that "heloptr" would also match
dyn-10-1-2-3.customer.example.com. This may or may not be harmful, but is
probably not what was intended.
It is what was intended. When example.com contracts with bigisp.com to
provide a dsl account with a small static IP block (typically /29), the problem
is that bigisp.com is typically unable to reliably provide PTR records
chosen by example.com[*]. However, the PTR record they do chose will
be something like 'dyn-10-1-2-3.bigisp.com', *not* 'dyn-10-1-2-3.example.com',
(never mind that the contract is for static ips).
Bigisp.com should simply not use the PTR mechanism for an SPF policy.
A literal compare operation added to spfv3 could serve the same purpose,
but I don't have any concrete syntax proposals.
[*]The most egregious example is bellsouth, who happily charges you for
static IPs, but then reports those static IPs to the DUL.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------------------------------------------
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