More about the SPF RRTYPE

[Murray S. Kucherawy]

Over on the exim-users mailing list, someone just complained that libspf2 tries for RRTYPE 99 (SPF) before 16 (TXT). That's what the standard says to do, but it also means some sites that firewall out unknown RRTYPEs cause clients to time out on the 99 before they try 16. During that time, some SMTP clients time out altogether and try again later, and the mail ultimately never gets through.

Maybe this isn't news to anyone, but I thought it might be interesting to bring up in the context of the SPF update and recent discussion.

-MSK



-------------------------------------------
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/6959934-50ec8f89
Modify Your Subscription: https://www.listbox.com/member/?member_id=6959934&id_secret=6959934-b7c4528d
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=6959934&id_secret=6959934-edadf31a&post_id=20110815150620:A82338A4-C771-11E0-ABF9-BA9C74BD6DA2
Powered by Listbox: http://www.listbox.com

[Frank Ellermann]

Post by Murray S. Kucherawy
Over on the exim-users mailing list, someone just complained that
libspf2 tries for RRTYPE 99 (SPF) before 16 (TXT).  That’s what the
standard says to do, but it also means some sites that firewall out
unknown RRTYPEs cause clients to time out on the 99 before they try
16.  During that time, some SMTP clients time out altogether and
try again later, and the mail ultimately never gets through.
Maybe this isn’t news to anyone

Yes, but 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?

-Frank

[Dotzero]

On Mon, Aug 15, 2011 at 4:00 PM, Frank Ellermann

Post by Frank Ellermann

Post by Murray S. Kucherawy
Over on the exim-users mailing list, someone just complained that
libspf2 tries for RRTYPE 99 (SPF) before 16 (TXT).  That’s what the
standard says to do, but it also means some sites that firewall out
unknown RRTYPEs cause clients to time out on the 99 before they try
16.  During that time, some SMTP clients time out altogether and
try again later, and the mail ultimately never gets through.
Maybe this isn’t news to anyone

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

4.4. Record Lookup

In accordance with how the records are published (see Section 3.1
above), a DNS query needs to be made for the <domain> name, querying
for either RR type TXT, SPF, or both. If both SPF and TXT RRs are
looked up, the queries MAY be done in parallel.


We may want to change the MAY to a SHOULD.

[Alessandro Vesely]

Post by Frank Ellermann
1 - try the SHOULD type 99 approach again, a PS could succeed where
an "experiment" failed.

-1, the value of an experiment is to direct a PS to successful approaches.

Post by Frank Ellermann
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.

+1, it is already an option. In Scott's words, the current spec says that

Operators are perfectly free to waste resources querying for Type SPF or
not. If you get both back, then the Type SPF takes precedence, but there's
no requirement to look for it.
http://www.ietf.org/mail-archive/web/domainrep/current/msg00404.html

I like TXT for unstructured data, I don't think it's ugly. For uniformity
with other protocols (DKIM, ADP, VBR, ...) we might introduce _spf.domain at
the same time as we deprecate type 99. While only updated software can query
_spf.domain directly, careful use of redirection and wildcards may provide
for some advantages.

Post by Frank Ellermann
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.

-0, it is possible, but brings no practical advantage.

jm2c

[Frank Ellermann]

Post by Alessandro Vesely

Post by Frank Ellermann
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.

-0, it is possible, but brings no practical advantage.

My "+1" would match your "+1", hopefully we'll have some clear evidence
that type 99 didn't make it if somebody insists on more than a "say-so"
in the 4408bis work.

For the EDNS0 issue I recall that "our" (= on the OpenSPF mailing list,
not in RFC 4408) expectations in 2008 were more optimistic than what
the "Netalyzr" folks found in 2011. The openspf.org server waits for a
reboot, for a semi-public XPS copy of the original Satin-Weaver PDF see

<https://docs.google.com/uc?id=0B-dYNQQki8VUNTUwOWFkMTEtODhiMi00Y2M5LTkwNzMtYTQyODVjNDUzZDc0&export=download>

-Frank

[Stuart D. Gathman]

Post by Alessandro Vesely
I like TXT for unstructured data, I don't think it's ugly. For uniformity
with other protocols (DKIM, ADP, VBR, ...) we might introduce _spf.domain at
the same time as we deprecate type 99. While only updated software can query
_spf.domain directly, careful use of redirection and wildcards may provide
for some advantages.

I think that type 99 is a lost cause for v=spf1, but should be kept
in reserve for v=spf3 - where it would be a MUST.

