SPF EAI and IDN TLDs

SPF, EAI, and IDN TLDs are not directly related, but I ended up as author of two related Internet-Drafts: SPF EAI is now at version 03, and the IDN test TLDs are already at version 11.

The new 2606bis draft with the eleven IDN test TLDs now also covers the corresponding nine IDN example labels. Reserving the nine IDN example TLDs is one of those procedural stunts. The contributor tricking me into this adventure does this all the time, it's scaring.

For what's it worth, there is also a relatively new OpenSearch draft, most of it still TBD. It depends on a cleanup of the IANA Atom link-relation registry adding the mostly identical HTTP link-relations and other missing pieces.

No plans to transition management of the root zone file to ICANN

In a letter to the ICANN Chair published 2008-07-30 the U.S. DoC notes:

First, it is important to note that the IANA functions contract was not part of the JPA mid-term review and the Department views these as two distinct instruments. As the community is aware, the IANA functions contract covers the performance of a series of currently interdependent technical functions that enable the continued efficient operation of the Internet, including processing requests to change the authoritative root zone file. Implementations of changes to the authoritative root zone file are performed by VeriSign under the terms of a separate agreement with the Department.

The Department believes that it is important to clarify that we are not in discussions with either party to change the respective roles of the Department, ICANN or VeriSign regarding the management of the authoritative root zone file, nor do we have any plans to undertake such discussions. Consistent with public statements made by the United States governement starting in 2000 and reinforced by the 2005 U.S. Principles on the Internet's Domain Name and Addressing System, the Department, while open to operational efficiency measures that address governments' legitimate public policy and sovereignty concerns with respect to the management of their ccTLD, has no plans to transition management of the authoritative root zone file to ICANN as suggested in the PSC documents.

In an article about the All important IANA the author wrote: An ICANN that is completely privatised and does not behave well afterward also might easily be stripped from the IANA contract and therefore its grip on the root zone.

RxWhois IETF 72 edition

Based on the latest DNSBL Internet-Draft rxwhois 2.1.2 now supports DNSBL queries for IPv6.

I've not yet found any black listed IPv6. The potential test entries ::FFFF:127.0.0.2 or ::2 are not listed on the nine pre-configured DNSBLs used by rxwhois.

The simple REXX code to transform an <IPv6address> into the reverse ip6.arpa format turned out to be more interesting than I thought; see procedure XIPV6 in the source… :-)

The classic SPF FAQ

After years on the SPF help list it is interesting that some folks still have difficulties with the very simple idea behind SPF. Modified question to protect the innocent:

my mail is MX relayed via anti.spam.example and then on to good.isp.example, and good.isp.example is reapplying SPF as if anti.spam.example were the originating MTA.

Answer: If anti.spam.example forwards mail to third parties it is the originating MTA as far as SPF checkers at these third parties are concerned.

can anyone say whether SPF would normally have any problems with mail relay?

Answer: No problems with mail relays on the side of the sender or on the side of the receiver. SPF is in essence for the one critical hop where two unknown strangers (sender and receiver) meet.

Now if you introduce a second critical hop in the form of "forwarding to third party" this will nowhere work "as is":

S -> F -> R instead of S -> R

The sender S defines S-IPs permitted to send MAIL FROM S. The sender S has no reason to permit sending IPs of any forwarder F or forger F, in fact S has no idea who F is.

The receiver R checks that MAIL FROM S comes from one of the S-IPs as defined in the sender policy of S. Without intervention sending IPs of forwarder F will FAIL, as for sending IPs of a forger F.

There is no difference between "forwarding to third party" and "forging" wrt SPF. Of course there are some things a legit F or R could optionally do:

• R could white list F as legacy forwarder (legit forger).
• F could rewrite MAIL FROM S to S@F (like mailing lists).
• F could store mails, and let R use say POP3 to fetch it.

If F and R do nothing about this situation – and that is perfectly allowed – R sees a FAIL, and hopefully rejects the MAIL FROM S actually sent from F.

After that F is obliged to send an error report (bounce) back to S. The sender S can then bypass the forwarder F and send the mail directly to R (if the bounce contained the real address at R).

If you think that there is a problem, then your problem is almost certainly with forwarder F, not with S or R.

It is up to you how you solve your problem with F. In my opinion an entity using the name anti.spam.example should know that forwarding mail "as is" to third parties is a part of the problem, YMMV.

Frisian frs vs. stq

Before 2006 there was only one language tag for the Frisian languages, fy. 2005-11-16 ISO 639.2 identified fy as Western Frisian, adding frr for Northern Frisian, and frs for Eastern Frisian. So far it is clear, ignoring the detail that Northern Frisian consists of several rather different dialects.
 
After the publication of RFC 4646 the IANA language subtag registry now contains fy, frr, and frs. But not fry, this is an alpha-3 alias of fy, and the RFC 4646 rules are roughly that shorter alpha-2 ISO 639 codes win.
 
It is not obvious what the Y, R, and S in these subtags stand for, one plausible theory is that S stands for Seeltersk, the Frisian language spoken in Saterland; see the S marker on the map.
 
Interestingly ISO 639-3 uses stq instead of frs for this language, this is also the code used for the stq.wikipedia. Two alpha-3 ISO 639 codes for one language are rather strange, and there is another theory to explain this situation: frs is the code of the Lower Saxon nds dialect spoken in Eastern Frisia, the territory including Aurich at the A marker on the map. In that case the S might stand for Saxon.

