Re: Re: More about the SPF RRTYPE

On 18 August 2011 04:18, Alex van den Bogaerdt wrote:

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

Yes, it was not exactly the fault of SPF that support for other types, let
alone new types, was poor.  And maybe still is poor, I can't tell.  That's
also *not* nice for SRV and NAPTR.

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

Well, if I'd want "binary" I won't try to use TXT or other "textual" types,
and vice versa.  Optimizing SPF for IPv4 is not more very interesting from
my POV; but optimizing SPF for IPv6 and/or EAI could be relevant "soon" when
IPv6 is used for SMTP and/or when EAI is ready.

> generally speaking: the effect of SPF on DNS usage should be evaluated
> and the protocol should, where necessary, be adapted.

4408bis should mention potential MX abuses explicitly, at least for folks
like me who ended up here because they liked the "reverse MX" RMX idea :-)

> Let's talk.

Please do, but as long as v=spf1 is not on "standards track" suggesting
new "SPF 3" or "SPF 2012" experiments could be a distraction.  Fortunately
v=spf1 was "ready for IPv6" many years before SMTP was "ready for IPv6".

But the SPF readiness for EAI is somewhat dubious wrt "per user policies".
I think the solution is still "obvious", as there is no difference between
the "EAI experiment" and the future EAI standard for the purposes of SPF.

Unrelated:
1 - Could somebody please kick the openspf.org server?  Or please tell me
    how that's arranged these days, so far I only understood that the old
    "SPF webmasters" mailing list for server issues does not more exist.
2 - On the MARF list Murray asked who intends to implement SPF modifiers
    for mail abuse reporting, that question should be forwarded to the
    developer list (for unknown reasons I used to have two accounts, and
    the now revived SPF discuss+help account doesn't help with SPF devel).

-Frank