--
Stuart D. Gathman <***@bmsi.com>
Business Management Systems Inc. Phone: [phone] Fax: [phone]
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

[Stuart D. Gathman]

Post by Stuart D. Gathman

Post by Alessandro Vesely
I like TXT for unstructured data, I don't think it's ugly. For uniformity
with other protocols (DKIM, ADP, VBR, ...) we might introduce _spf.domain at
the same time as we deprecate type 99. While only updated software can query
_spf.domain directly, careful use of redirection and wildcards may provide
for some advantages.

I think that type 99 is a lost cause for v=spf1, but should be kept
in reserve for v=spf3 - where it would be a MUST.

With type 99 for v=spf3, if you don't support v=spf3, you query TXT only.
Otherwise, you query SPF first (hopefully by the time v=spf3 is out DNS
servers will stop timing out for unknown RR queries), and TXT if not
present to check for a v=spf1 policy. There was no real motive to check
SPF (especially given the DNS server bugs) for v=spf1, but there is a motive
to check for the new version, which presumably lets you reject more
mail with enhanced features. If too many DNS servers are still broken
when v=spf3 comes out, then the parallel query thing could be
needed. Otherwise, a lot of TEMPERRORs on email from domains with broken
servers could be a motive to get them fixed.

--
Stuart D. Gathman <***@bmsi.com>
Business Management Systems Inc. Phone: [phone] Fax: [phone]
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

[Julian Mehnle]

Post by Frank Ellermann
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.
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.

[Dotzero]

Post by Julian Mehnle

Post by Frank Ellermann
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.
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.
-Julian

+1

[Alex van den Bogaerdt]

Post by Julian Mehnle

Post by Frank Ellermann
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.
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

[Dotzero]

On Wed, Aug 17, 2011 at 10:18 PM, Alex van den Bogaerdt

Post by Alex van den Bogaerdt
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

Set aside the specifics you propose, I don't see the next go around as
an "experiment". We should be looking at an effort that is standards
track rather than experimental.

As far as a the religious wars that were MARID, I have a feeling that
if we stay tightly focused on cleaning up what we have already we can
avoid that.

[Julian Mehnle]

Post by Alex van den Bogaerdt

Post by Julian Mehnle
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(!)

TXT-type with a name prefix is clearly better than SPF-type because the
SPF type is still not as widely implemented as the TXT type, and the name
prefix doesn't have significant disadvantages. (All in the context of
v=spf3, of course. A prefix will never fly for v=spf1.)

Post by Alex van den Bogaerdt
[...]
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.

No one cares about RFC 4406 at this point. I don't think anyone will make
an effort to move that one to the Standards Track. So no problem there.

[Alex van den Bogaerdt]

Post by Julian Mehnle

Post by Alex van den Bogaerdt

Post by Julian Mehnle
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(!)

TXT-type with a name prefix is clearly better than SPF-type because the
SPF type is still not as widely implemented as the TXT type, and the name
prefix doesn't have significant disadvantages. (All in the context of
v=spf3, of course. A prefix will never fly for v=spf1.)

Agreed, we should not try to "fix" spf1. But I think the _spf name prefix
is more for "v=spf1b", and we should also think about "v=spf3".

The choice to make now is: do we go for SPF policies in TXT records under
the _spf label of a domain, exclusive_or do we go for using the SPF record
type. Do not make the same mistake again, do not allow TXT and/or SPF.

As seen from an spf1 point of view, _spf.{$domain} is better than a TXT
record at {$domain}. And I tend to agree: an SPF record at {$domain} which
is nothing more than a disguised TXT record, is not the way to go.

But that does not mean we should not use it at all. If we go from ASCII
elements to a binary format, it can have advantages.

Dotzero wants to go standards track. This can happen anyway. The options
I see right now are:

I: document the current work, no alterations, go for standard
II: document the current work, include the name prefix, apply some other
small fixes for lessons learned (e.g. PTR), and define "v=spf1b", as a
standard, only in TXT records
III: continue experimenting, building on the current experiment

I think III is not mutually exclusive with either I or II?
My preference would be a combination of II and III.

another 2c
Alex

[Julian Mehnle]

Post by Alex van den Bogaerdt
[...]
Dotzero wants to go standards track. This can happen anyway. The
I: document the current work, no alterations, go for standard
II: document the current work, include the name prefix, apply some
other small fixes for lessons learned (e.g. PTR), and define "v=spf1b",
as a standard, only in TXT records
III: continue experimenting, building on the current experiment
I think III is not mutually exclusive with either I or II?
My preference would be a combination of II and III.

