[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [tpop3d-discuss] append-domains still working in 1.4.1?
From: |
Chris Lightfoot |
Subject: |
Re: [tpop3d-discuss] append-domains still working in 1.4.1? |
Date: |
Thu, 25 Apr 2002 11:13:27 +0100 |
User-agent: |
Mutt/1.3.24i |
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 'address@hidden' to being sent as two separate keys in
> > the hash, 'name' and 'domain'.
>
> 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 address@hidden supplied by the user, or, if no address@hidden:] 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
cation, a request is passed to each of a number of con
figured authenticators in turn, until the client is suc
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
address@hidden 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 = foo
local-part not set
domain = dom
If this fails, and append-domain is set, then a second
attempt will be made with:
user = foo
local-part = foo
domain = dom
Otherwise no second attempt is made.
If instead the client says:
USER address@hidden
then authentication will be attempted using:
user = address@hidden
local-part = foo
domain = 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
address@hidden is supplied, authentication will be attempted with
user = foo, local-part = not set and domain = 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.
--
`Evans boldly put 50 atm. of Ethylene in a cell with 25 atm. of oxygen. The
apparatus subsequently blew up, but luckily not before he obtained the spectra
shown in fig. 8.' A J Merer and R S Mulliken, Chem. Rev. 69, 645 (1969)
Re: [tpop3d-discuss] append-domains still working in 1.4.1?, Chris Lightfoot, 2002/04/25