This allows the `ssl` setting to control TLS vs. plain HTTP, and makes
it possible to create a compatible service that doesn't use TLS (e.g.,
for testing).
Comments should only be used if the code is doing something
subtle/tricky/non-obvious/unusual, otherwise they're distracting and
might get out of sync with the code (in which case it becomes
difficult to tell if it's the comment or the code that's wrong). If
the code is difficult to understand without comments but is doing
something ordinary, then the code needs to be modified to improve
readability.
Rationale:
* For consistency.
* It's generally not a good idea to mix interpolation with `sprintf`
because the interpolated string itself might coincidentally (or
maliciously) contain format specifiers.
This adds a protocol to email IP address changes without needing a
dynamic DNS service. This is useful if you don't use a DDNS service
but want to be notified when the IP of a machine changes.
Rationale:
* Logging to STDERR enables separation of processable output (e.g.,
`--version` or `--help`) and ephemeral status/error messages.
* A single file descriptor for all log messages makes it easier for
users to capture all log messages.
* Consistency: it's what most utilities do.
`$config{$h}{'status'}` was always initialized to a non-`undef` value,
so the `//` fallbacks never did anything. Instead, any protocol that
does not explicitly update the legacy `status` variable (such as
`godaddy`) would always appear to have failed even if it had
succeeded.
Change the `status*` variables to `undef` by default, and only set
them when an attempt is made so that the legacy `//` fallback works as
expected.
This shouldn't matter in practice because the `status-ipv$ipversion`
field is initialized to a non-`good` value so failing to set it to
`bad` doesn't turn it `good`, but it improves readability.
The `dnsexit2` protocol reads the IP addresses from the new `ipv4` and
`ipv6` variables, so it should update the `status-ipv4` and
`status-ipv6` variables.
