There are a number of schemes for dealing with spam that boil down to'people will get SSL certificates, you only accept email with a validcertificate, and if people still spam the certificate authority willrevoke their certificate'. There is a simple, core problem with theseschemes:

Certificate revocation never works.

Certificate authorities are paid by the people who they issuecertificates to, not by the people accepting those certificates. Thepeople who provide the money do not want their certificates revoked, andso it is not in

Consider a not entirely hypothetical situation: you have an officemachine that serves as one end of a GRE tunnel ,and, in addition to its official network interface, has a fluctuatingnumber of secondary interfaces on various internal VLANs for testing,debugging, and so on. The simple approach for such a machine is to justturn on global IP forwarding and cross your fingers that no one willdecide to make the machine their gateway (apart from the GRE link). Butthis is not ideal; if nothing else,

I made a bugfix to our mail server's configuration today.

Size of the bugfix: 25 characters added to an existing line.

Size of the comment sort of explaining why the bugfix is necessary: sixlines.

(And a complete discussion of the issue would be much longer.)

Of course, this is not unique to system administration; programmingalso has that sort of bugfixes. I think system administration may bemore prone to it, because so few of our tools, especially the ones with complicated logic

Unlike many Unixes, Linux determines whether or not it does IPforwarding on an interface by interface basis, based on interface thepacket arrived on . While Linux has a global IP forwarding sysctl, net.ipv4.ip_forward , pretty much all this really does is (re)set thevalue for all of the interfaces and make it the default; you can stillchange individual interfaces later.

The fine controls are in /proc/sys/net/ipv4/conf/ , where thingsgo like