-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/26/2013 09:48 PM, Phil Pennock wrote: > On 2013-06-26 at 14:20 -0400, Daniel Kahn Gillmor wrote: >> kristian, you're doing a much-appreciated job maintaining the SKS >> pools. I was wondering if you'd consider allowing members of the >> pool(s) to register an e-mail address associated with their >> server, to receive notifications when their server gets ejected >> from the pool. >> >> For example, i'd like to be able to communicate with you (out of >> band, perhaps) and say "my keyserver, zimmermann.mayfirst.org, >> belongs in the ha pool. please have your system send me an alert >> if it gets removed from that pool".
Hi Daniel, First of all, thanks for your thoughts. Indeed; this was why we, as Phil pointed out, added the server contact configuration directive; To be able to have better communication between the keyserver operators. When it comes to automatic notification from the pool software, it is something I've been pondering from time to time, however I've so far always concluded that the additional complexities weren't worthwhile. My primary intention with the pool is to have enough good servers in it, to at any time provide a good experience for OpenPGP users. To be able to provide information to server operators as a benefit of that, given that the information is collected anyways, is an added bonus, but it isn't vital for the pool per se. As such this has to be a balancing act vs design complexity and server resources that might compromise the primary goal. Also, I immediately see some possible drawbacks. Say for instance my IPv6 connection drops down and people somehow are signed up to receive messages when they drop out of that subpool, suddenly I've spammed half (or actually more than that) of the operators :) But adding to that, as I'm performing polling from a single location (albeit correcting the data by using measuring stations around for the geographical sub-pools), connectivity issues, or simply polling a server when it is busy will lead to it being excluded for the next hour. This really isn't an issue for the user experience, but it would contribute to noise if automatic messages were sent out. > > We added "Server contact:" to the stats page, configured by > "server_contact:" in sksconf, which lets folks set the PGP keyid of > the operator, without directly putting email addresses into a > scrapeable page, and Kristian collects that already, showing it as > [@] after some server names. > Indeed > Perhaps we should add a "pool_policy:" statement, which applies to > everyone running any kind of pool, with a very simple grammar? > See above re complexity. For instance this would only apply if the keyserver responds and the software can read the status page. If the intent is to have a hidden server, it would still show up if the server doesn't respond. I can (to some extent) see the value in this if the purpose is to not want the traffic/use from the public, however it is far simpler for me to just add such servers to the global exclude list, and IMHO if that is the purpose, only accepting certain IP ranges to use the server (or a non-standard port) intuitively makes more sense to me. > Key: hkpsport=11373 Action: HKPS service offered, any SRV > records should reference this port; if port is not 443, do not > include in non-SRV pool definitions. > The pool crawler actually detects non-443 port HKPS servers already using the SRV record, however offering this in DNS is currently disabled due to the GnuPG issues involved (1446,1447). - -- - ---------------------------- Kristian Fiskerstrand Twitter: @krifisk - ---------------------------- Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Testis unus, testis nullus A single witness is no witness -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.0-beta210 (GNU/Linux) iQIcBAEBCAAGBQJRy0wEAAoJEJjgB+fVz3pu7fUP/2i5263+GL1qqL/XfCHwetIS OlsNAwa6o8RegRFYitjVxNNqMkz+OEEwcjBeADnwpoYEiyXMisJdNhW+X1/0P2YZ weGkvJ/3LaY5OFu8uRoK8smDaEyiL5DiqbN762s7ffYT3UFZDWEo3uoUgMrNfmez DGHuKnBwaAGJby9wka21urCNgsFDdtdHoZSv9kkzWnuOXJB6ditcWsiNyDSA2w7T U0K+z/C5BpYfityQ8kN2NCT0N9nVaJlCkN/HWrWO4J3Y09AnzyLHi81FcaT/cYqT LQG8HGBpXMPbBf4vc6Mj1jIVdWT3n1YHgXMJZ4FI+uTvQnQBNUPgKiwor61a6i+J HD2rzM+tpsQ9evQUMH7vBULzYv3sHqKks5QxG2kdZkNfQDnnLDzMIkP4/LSFIzD1 EPbcy+6Oxg+Q26U/1gup/4UixqYZF8a4rPML3t5WMfVacNowAPtzU/mA08iwFObU 3Ajrga/QwsMh/Z61ByKH9Oak63btM/1qrsHTPZLz8H8ILHp4lDOZFpOZwhCPrz4s L2/NPQbT10d384ySKko9K2Hlwv/5MYHto2CnbmmNaQW/shMwoHd0TScbGIQVmm68 5eAPIpvf1uydBH7p4ewEgJ2V5omBybuoUS4ySAPKzi3v08NLkGASJkAP1lsTxB8z kP5LIAWg/lkpZ/ojlPcz =XDcX -----END PGP SIGNATURE----- _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