II is worthless because it would immediately abandon the entire deployed
base of both v=spf1 records published and SPF implementations installed,
without giving us the benefit of a full revisit and overhaul that v=spf3
could give us.

To be even more explicit: At this time I do not care about anything but
getting v=spf1 on the Standards Track as-is (with only the minimum set of
changes required to achieve the goal). There is a very large deployed
base, and that should be recognized as a standard.

[Commerco WebMaster]

Julian,

Post by Julian Mehnle

Post by Alex van den Bogaerdt
[...]
Dotzero wants to go standards track. This can happen anyway. The

-- snip options --

Post by Julian Mehnle
To be even more explicit: At this time I do not care about anything but
getting v=spf1 on the Standards Track as-is (with only the minimum set of
changes required to achieve the goal). There is a very large deployed
base, and that should be recognized as a standard.
-Julian

I have not posted to this list in a very long time, but as an early
adopter and implementer of v=spf1 (and hopefully somewhere along the
line, a somewhat useful contributor), I must agree with you.

Is there any place to view an outline for the minimum set of changes to
which you refer? It would be nice to confirm that our own v=spf1
records still conform to the draft as it stands today and that the
records will continue to work with the changes to qualify v=spf1 for
Standards Track.

Best,

Alan M

[Frank Ellermann]

Post by Commerco WebMaster
Is there any place to view an outline for the minimum set of changes to
which you refer?  It would be nice to confirm that our own v=spf1 records
still conform to the draft as it stands today and that the records will
continue to work with the changes to qualify v=spf1 for Standards Track.

If you are aware of the errata on openspf.org (no changes for three years)
it should roughly constitute the "minimum set of changes".

Actually Scott could publish his draft "as is", changing the draft name
from I-D.xxx-kitterman-yyy or similar to I-D.4408bis-yyy in a 4408bis WG
later is common practice.

-Frank

[Scott Kitterman]

Post by Frank Ellermann

Post by Commerco WebMaster
Is there any place to view an outline for the minimum set of changes to
which you refer? It would be nice to confirm that our own v=spf1 records
still conform to the draft as it stands today and that the records will
continue to work with the changes to qualify v=spf1 for Standards Track.

If you are aware of the errata on openspf.org (no changes for three years)
it should roughly constitute the "minimum set of changes".
Actually Scott could publish his draft "as is", changing the draft name
from I-D.xxx-kitterman-yyy or similar to I-D.4408bis-yyy in a 4408bis WG
later is common practice.

Scott needs to find some time to beat it into a reasonably stable state first.

Scott K

[Frank Ellermann]

Post by Scott Kitterman
Scott needs to find some time to beat it into a reasonably stable state first.

The folks on the xml2rfc list are often helpful. The old XML won't
work as it was, some legalese has changed, and the DTD is also not
more exactly as it was for 4408 (minor changes wrt appendices etc.)

Have fun

[Murray S. Kucherawy]

-----Original Message-----
Sent: Saturday, August 20, 2011 6:49 AM
Subject: Re: [spf-discuss] Re: More about the SPF RRTYPE

Post by Frank Ellermann
Actually Scott could publish his draft "as is", changing the draft name
from I-D.xxx-kitterman-yyy or similar to I-D.4408bis-yyy in a 4408bis WG
later is common practice.

Scott needs to find some time to beat it into a reasonably stable state first.

It might be possible to get the XML source for RFC4408 from the RFC Editor, if that's how it was submitted to them.

It can be tedious to take the text raw and put it into XML, but it has been done...

[Murray S. Kucherawy]

-----Original Message-----
Sent: Wednesday, August 17, 2011 7:19 PM
Subject: Re: [spf-discuss] Re: More about the SPF RRTYPE

Post by Julian Mehnle
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 lot of people would be happy if SPFbis said to use an "_spf" TXT record, and the various open source and commercial implementations evolved to comply. People could leave SPF TXT records in the current location for transition purposes as long as they like, but we should explicitly deprecate that practice and encourage the new one.

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

Some of this stuff might fly, if we do indeed move the TXT record, but we'll also need to come up with tools that the average sysadmin can use to generate a TXT record in a BIND zone file that matches the new specification. The thought of doing this stuff in a conventional text editor will set a barrier to entry.

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.

What are the bases for those changes?

