REXX, SPF, Internet drafts


Catch you later… 💩

Whatever this playlist is, it is no buzz or music for G+, and has a label here.  YouTube's "share on blogger" feature is nice.


Channel banner

New banner (attribution: Georges Seguin, licence: CC-BY-SA 3.0):

Old banner (attribution: Christof Pins, licence: CC-BY-SA 4.0):
The banners are also available in a shared photo album with the hilarious Google search result (left side) in a readable size. The utter dubious licence is for the right side, I'd still say that this is PD-ineligible (no sweat), but IANAL.


Mismade Girl

Tracklist and background info on EARMILK (2016-03-03):
The model vs. DJ+writer battle ended in a model+writer truce.

Cute without ya

Testing the "share on blogger" feature with a start and end time:

19 extracted pictures in a photo album, CC-BY Emma Blackery.



At some point in time Blogger added a Google+ tracking script to this blog, and I've not yet figured out how to get rid of this spyware. If you have a browser extension blocking wannabe-social tracking sites such as ShareMeNot this won't affect you. While at it and FWIW I have replaced the CC-BY-SA 3.0 license for this blog by 4.0, removed the dead Google Reader links, and fixed some other minor blog template rot issues.

Recently Google Sites somehow managed to clobber embedded Google Docs videos with non-existing YouTube content. Just embedding the video again can fix this. Just for fun I try this also here—for the complete story see its page on my Google site:


Corrigendum #9 clarifies noncharacter usage in Unicode

While waiting for the "missing" combining character forbidden to go with the new U+1F4A9 I'm slightly confused by Corrigendum #9: There is a small block of 32 non-characters in the BMP (plane 0), and each plane (0..16) ends with two non-characters, for an immutable (stability guaranteed) total of 66=32+2×17 non-character code points. It's good to know that converters from, say, UTF8 to UTF16LE, are not forced to handle non-characters as errors. Unlike surrogates, surrogates outside of UTF16 or not appearing in a surrogate pair to address code points outside of the BMP still are errors.

But one non-character U+FFFE (arguably one plus sixteen in all planes) has an important purpose, it is not a BOM, also known as signature.

UTF16 texts starting with hex. FEFF are supposed to be UTF16BE (big endian), while UTF16 texts starting with hex. FFFE are supposed to be UTF16LE (little endian). UTF16 texts starting with non-character U+FFFE instead of U+FEFF would be a major pile of poo.


FAT16 fun

Continuing the FAT fun saga with an unplanned sequel:  rexxfat used partition type 05 instead of 06 for BigFAT, i.e., FAT16 with 2**16 or more sectors.  I've fixed this stupid bug in the last rexxfat version.  The virtual hard disk image works fine in a Windows 2000 virtual machine:

The odd size 3759 MB matches what I have on a memory card.  It's rather tricky to copy the disk image to the memory card, either rawcopy doesn't support copies to a physical device, or it was not obvious for me how to manage this.  Using diskpart to unmount the one and only volume on this partitioned memory card wasn't good enough for write access, eventually the diskpart  delete volume magic did the trick.  Presumably that also explains my difficulties with other tools including dskprobe and HxD.

Looking for explanations I stumbled over SysInternals SDelete.  That article doesn't explain how Windows 7  manages volumes on memory cards, but answered another open question: Compressed, encrypted and sparse are managed by NTFS in 16-cluster blocks.  That matches my observation for rxsparse.rex, 16×4=64 KB, and if the SysInternals folks got that right Wikipedia also got it right.  Hint, it is very likely that SysInternals got it right, after all they were the first to offer a working DOS NTFS-driver permitting write access.



After creating a somewhat dubious MBR in disk images formatted by rexxfat I've now also added a dummy VBR doing more than only INT 18h (hex. CD 18).  For an ordinary FAT12, FAT16, or FAT32 volume this VBR displays the OEM Id. (8 characters at offset 3 of the VBR), the file system type string (8 characters at offset -8 from the begin of the VBR code), the volume label (11 char.s, offset -19, default NO␠NAME␠␠␠␠), and the wannabe-unique volume Id. (4 bytes shown as 8 little endian hex. digits, offset -23).

Wikipedia claims that the file system type string and the volume label only exist for an extended boot signature introduced by 29h at offset -24 from the begin of the code.  In other words, for 28h only the volume id. can be expected to exist, and for anything else these 1+4+11+8 bytes won't exist at all, notably on media formatted with PC DOS 3.x or earlier.  The rexxfat dummy VBR code is designed to work for any 29h FAT layout with sector size 256, 512, or more.  Check out the script for the OpenWatcom WASM assembler MBR and VBR sources in two REXX comments.

Apparently Darwin VBRs expect that SI points to their partition table entry in the MBR, and just in case rexxfat now guarantees that when it boots an active primary partition.  Looking at a Darwin MBR source I think this is only used in its magic to boot a logical disk in an extended partition, i.e., the relative number of hidden sectors from the begin of the EBR to the logical disk VBR is updated on the fly to yield the absolute number of hidden sectors from MBR to VBR, and that's of course the LBA.  This won't help normal FAT VBR code expecting the number of hidden sectors in its own BPB, and the rexxfat MBR limits its efforts to initialize SI as expected for primary partitions.  Patching loaded FAT VBRs in an extended partition is left as an exercise for the EBR code — and so far rexxfat only formats one primary partition with a FAT.  More convoluted tasks are a job for GRUB, BCDEDIT, diskpart, parted, or what you have.

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.


Creative Commons Licencexyzzy blog
CC Attribution-ShareAlike 4.0 License
Search only IANA, ICANN, IETF, OpenSPF, Unicode, W3C, xyzzy

About Me

My photo
Hamburg, Germany
ex-Wikiholic, now having fun with the last days of Google+ and its murderess.