General problems revolving around perl_access

Matt 'Goo Goo Dolls' Melton matt_08-02 at
Wed Aug 28 23:54:30 UTC 2002

Problem 1?

I've recently had to solve a problem where nnrpd dies and offers no
warning when it tries to pattern match (via wildcards) a non existent
news group.

In demonstration, $return_hash{"post"} = "alt.not.exist";, does not
cause nnrpd to die, however, $return_hash{"post"} = "alt.not.*";

I would like to see, if possible, support for matching/globing or the
whatnot of non-existent news groups as, in the the near future i
consider INN a perfect tool for serving dynamic news groups - where
newsgroups appear and disappear on a frequent basis. It would break
an access engine, if:
        $return_hash{"read"} = "!*.private" . join(',', @allowed);
whilst at that particular point in time no *.private groups exist;
this kind of situation i expect to happen on hosting servers, with
frequently changing newsgroups (closed to out going feeds naturally).

I've spent my time implementing an access method based on the
$attributes{username} and the interface connected to.

It's available via via anon ftp,
however it is not yet finished.

It revolves around a file called "access.conf". Both
and read that for the password and read/post flags via
the module It's based on the following format: {
        pass: fakepwd
        read: *
        post: *

Where it conforms to:
        $attributes{'username'} . '%' . $attributes{'interface'}
This is inline with recommended smtpd vhost usernames. As you may
note, if a '%' (percentage) symbol is found in the supplied username
by, then the current working interface is not used - again,
this allows for alias vhosts and ipbased vhosts. If the '%' symbol
is found, the user is authenticated as what they supply.

Problem 2?

It's been the basis of my testing of the new perl_* interface, and
I've come to note this problem. When returning
$return_hash{"post"} = "*, !*.private"; the server will die at
access - why is this, is "*, !*.private" the wrong kind of string
to return?

Also, when no username is returned for auth, my client receives
a syntax example - I assume this is part of the INN rfcs - however
I'd really appreciate seeing a different challenge auth (ie: if no
username is returned by the reader, then a null username is
authenticated with or without a declared password), as maybe a
commandline switch?


More information about the inn-workers mailing list