-MSK

[Scott Kitterman]

Post by Murray S. Kucherawy

-----Original Message-----
Sent: Wednesday, August 17, 2011 7:19 PM
Subject: Re: [spf-discuss] Re: More about the SPF RRTYPE

Post by Julian Mehnle
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 lot of people would be happy if SPFbis said to use an "_spf" TXT
record, and the various open source and commercial implementations evolved
to comply. People could leave SPF TXT records in the current location for
transition purposes as long as they like, but we should explicitly
deprecate that practice and encourage the new one.

I'm against any gratuitous incompatibilities. I'm not aware of any actual
problems caused by the current TXT usage in SPF. The _spf approach would make
wild carding impossible (_spf.*.exmple.com), but I'm not sure I really care.
Someone may.

I think for 4408bis saying SHOULD NOT Type SPF (99), SHOULD TXT, MAY _spf TXT
is reasonable. Then in the next update Type SPF could be retired and if there
is deployment, _spf could be preferred.

Scott K

[Julian Mehnle]

Post by Scott Kitterman
I'm against any gratuitous incompatibilities. I'm not aware of any
actual problems caused by the current TXT usage in SPF. The _spf
approach would make wild carding impossible (_spf.*.exmple.com), but
I'm not sure I really care. Someone may.

I don't care about wildcarding either. Wildcarding in general isn't too
useful. And there is no need to publish "v=spf1 -all" for non-existent
domains. Any sane MTAs will reject mail from NXDOMAIN anyway.

Post by Scott Kitterman
I think for 4408bis saying SHOULD NOT Type SPF (99), SHOULD TXT, MAY
_spf TXT is reasonable. Then in the next update Type SPF could be
retired and if there is deployment, _spf could be preferred.

"MAY _spf TXT" is hardly reasonable because that will mean receivers will
have to include _spf TXT in their policy discovery, which at this point
will effectively be even less useful than looking up SPF, so hardly
anyone will do it. Chicken/egg problem all over again. Let's save that
for v3.

[alan]

Post by Scott Kitterman
I'm against any gratuitous incompatibilities. I'm not aware of any actual
problems caused by the current TXT usage in SPF. The _spf approach would make
wild carding impossible (_spf.*.exmple.com), but I'm not sure I really care.
Someone may.
I think for 4408bis saying SHOULD NOT Type SPF (99), SHOULD TXT, MAY _spf TXT
is reasonable. Then in the next update Type SPF could be retired and if there
is deployment, _spf could be preferred.
Scott K

can i humbly suggest instead of _spf
we suggest to use
_spf1

to leave room for later potentially incompatible
_spf3

thus people querying can be told to MUST look for _spf1.domain.tld/TXT and MAY if nonexistant look for domain.tld/txt

thus implementers can publish

_spf1.domain.tld IN TXT "v=spf1 whatever -all"
_senderid.domain.tld IN TXT "v=spf1 whatever -all"
domain.tld IN TXT "v=spf1 redirect:_spf1.domain.tld -all"
domain.tld IN TXT "spf2.0/mfrom redirect:_senderid.domain.tld ?all" <any other junk thrown into txt
domain.tld IN TXT "spf2.0/pra ?all" <any other junk thrown into txt
(yes i publish sender-id to stop them mis-using my spf as such)

or whatever they want

and have their record work with new libspf(1 lookup) and old libspf(2 lookups) and all those horrid senderid implementors (2 lookups)

when spf3 comes round we just add

_spf3.domain.tld IN TXT "whatever"

and let implementors leave the old spf1 stuff in place for those recievers not doing spf3 yet
but spf3 requesters will only query _spf3
so once adopted by all (ie the libspf is common) then extra crap in the txt for the domain can be weeded

Post by Scott Kitterman
-------------------------------------------
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/13124949-0b42f103
Modify Your Subscription: https://www.listbox.com/member/?&
Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20110818143728:1EEEF82A-C9C9-11E0-906B-FB4D5F1CDC4B
Powered by Listbox: http://www.listbox.com

[Frank Ellermann]

The _spf approach would make wild carding impossible (_spf.*.exmple.com),
but I'm not sure I really care. Someone may.

nslookup -q=txt *.claranet.de
nslookup -q=txt xyzzy.claranet.de

I guess I care at least as far as xyzzy.claranet.de is affected... ;-)
But I can't tell how popular such "catchall" constructs still are in 2011,
or rather how unpopular they are today.

