OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Postfix Archives: Re: pop-before-smtp revisited

Re: pop-before-smtp revisited

Subject: Re: pop-before-smtp revisited
From: Harry Palmer (hpalmerjerky.net)
Date: Wed Jan 05 2000 - 11:58:55 CST

>
> 2000-01-04-17:29:24 Wietse Venema:
> > One question: how much would it take to have a POP daemon update
> > an access DB file upon login, and to have a mine sweeper cron job
> > that iterates over the file and that kills old entries every 30
> > minutes or so? The disadvantage is that having multiple writers
> > requires locking.
>
> What would be the advantage of that approach over my daemon? I enjoy
> single-writer on my db file, and use with unmodifed UW pop3d/imapd (and of
> course unmodified Postfix). File::Tail backed by a couple of quick regex
> matches to toss uninteresting lines doesn't seem to thagomize the CPU, even on
> a pretty lively maillog. It can catch up with about 18MB of log (a couple of
> days worth) in a dozen seconds or two, and once it's caught up it settles
> right down and eats no CPU to speak of at all --- and that's with options
> tuned to make it follow the logfile hot-n-fast, so people will see their auth
> very shortly after their pop.
>
> > One comment: Postfix maps use file names like `foo' rather than
> > `foo.db' for the simple reason that Postfix also needs to support
> > DBM databases, which have the nasty property that they come in
> > pairs. Suggestions to eliminate the implicit suffix logic are
> > welcome.
>
> I don't know whether it's worth bothering with; it sure didn't take long for
> me to figure out the problem --- just peeked at maillog after the reload,
> which I've come to regard as mandatory whenever I edit main.cf. I've seen the
> convention elsewhere, and it fits nicely with the expectation that there might
> be a txt file that produces the db file, probably true for most uses of db
> files with MTAs.
>

Using the mysql patch for Postfix and a quick little alteration of
popa3d (Solar Designer?) can create a much faster, better scaling, POP
before SMTP solution. The modification to the POP daemon is trivial.
Simply add your INSERT query to some POP logging table. Then you add a
mysql access map in postfix and SMTP will automagically be available for
users the instant they authenticate with POP. No lame text files or log
files to parse through, and it makes adding multiple POP and SMTP
servers much easier than the design you have. For example, with your
tailing the log file "solution", its a pain in the ass to setup say 20
POP servers and 20 SMTP servers all working together in harmony to
handle end user requests. The best way I could think of is to have all
your POP servers log to a logging host, then have the log file be
network mounted so that the SMTP machines can access that stuff in real
time. With the DB access list and the slightly modified POPD there are
no ugly hacks, and you can simply add in the servers as many or as few
as you like. This also reduces support headaches because all
the machines are identical. Naturally with this scheme the limit of
your scalability in the power of your database server, but with
database clustering solutions and Oracle running on badass hardware, it
shouldn't be an issue for a very long time.

This archive was generated by hypermail 2b27 : Wed Jan 05 2000 - 11:58:55 CST