Mailing List Archive

SPF Internationalization
New article:
SPF Internationalization <http://www.openspf.org/FAQ/I18N>

Also modified: <http://www.openspf.org/FAQ/Hints_for_ISPs>

I've moved the "last erratum" to "confirmed". There was no
consensus for picking only "no match", or only "PermError".

Everybody agreed that a TempError is impossible, and that
2.5.7 has to be updated if the outcome is not "PermError":
http://www.openspf.org/RFC_4408/Errata#permerror-invalid-domains

Frank

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com
Re: SPF Internationalization [ In reply to ]
Kudos to you!

Frank Ellermann wrote:
> New article:
> SPF Internationalization <http://www.openspf.org/FAQ/I18N>

That's Greek to me, though. Actually, an example with uppercase macros
would be most welcome in the specs. If you feel like writing one on
the FAQ meanwhile, it may clarify its meaning.

> Also modified: <http://www.openspf.org/FAQ/Hints_for_ISPs>

* I have two servers at 194.243.254.162/31, CIDR is a useful
abbreviation here too.

* Many use "_spf" rather than "dummy". Does it make sense to follow
that trend?

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com
Re: SPF Internationalization [ In reply to ]
Alessandro Vesely wrote:

> Actually, an example with uppercase macros would be most welcome
> in the specs. If you feel like writing one on the FAQ meanwhile,
> it may clarify its meaning.

We can discuss it here until we arrive at a less Greek version ;-)

domain.example. IN TXT "v=spf1 a -all exp=mumble.example"
mumble.example. IN TXT "http://domain.example/why?user=%{l}"

For a local part "test" in test@domain.example this results in
an explanation http://domain.example/why?user=test as it should.

For a local part "oo/ps" in "oo/ps"@domain.example it should
also work, http://domain.example/why?user=oo/ps

For a local part "Q&A" in "Q&A"@domain.example it could break:
http://domain.example/why?user=Q&A Worse for "S P" (space):
http://domain.example/why?user=S P

The issue depends on the position of the macro in the URL, and
of course on the expansion of the macro. The same examples
with %{L} instead of &{l} yield:

http://domain.example/why?user=test - as before
http://domain.example/why?user=oo%2Fps - %2F for /
http://domain.example/why?user=Q%26A - %26 for &
http://domain.example/why?user=S%20P - %20 for SP

It's not limited to %{L} vs. %{l}, e.g., HELO %{H} can also be
odd if it's used in the URL of an explanation.

[ISP hints]
> I have two servers at 194.243.254.162/31, CIDR is a useful
> abbreviation here too.

Yeah, I wanted a /24 example, where I can later say 11.22.33.nn
without going into details, ISPs are supposed to know what CIDR
is - just in case the word "CIDR" links to RFC 4632 :-)

> Many use "_spf" rather than "dummy". Does it make sense to
> follow that trend?

Sure, here I didn't want to go into details about underscores
in DNS names, there's a separate FAQ entry for this:
http://www.openspf.org/FAQ/Underscore_in_DNS

If readers think that _spf is required it won't cause havoc,
but implementors should not get odd ideas, any <target-name>
is okay.

Frank

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com
Re: Re: SPF Internationalization [ In reply to ]
Frank Ellermann wrote:
> For a local part "Q&A" in "Q&A"@domain.example it could break:
> http://domain.example/why?user=Q&A

That's a good one, it is clear why it won't work.

Re-reading the first section, I realized it is about exp. (When I read
it yesterday, I didn't know about uppercase macros, so I turned on the
second link, and from rfc4408 to rfc3986 to learn what's an "uric".)
What about changing the section title to something like

== '''Why'''-service URL in Explanation modifiers

Yes, including the user's name in a why-page is a probably good idea.

> http://domain.example/why?user=Q%26A - %26 for &

So the above would result from

> <code>v=spf1 mx -all exp="See http://www.example.com/why?user=%{L}"</code>

Hm... are quotes ok? (domain-spec = macro-string domain-end looks broken)

> It's not limited to %{L} vs. %{l}, e.g., HELO %{H} can also be odd
> if it's used in the URL of an explanation.

Won't it come in its '--'-encoded form anyway?

> [ISP hints]
>> Many use "_spf" rather than "dummy". Does it make sense to follow
>> that trend?
>
> Sure, here I didn't want to go into details about underscores in
> DNS names, there's a separate FAQ entry for this:
> http://www.openspf.org/FAQ/Underscore_in_DNS
>
> If readers think that _spf is required it won't cause havoc, but
> implementors should not get odd ideas, any <target-name> is okay.

It could be clarified in the text that it doesn't have to be "_spf".
There are chances that the string exemplified is pasted in the zone
file "as is" (luckily, rfc2606 has been issued early enough...)

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com
Re: SPF Internationalization [ In reply to ]
Alessandro Vesely wrote:

>> For a local part "Q&A" in "Q&A"@domain.example it
>> could break: http://domain.example/why?user=Q&A

> That's a good one, it is clear why it won't work.

Okay, I guess <http://www.openspf.org/Modifier/exp>
could say a tiny bit more about this topic... ;-)

