purl.net/xyzzy

Reviving this dead blog was possibly maybe a bad idea, but I'm still terrified to get a Twitter account to replace G+ in April, maybe Blogger is goodbad enough. At least it still works, and apart from Gmail I'm not aware of any other still working Google product. #GirlsGotGroove could be an argument for Twitter, "registering" hashtags is about as much fun as playing with WikiData.

The old websites are now all gone, R.I.P.: 2004, 2010, 2012. For the required legalese I trusted that "click on banner + click on imprint" covered your privacy also for this blog, i.e., there is no such thing as privacy on Google products, and if you allow third party cookies SoundCloud.com (example) will track you on any page with an SC iframe (=technical term for an embedded object, ignoring images + applets.)

SC politely asked to put that info into any affected privacy policy, so consider it done here for this blog until I get a static blogger page for some remotely legal legalese. I still don't do analytics or monetisation or cookies, not here, not on YouTube, nowhere, period. BTW, get an AdBlock, and disallow JavaScript on all sites complaining about it, c.f. chrome://settings/content/javascript.

DynDNS killed xyzzy.webhop.info some years ago, IIRC it was a redirect to my Google Apps account. Meanwhile Google also killed the target, good riddance.

DynDNS also killed xn--80akhbyknj4f.boldlygoingnowhere.org and xn--xyzzy.boldlygoingnowhere.org belonging to my i18n-fun pages here. That's sad, but the fun factor was possibly maybe limited to some folks I (virtually) met in IETF WGs. All is well if it ends well, SPF is a proper RFC now, the technically dubious (or ethically too ambitious) Sender-ID is dead, and I even produced a silly RFC to balance the IAB appeal.

YAM (Yet Another Mail)

The ways of the IETF are completely bizarre, and the Tao of IETF does not really explain why.  In a recent episode the YAM WG will be closed after moving two of four e-mail related RFCs to STDs:

• STD 72 is RFC 6409 and covers "mail submission".  That's what ordinary users like you and me do when they send e-mail using their ISP or another ESP such as Gmail, GMX, or Hotmail.
• STD 71 is RFC 6152 and covers "8BITMIME".  That's what everybody uses since about 1993 outside of pure US-ASCII 7bit e-mail.

Oddly YAM didn't finish the work on a 5321bis and a 5322bis.  That leaves us with STD 10 (SMTP) and STD 11 (message format) in limbo, unless you still consider RFCs 821 and 822 (vintage 1982) as the ultimate truth in IETF e-mail standards.

For SPF it's quite interesting to look at the "reverse path" fine print of RFC 821, e.g.:

• The first host in the <reverse-path> should be the host sending this command. (RFC 821 about MAIL FROM).
• In any case, the SMTP adds its own identifier to the reverse-path. (RFC 821 about Relaying).

Sadly RFC 4408 specifying SPF also claims that this RFC 821 feature is archaic.  Of course today nobody uses reverse and forward paths as designed about thirty years ago for e-mail routing, but for SPF the MAIL FROM address is still supposed to indicate the responsible party for technical problems with an e-mail, also known as bounce address.  And e-mails forwarded to a third party need a new envelope sender address, otherwise SPF checks at this third party will fail, because IP-addresses authorized to send e-mail from the first party won't match IPs used by the forwarding second party.  That's as simple as it can be, ignoring the minor detail that RFC 1123 broke it about twenty years ago.

By the way, the work on 4408bis is supposed to start really soon now, but my confidence in the IETF is somewhat limited.

RFC 6055: IAB Thoughts on Encodings for Internationalized Domain Names

The new RFC 6055 is quite interesting, it discusses issues of IDNA vs. UTF-8 encodings in the DNS and other namespaces.

By definition any valid IDNA A-label, i.e., an ASCII compatible label starting with xn-- and following the IDNA rules specified in RFC 5890 and RFC 5891 (among others), has a corresponding Unicode U-label, i.e., a label containing non-ASCII characters. The IDNA encoding mechanism punycode tries hard to create short A-labels, because there is an upper limit of 63 octets per label, and another upper limit of 255 octets per FQDN DNS query consisting of zero or more labels.

RFC 6055 does not propose to use redundant UTF-8 DNS entries for raw U-labels in addition to the IDNA A-labels, so I guess there are too many cases where this would anyway not work, e.g., when an otherwise valid U-label consists of more than 63 UTF-8 octets.

When I get "a round tuit" I'll look into a now long expired EAI SPF draft, where using raw UTF-8 labels was the only viable solution for an EAI extension of SPF. Even if nobody implements this draft and/or if EAI never really makes it the last "tombstone" version should reference RFC 5321 (SMTP), RFC 5890, RFC 5891, and RFC 6055.

John Klensin is the author or a co-author of all RFCs mentioned here. I should check what else he published between RFC 5321 and RFC 6055, but it is nice to see that for at least one person in the world "RFC" still works as a "Request For Comments". :-)

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.

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.

RFC errata

Various pending RFC errata have been published recently, among others for RFC 2069, 2822, and 4408. The RFC editor might soon offer a Web form for submissions as outlined in an Internet Draft.

• The 2069 erratum resulted in an editorial update of my MD5 test suite.
• The 2822 erratum was already covered in the 2822upd drafts.
• The 4408 erratum is actually a link to the OpenSPF errata page.

HTML test

Here's my OpenSPF page, it offers a customized search engine provided by Google.