On Fri, 23 Apr 2004, Philip Hazel wrote:
> There was one ISP that used to respond with an encrypted
> string that recorded in great detail the identify of who had originated
> the message (time, date, which dial-in line, etc), but because it was
> encrypted, it told nothing to the outside world.
Well, we're no ISP, but that's pretty much what our mail system does,
using the crypted option of pidentd. See "man identd" for the pidentd
package (I think this is standard in RedHat, no?):
An encryption key (1024 bytes long) should be stored in
the key file ( /etc/identd.key ) [...]
The returned token will contain the local and remote IP
addresses and TCP port numbers, the local user's uid num
ber, a timestamp, a random number, and a checksum - all
encrypted using DES. The encrypted binary information is
then encoded in a BASE64 string (32 characters long) and
enclosed in square brackets to produce a token that is
transmitted to the remote client.
The encrypted token can later be decrypted by the idecrypt
command. This program will attempt to decrypt a token with
all the keys stored in the key file until it succeeds (or
have tried all the keys).
> However, if it was sent back as part of a query, they could figure
> out exactly who caused the problem.
Yes, and not only that - the fact that the partner site could present
this token (which we then successfully decrypt) helps to validate that
their complaint is genuine. I must admit this has rarely been an
issue in practice - but it's comforting to know that it's there,
nevertheless, in case some rogue or confused admin should launch some
misguided complaint against us.