The ISO 639-2 rules make it fairly difficult to get codes for nonsense, there must be some evidence what they had in mind when frs was registered. OTOH with codes such as eur and tlh Occam's razor might miss the point.

rxwhois 2.1.1

The modifications in version 2.1.1 of rxwhois.cmd include the addition of whois.nic.asia, whois.nic.bi, whois.adsib.gob.bo, whois.registry.gy, whois.nic.ht, whois.nic.im, whois.kcce.kp, whois.nic.mq, whois.nic.org.mt, whois.nic.pr, whois.co.ug, and vunic.vu from the usual sources: IANA, whois-servers.net, guesswork.

Lost in space: whois.nic.ki, whois.nic.tel, and whois.cctld.uz. Some domain grabbers in the TLDs CM, FM, GD, KN, and PN were ignored. Eleven other whois.whatever.tld hosts were added, but these are (yet) no whois servers. The rxwhois manual page contains the version history up to 2.1 over the last six years.

HTML5: asinine + selfish

HTML5 "reuses the well-known URL moniker in the most asinine way, and blames the other standards (which he thankfully has no control over) for not supporting all of the possible crappy raw data that could be input in an HTML attribute."

"That's why this whole discussion about creating new identifiers and new protocols in HTML is a total waste of time — the rest of the world does not want it and will not allow it to be published as HTML5. Pound the sand all you like; the network standards will not change because they are designed to support everyone's needs, not just the selfish desires of a very small set of browser developers."

So far from a co-author of RFC 3986 (the Internet Standard STD 66 for URLs) and of RFC 2616 (the currently revised HTTP specification) in one of the various HTML5 flame wars.¹

Fast track IDN ccTLDs

There will be hundreds, thousands, or even millions of new top-level domains, from the variety known as gTLDs. "ICANN is working towards accepting the first applications in the second quarter of 2009", as noted in their process FAQ.

This also affects the "fast track" introduction of internationalized top-level domain names for territories with a country code, also known as IDN ccTLDs. "The Board intends that the timing of the process for the introduction of IDN ccTLDs should be aligned with the process for the introduction of new gTLDs", stated in an ICANN Board resolution.

Enough time to fix the toplabel bug in RFC 1123, document the IDN test TLDs as reported here ten months ago, and get ready with IDNAbis.

Lost + found: 268,435,455 free IPs

Three Internet Standards, one of them historic, RFC 3330, an RFC 3330 erratum, and three Internet Drafts entered the battle over 6.25% of all IPv4 addresses:

RFC 3330 lists special IPv4 addresses, among others 240.0.0.0/4 also known as class E. Allegedly "reserved for future use" on page 4 of the historic RFC 1700, formerly known as STD 2. The notation 240.0.0.0/4 stands for all IPv4 addresses starting with the four bits 1111, hex. F0 is decimal 240.

Page 4 of RFC 1700 actually belongs to an introduction with basic terms copied from RFC 1122, a part of STD 3. In fact RFC 1122 specifies 0.0.0.0/8 and 127.0.0.0/8 as listed in RFC 3330, but not 240.0.0.0/4.

RFC 1122 and the RFC 1700 intro only mention class E, but it is specified in RFC 1112, a part of STD 5. Apparently RFC 3330 got this wrong, RFC 1700 by itself did not register anything at all, it was a snapshot of various IANA registries with references to registrations of all "assigned numbers".

As the future of IPv4 is now before IPv4 is replaced by IPv6 the question is what to do with these 6.25% of all IPv4 addresses "reserved for future use" minus one 255.255.255.255 specified in RFC 1122. Three Internet-Drafts fight over it:

• IANA proposes to keep class E as is, because RFC 1700 said so.
• CISCO proposes to unreserve these 268,435,455 IPs reserved in RFC 3330.
• A third draft suggested to reserve these IPs for private use updating RFC 3330.

Ignoring the expired third draft as bad idea it will be interesting how the IETF manages to free this huge pool of IPv4 addresses while the rest of the world is busy to upgrade their hard- and software to IPv6. Apparently RFC 1112 does not do anything with class E apart from reserving it, it is about class D 224.0.0.0/4 multicast addresses. Or as RFC 1812 puts it:

The Class D (IP Multicast) and Class E (Experimental) address spaces are preserved, although this is primarily an assignment policy.

Update 1, it's a bit more complex: RFC 988, a predecessor of RFC 1112, created the 224.0.0.0/4 multicast addresses as class D out of the in RFC 960 reserved 224.0.0.0/3 block, the remaining 240.0.0.0/4 block got the name class E in RFC 990 obsoleting RFC 960. After that RFC 997 updated RFC 990 and listed the "Internet numbers" including class E, while RFC 1010 obsoleted RFC 990 and listed the "assigned numbers". RFC 1010 was a predecessor of RFC 1700 over many steps, RFC 997 was the predecessor of RFC 1166. In other words, RFC 1112 specifies class D, and RFC 1166 explains the remaining class E. RFC 1166 is only "informational", that's good news from the procedural side.

Update 2, a fourth draft was published: T. Savolainen proposes to use class E for hosts indicating that they can handle this , e.g., for dial-up connections.