[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[leafnode-list] Re: Header PATH and FQDN
Am 07.12.2010 22:32, schrieb clemens fischer:
> Matthias Andree wrote:
>> True enough, but steps 8 and 9 in RFC 5537 section 3.5 are quite clear:
>> begin quote
>> 7. If the Newsgroups header contains one or more moderated groups
>> and the proto-article does not contain an Approved header field,
>> [redirect to moderator] [...]
>> 8. Otherwise, a Path header field with a <tail-entry> MUST be added
>> if not already present.
>> 9. The injecting agent MUST then update the Path header field as
>> described in Section 3.2.1.
>> end quote
> Re. FQDN: is it not possible to insert an IP (dotted quad form) in
> place of a FQDN if the injecting agent doesn't have a real FQDN?
> I think I've seen this in live headers.
Yes, but that does not take us much farther. I'd have to weed out invalid
addresses (RFC-1918, multicast, APIPA, 0.0.0.0, 127.*) much the same as I reject
default and other widespread domain names.
> If the RFC 5537 allows this, then leafnode should allow it, too. The
> next question would be how to reliably determine this IP or how to
> configure it for dial-up hosts, but this shouldn't be a hard problem.
While permitted (note that it should be a domain literal then although the ABNF
syntax does not enforce that), it is discouraged in section 3.1.3 (p.12) of RFC
5536 due to lack of uniqueness.
If the host only has RFC-1918 IPv4 addresses, or only IPv6 addresses, what are
you going to pick? There are thousands of computers with 192.168.178.X and
192.168.2.X address (anything that is a DHCP client to an AVM Fritz!Box or
Deutsche Telekom Speedport router), too, and we don't need our external IP
address for any other purpose.
We might as well create some namespace (a subdomain in this case) under
leafnode.org and use a host-and-time-based UUID, or some-128-bit-hash of UUID to
mask the MAC address.
Any of this will likely add library dependencies...
leafnode-list mailing list