[tpop3d-discuss] append-domains still working in 1.4.1?

Chris Lightfoot chris at ex-parrot.com
Thu, 25 Apr 2002 11:13:27 +0100


On Thu, Apr 25, 2002 at 02:24:33AM -0700, Paul Makepeace wrote:
> On Wed, Apr 24, 2002 at 09:10:52PM -0500, Christopher E. Stith wrote:
> > I did have to check the C code in pop.c to find the change from the
> > name being sent as 'name@domain' to being sent as two separate keys i=
n
> > the hash, 'name' and 'domain'.
>=20
> I wonder if calling it local_part & domain wouldn't be a bad idea, in
> line with exim & other MTAs' terminology, and the general principle of
> avoiding vague monikers like "name".

auth-perl and auth-other supply for USER/PASS or APOP
authentication the following keys:

    user            the username as supplied by the client

and optionally

    local_part      the local-part of an email address
    domain          the domain of an email address

The latter are derived either by splitting up a string of
the form foo@bar supplied by the user, or, if no [@%!:] is
present, and a domain is specified for the listener, by
using $(user) as the local-part and the domain associated
with the listener as $(domain).

This has changed somewhat from 1.3.5 to 1.4.1; there is a
section in tpop3d.conf(5) which explains it:

       Authentication   is  supported  using  the  conventional
       USER/PASS method, or the challenge-response APOP method.
       When  a client connects to tpop3d and attempts authenti=AD
       cation, a request is passed to each of a number of  con=AD
       figured authenticators in turn, until the client is suc=AD
       cessfully authenticated or all authenticators have  been
       tried.

       The  information  supplied with each request consists of
       user, the user name as supplied by  the  client;  local-
       part,  the local-part of a virtual-domain email address,
       and domain, the domain in which authentication is taking
       place.  By default, domain is the domain associated with
       the address to which the client has connected.

       If the client's supplied username contains  one  of  the
       characters  `@', `%', `:' or `!', it is interpreted as a
       local-part@domain combination, and the given  local-part
       is  used  while  the  given  domain  replaces the domain
       derived from the address to which the client  connected.

       If  there  is  no  separator,  authentication  is  first
       attempted with no local-part and the default domain;  if
       this  does  not  succeed,  and  the append-domain global
       option  is  set,  then  authentication  will   also   be
       attempted  with  the local-part the same as the supplied
       user and the default domain.

       For example, if the client sends the command
         USER foo
       to the  listener  for  domain  `dom',  tpop3d  will  try
       authentication with the parameters:
         user       =3D foo
         local-part   not set
         domain     =3D dom
       If  this  fails, and append-domain is set, then a second
       attempt will be made with:
         user       =3D foo
         local-part =3D foo
         domain     =3D dom
       Otherwise no second attempt is made.

       If instead the client says:
         USER foo@bar
       then authentication will be attempted using:
         user       =3D foo@bar
         local-part =3D foo
         domain     =3D bar
       In this case, no alternative attempt  will  be  made  if
       authentication fails.

The effect of strip-domain is that, if a username such as
foo@bar is supplied, authentication will be attempted with
user =3D foo, local-part =3D not set and domain =3D dom. (This
bit isn't actually in the man page.)

Arguably this is over-complicated, but I think that it's
preferable for all of the available information to be
supplied to authenticators than for some of it to be
hidden.

--=20
`Evans boldly put 50 atm. of Ethylene in a cell with 25 atm. of oxygen. T=
he
 apparatus subsequently blew up, but luckily not before he obtained the s=
pectra
 shown in fig. 8.' A J Merer and R S Mulliken, Chem. Rev. 69, 645 (1969)