My "experiment" to report all spam to ***@xyzzy at SpamCop failed years
ago when I hit SpamCop report limits, or when I got spam faster than I
could report it, or when Clara.Net sometimes disabled this catchall when
their server couldn't handle the resulting traffic anymore.

Some days ago I saw a mail to nur-fuer-***@xyzzy used *once* in NetNews
(German mail abuse newsgroup) before I knew SPF, or maybe even before SPF
existed. Whatever spammers do with their address lists, removing "cruft"
is obviously not their top priority. If the spammer spent real money for
the list containing nur-fuer-***@xyzzy or any part-of-message-***@xyzzy
(s)he's entitled for a full refund as far as I'm concerned.

-Frank

[Julian Mehnle]

Post by Murray S. Kucherawy

Post by Alex van den Bogaerdt
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 lot of people would be happy if SPFbis said to use an "_spf"
TXT record, and the various open source and commercial implementations
evolved to comply. People could leave SPF TXT records in the current
location for transition purposes as long as they like, but we should
explicitly deprecate that practice and encourage the new one.

This would abandon the entire deployed base and would also cause
implementations to do *yet another* lookup for policy discovery (in
addition to domain./TXT and possibly domain./SPF). I don't think there's
any point in doing that for v=spf1.

If the IETF WG that's under discussion for this effort were to introduce
*such* a change, I doubt that many SPF implementations would follow suit
soon. Everyone would probably just continue what they're doing and
ignore 4408bis.

Post by Murray S. Kucherawy

Post by Alex van den Bogaerdt
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. [...]

Some of this stuff might fly,

I don't think it would. If a sysadmin has got two options: (1) follow
4408bis and use new tools to create an obscure binary representation in
TXT \123\456 format or (2) just type up your SPF record in human-readable
format and ignore 4408bis, which are they going to do?

Besides, the binary format wouldn't fundamentally solve any problems.
Merely ~doubling the maximum number of declarations in an SPF record is
worth almost nothing.

- -Julian

[Stuart D. Gathman]

Post by Julian Mehnle

Post by Murray S. Kucherawy
I think a lot of people would be happy if SPFbis said to use an "_spf"
TXT record, and the various open source and commercial implementations
evolved to comply. People could leave SPF TXT records in the current
location for transition purposes as long as they like, but we should
explicitly deprecate that practice and encourage the new one.

This would abandon the entire deployed base and would also cause
implementations to do *yet another* lookup for policy discovery (in
addition to domain./TXT and possibly domain./SPF). I don't think there's
any point in doing that for v=spf1.

+1

No point to yet another lookup for v=spf1. Save the type99 vs _spf debate
for v=spf3.

--
Stuart D. Gathman <***@bmsi.com>
Business Management Systems Inc. Phone: [phone] Fax: [phone]
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

[Alessandro Vesely]

Sorry for the delay.

Post by Murray S. Kucherawy

From: Alex van den Bogaerdt
TXT records with an _spf prefix is clearly a better approach than TXT
records without this prefix.

I think a lot of people would be happy if SPFbis said to use an
"_spf" TXT record, and the various open source and commercial
implementations evolved to comply. People could leave SPF TXT
records in the current location for transition purposes as long as
they like, but we should explicitly deprecate that practice and
encourage the new one.

I agree with Julian that we shouldn't force receivers to do yet
another discovery query. (Rather, we should almost deprecate one.)
However, I have a couple of observations:

1. SPF deployment seems to leave something to be desired for
validating helo-names. Anything that allows to publish a single
record for all hosts should be taken into consideration.

2. There is a noticeable deployment of _spf.domain already. AFAIK,
it is used by large mailers for inclusion by their clients. We
should explore and possibly document such practice. Ideas?

Post by Murray S. Kucherawy

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

Some of this stuff might fly, if we do indeed move the TXT record,
but we'll also need to come up with tools that the average sysadmin
can use to generate a TXT record in a BIND zone file that matches
the new specification. The thought of doing this stuff in a
conventional text editor will set a barrier to entry.

There's a draft for defining new types in /etc/rrtypes [L]. I propose
to postpone this discussion to when that language will be settled, so
that we can check whether it handles a binary type 99.

[L] http://tools.ietf.org/html/draft-levine-dnsextlang

--

[Frank Ellermann]

Post by Alex van den Bogaerdt
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.

Post by Alex van den Bogaerdt
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.

Post by Alex van den Bogaerdt
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 :-)

Post by Alex van den Bogaerdt
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