Re: auth_vpopmail_sql

2005-04-01 Thread John Peacock
Christopher Heschong wrote:
Hi Jeff, I wrote a plugin that I posted to this list a while back that 
will authenticate to the local IMAP server, so if you already have IMAP 
or POP3 setup on your server with whatever backend authentication 
mechanisms you might need (vpopmail, etc), you don't have to worry about 
a second authentication method or different way of accessing them.  
The one caveat being that your implementation only supports cleartext methods 
like auth-plain (and auth-login if you added it).  Because you need the 
cleartext password to perform the backend authentication, there is no way to 
support auth-cram-md5.  That may be an acceptable limitation for some sites, but 
doesn't lend itself to a generalized solution.

John


Switching to latest SVN version

2005-04-01 Thread Robin Bowes
Hi,

I'm currently looking at switching over to the latest SVN version (402)
from an older CVS version of qpsmtpd (0.28 or 0.29 - not sure as 0.29 is
listed in the Changes file, but qpsmtpd reports 0.28 when I telnet to port
25).

I'm aware that the logging has changed - I'd like to setup adaptive
logging - and I use clamav.

Are there any particular gotchas I should look out for?

Contents of config and plugin dirs attached.

R.
-- 
http://robinbowes.com

qpsmtpd-config.tar.gz
Description: application/gzip-compressed


Re: Switching to latest SVN version

2005-04-01 Thread John Peacock
Robin Bowes wrote:
I'm aware that the logging has changed - I'd like to setup adaptive
logging - and I use clamav.
Here's my upgrade procedure (somewhat simplified):
1) Remove the softlink'd directory:
  $ rm /service/qpsmtpd
which means only that supervise won't restart the service; the existing 
service will continue running from the original directory.

2) Rename the old service directory:
  $ mv /var/qmail/service/qpsmtpd /var/qmail/service/qpsmtpd.old
which will also not affect the already running process (since the 
directory name is actually a property of the parent directory).

3) Checkout the new code into a new directory
  $ svn co svn://blah/blah/qpsmtpd/trunk /var/qmail/service/qpsmtpd
4) Copy the configuration file and any custom plugins from the old 
directory and then test on a high port; I usually do this:

  $ perl -T ./qpsmtpd-forkserver --user qmaild
which will start up on port 2525 with an unpriveleged user and log to 
the console.  Remember to create the spool directory with appropriate 
ownership and rights.

5) If all testing works (and I usually send virus-laden messages for 
good measure), then link the new service directory in:

  $ ln -s /var/qmail/service/qpsmtpd /service
which won't actually start the new service, since the old service is 
still squatting on port 25.

6) Lastly, stop the old service:
  $ cd /var/qmail/service/qpsmtpd.old
  $ svc -dx . ./log
Are there any particular gotchas I should look out for?
The things to test are the spool directory rights (depending on whether 
you use clamdscan or clamscan); make sure the multilog directory is set 
up correctly (I ./run it manually first, to make sure that the ownership 
and directories are correct); make sure the logging plugin is what you want.

For the last, the config.sample/logging only has the compatibility 
plugin shown (logging/warn).  I'm in the midst of rolling out the following:

  logging/adaptive accept LOGERROR reject LOGDEBUG prefix !
and I'm going to use multilog's filtering to store the good mail 
(without a !) in seperate log files from the bad mail (guess).

HTH
John


Re: Switching to latest SVN version

2005-04-01 Thread Robin Bowes

On Fri, April 1, 2005 15:46, John Peacock said:
 Robin Bowes wrote:

 I'm aware that the logging has changed - I'd like to setup adaptive
 logging - and I use clamav.

 Here's my upgrade procedure (somewhat simplified):

John,

Thanks, I'll give it a shot over the weekend.

R.
-- 
http://robinbowes.com



Re: auth_vpopmail_sql

2005-04-01 Thread Christopher Heschong
You are certainly correct, it was written for my own personal use.  On 
my system, I use vmailmgr which stores its passwd info in cdb files 
owned by the user in their home dir... no way for a non-root process to 
read them that I can think of.  I think that is why Jeff asked about 
the possibility of using some sort of SSL frontend which would be nice 
to see.

Of course, if anyone else has methods for dealing with vmailmgr 
usernames I'd be happy to hear them.

On Apr 1, 2005, at 6:41 AM, John Peacock wrote:
Christopher Heschong wrote:
Hi Jeff, I wrote a plugin that I posted to this list a while back 
that will authenticate to the local IMAP server, so if you already 
have IMAP or POP3 setup on your server with whatever backend 
authentication mechanisms you might need (vpopmail, etc), you don't 
have to worry about a second authentication method or different way 
of accessing them.
The one caveat being that your implementation only supports cleartext 
methods like auth-plain (and auth-login if you added it).  Because you 
need the cleartext password to perform the backend authentication, 
there is no way to support auth-cram-md5.  That may be an acceptable 
limitation for some sites, but doesn't lend itself to a generalized 
solution.

John


smime.p7s
Description: S/MIME cryptographic signature