[[e-mail] (Nigel Metheringham): Re: TAP/RFC931 support for Smail 3.1.26 ]

[Stephen D Crocker <[e-mail]>]

------- Forwarded Message

Date: Fri, 28 Aug 92 16:41:26 +0000
From: [e-mail] (Nigel Metheringham)
Received: by NeXT Mailer (1.63)
To: [e-mail] (Neal Becker)
Subject: Re: TAP/RFC931 support for Smail 3.1.26 
Cc: [e-mail], [e-mail]

> Thanks!  I see that the patch for smail uses libauth.  This
> will work OK with identd?

The patche used libauth simply because the only other library there  
is (unless its well hidden) is marked as being a preliminary  
beta-test.

As I understand it RFC931 begat Ident which is much the same, but  
slightly more baroque (although its still a nice small RFC).  TAP is  
the attempt for Ident to get back to its roots - a good simplified  
minimalistic version of Ident.  However they all basically respond to  
a query of the form 

  <localport>, < foreignport>
and return
  <localport> , <foreignport> : USERID : <systemtype> : <conn-info>

The rub is that ident could theoretically return almost anything as  
the conn-info (for most cases read username - although some sites  
return an encrypted username which they can decode - they just don't  
want to publish the information).  TAP implementations are intended  
to be a little more lenient with their return values (ie no wierd  
characters in the conn-info).

To return to the question, the libauth library will work agains any  
of the ident implementations, however it does no special processing  
on the returned conn-info, and neither does my patch.  If someone  
puts all sorts of junk in that field then something could break (ie 8  
bit characters in the Received header of the message).  


The question is, should I patch the patch to defend against oddities  
in the server response, and what should that entail?

	Nigel.

------- End of Forwarded Message