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