[.[. Personally I think exp= and %{l} are some of the
two worst ideas in SPF, exists: and SOFTFAIL are
also dubious. Considering how many folks get mx
wrong, while Doug invents DDoS scenarios based
on mx and %{l}, I'm ready to add mx to the list,
as long as RMX stays in the credits... ;-) ]]

> What about changing the section title to something like
> == '''Why'''-service URL in Explanation modifiers

Which section, the remark in FAQ/I18N ? It can get
a link to Modifier/exp, and Modifier/exp can explain
the fine print of upper case macros with an example.

> v=spf1 mx -all exp="See http://www.example.com/why?user=%{L}"
> Hm... are quotes ok?

Yes and no, that's not how it works. exp= points to
a domain, e.g. "v=spf1 mx -all exp=go.to.example"

go.to.example has a TXT record with the explanation:
go.to.example. IN TXT "See http://www.example.com/why?user=%{L}"

>> HELO %{H} can also be odd if it's used in the URL
>> of an explanation.

> Won't it come in its '--'-encoded form anyway?

Is that about punycode xn--labels ? What I meant was
a crappy HELO oem&computer - clear SMTP syntax error,
but if the receiver accepted it, and later tries to
report a FAIL with an explanation including %{H},
then it is at least transformed to oem%26computer

[dummy vs. _spf labels]
> It could be clarified in the text that it doesn't
> have to be "_spf". There are chances that the string
> exemplified is pasted in the zone file "as is"

Which string, dummy.your.domain.example ? If an ISP
tries to use that as is it's no ISP, problem solved ;-)

> (luckily, rfc2606 has been issued early enough...)

ACK, it should be updated adding the 11 IDN test TLDs.

Frank

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com
Re: Re: SPF Internationalization [ In reply to ]
My recollection is that the internationalization work was going on in
parallel to the design of SPF and we conciously decided to ignore it. If
there are some complexities that aren't well dealt with it should not
suprise anyone.

Am I remembering the right internationalization issue?

Scott K

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com
Re: SPF Internationalization [ In reply to ]
Scott Kitterman wrote:

> we conciously decided to ignore it
[...]
> Am I remembering the right internationalization issue?

We didn't *ignore* it <shudder /> We found that SMTP
is as it is (explained in the first part of FAQ/I18N),
nothing to do for SPF.

Publishers can create their own WHY-pages behind URLs
of exp= explanations in any script and language. If
they try something more direct and it is not US-ASCII
it won't work as they expect it.

For EAI: Current SPF implementations don't support
U-label to A-label (IDNA), or do they ? Depending on
the programming language this might as simple as a
library call, or a serious headache.

Frank

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com
Re: Re: SPF Internationalization [ In reply to ]
Frank Ellermann wrote:
> Okay, I guess <http://www.openspf.org/Modifier/exp>
> could say a tiny bit more about this topic... ;-)

Thanx

> [.[. Personally I think exp= and %{l} are some of the
> two worst ideas in SPF, exists: and SOFTFAIL are
> also dubious. Considering how many folks get mx
> wrong, while Doug invents DDoS scenarios based
> on mx and %{l}, I'm ready to add mx to the list,
> as long as RMX stays in the credits... ;-) ]]

I may agree about the cosmetic nature of exp= and %{l}, but exists: is
not dubious at all, as it enables complete control over authorized
senders. For example, one could configure a server so as to
automatically add a remote client's IP to various DNS records upon IP
assignment, possibly including A, MX, and PTR besides accomplishing
the exist: mechanism. That would allow to go along with the wishes of
those folks who run an MTA on their laptops...

The rest of your note is rather puzzling... you must refer to the mx
mechanism, not the mx record type, but why RMX?? You mean the old
http://www.tools.ietf.org/html/draft-danisch-dns-rr-smtp-04 ?
BTW, that link in http://old.openspf.org/rfcs.html is broken.

>> What about changing the section title to something like
>> == '''Why'''-service URL in Explanation modifiers
>
> Which section, the remark in FAQ/I18N ?

I meant "SPF Internationalization". Actually both words in the current
section title (the 2nd one in its abbreviated form) appear already in
the titles hierarchically above that section, i.e. page and site.

> It can get
> a link to Modifier/exp, and Modifier/exp can explain
> the fine print of upper case macros with an example.

Great!

> [dummy vs. _spf labels]
>> It could be clarified in the text that it doesn't
>> have to be "_spf". There are chances that the string
>> exemplified is pasted in the zone file "as is"
>
> Which string, dummy.your.domain.example ? If an ISP
> tries to use that as is it's no ISP, problem solved ;-)

Hmm... I regret I just canceled the quoting about oem&computer,
otherwise I could mention that as a counter example ;-)

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com