alex at vandenbogaerdt
Aug 17, 2011, 7:18 PM
Post #10 of 28
(1699 views)
Permalink
|
> Frank Ellermann wrote:
>
>> [...] it is clearly something that should be addressed in 4408bis:
>>
>> Apparently nobody intends to eliminate the ugly TXT abuse in v=spf1,
>> because it's years too late to try it, or IOW, the wannabe-experiment
>> failed to fix this.
>>
>> Possible ways to improve that situation in 4408bis:
>>
>> 1 - try the SHOULD type 99 approach again, a PS could succeed where
>> an "experiment" failed.
>> 2 - give up, note that TXT is ugly but can't be changed, and that
>> now is the time to drop SPF type 99 for the purposes of v=spf1.
>> 3 - explain that practical EDNS0 limits could affect TXT where type
>> 99 still works, but that trying both queries simultaneously and
>> pick the first answer is perfectly okay.
>>
>> I didn't look into RFC 4408 for some years, but IIRC (3) is allowed,
>> or isn't it?
>
> (3) is exactly what RFC 4408 already says.
>
> I don't see any benefit in changing that in 4408bis.
>
> I think RR type 99 won't be very useful in v=spf3 because using the TXT
> type with a name prefix (_spf) is clearly a better approach.
TXT records with an _spf prefix is clearly a better approach than TXT
records without this prefix. That does IMHO not mean it is also a better
approach than using SPF RR. I am not necessarily saying the opposite is
true either(!)
I think a very important lesson learnt should be: no "SHOULD", no choosing
between TXT and SPF. At least not when the only difference is the type of
RR. Why work on supporting SPF records when you can tell your customer
"just use TXT records".
Another important lesson learnt: It is good to have a major player
supporting the protocol. But it has to be our protocol, not a derivative
using the same encoding but with different semantics. I am not opposed to
try again and integrate both experiments into one, but I do fear another
episode of two slightly incompatible protocols where one ABuses the
efforts of the other.
The experiment could enter a new phase. There is no need for ASCII
characters in the SPF record. This means that for instance
"ip4:192.168.234.123" could be encoded in 5 octets instead of 19 plus 1
for a separating space. There could/should be a "home base" modifier, so
that repetitive domain parts or network numbers only have to be specified
once. I mean: in network 192.168.100.0/24 authorize hosts 1,5,100 and 200.
Under domain name subdomain.example.com authorize hosts alpha bravo and
delta. Obviously such a "home base" should result in shorter notation,
else the "old notation" is the better. The policy is evaluated left to
right, a new home base setting will be applied only for partial entries
following this home base. The default home base will be the domain being
queried, and the network {to be discussed}.
The use of PTR, and possibly MX, should IMHO be depriciated. More
generally speaking: the effect of SPF on DNS usage should be evaluated and
the protocol should, where necessary, be adapted.
Participants in the next leg of the experiment MUST support v=spf1
policies, encoded in either SPF records or in TXT records. They MUST also
support v=spf2012 encoded in SPF records. If they choose to also _publish_
a v=spf1 policy, then they MUST add the modifier "spf2012=preferred"
unless this would cause their v=spf1 policy to become too big.
I'm sure there's more to discuss for those who are interested, and I am
also sure some will find my proposal utterly useless. Let's talk.
my 2c
Alex
-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110817221849:67B50C18-C940-11E0-ACD3-F3162202B49F
Powered by Listbox: http://www.listbox.com
|
signature.asc
1
