From: john on
I want to create a separate outbound relay cluster to offload some
load from my main mail server.

My smtp relay security is by way of a pop-before-smtp setup. On the
original mail server, apop3d daemon generates the popauth hash map,
and also does some magic that tells sendmail to reread the map when it
was changed.

On my relay cluster, I am scp'ing the popauth files over to the over
servers. This works, but.... I have to restart sendmail everytime the
popauth data changes.

Is there any way around this? How can you tell sendmail to reread the
map file without actually having to restart sendmail? apop3d must have
a way to do this, but I dont know it works.
From: ska on
john(a)essenz.com wrote:

> original mail server, apop3d daemon generates the popauth hash map,
> and also does some magic that tells sendmail to reread the map when it
> was changed.
>
> On my relay cluster, I am scp'ing the popauth files over to the over
> servers. This works, but.... I have to restart sendmail everytime the
> popauth data changes.
>
> Is there any way around this? How can you tell sendmail to reread the
> map file without actually having to restart sendmail? apop3d must have
> a way to do this, but I dont know it works.

Well, you say popauth "hash map". If it really is a hash map (aka some
binary format usually created with the "makemap" command), sendmail is
to detect its change automatically.

Otherwise is "/etc/init.d/sendmail reload" should work.

http://www.sendmail.org/~ca/email/roaming.html
contains a perl script to make a popauth database, the last and final
command is the "makemap" command, if you use the similiar approach in
sendmail (aka the rulesets), no further action is needed.

ska
From: John Von Essen on
On Oct 9, 3:45 am, ska <s...(a)mail.inf.fh-brs.de> wrote:
> j...(a)essenz.com wrote:
> > original mail server, apop3d daemon generates the popauth hash map,
> > and also does some magic that tells sendmail to reread the map when it
> > was changed.
>
> > On my relay cluster, I am scp'ing the popauth files over to the over
> > servers. This works, but.... I have to restart sendmail everytime the
> > popauth data changes.
>
> > Is there any way around this? How can you tell sendmail to reread the
> > map file without actually having to restart sendmail? apop3d must have
> > a way to do this, but I dont know it works.
>
> Well, you say popauth "hash map". If it really is a hash map (aka some
> binary format usually created with the "makemap" command), sendmail is
> to detect its change automatically.
>
> Otherwise is "/etc/init.d/sendmail reload" should work.
>
> http://www.sendmail.org/~ca/email/roaming.html
> contains a perl script to make a popauth database, the last and final
> command is the "makemap" command, if you use the similiar approach in
> sendmail (aka the rulesets), no further action is needed.
>
> ska

Thats what I thought. But I did a test where I removed an entry, and
sendmail still had the old value cached. I'll try testing it again,
maybe I just made a mistake. But even things like virtusertable maps,
I always have to reload sendmail to make those changes take effect.
The problem with the popauth map is it changes every minute, so I dont
really want to reload sendmail every 60 seconds.
From: Johann Klasek - swap last two domainparts on
John Von Essen <john(a)essenz.com> wrote:
> On Oct 9, 3:45�am, ska <s...(a)mail.inf.fh-brs.de> wrote:
> > j...(a)essenz.com wrote:
[..]
> > > On my relay cluster, I am scp'ing the popauth files over to the over
> > > servers. This works, but.... I have to restart sendmail everytime the
> > > popauth data changes.
> >
> > > Is there any way around this? How can you tell sendmail to reread the
> > > map file without actually having to restart sendmail? apop3d must have
> > > a way to do this, but I dont know it works.
> >
[..]
> > Otherwise is "/etc/init.d/sendmail reload" should work.
> >
> > http://www.sendmail.org/~ca/email/roaming.html
> > contains a perl script to make a popauth database, the last and final
> > command is the "makemap" command, if you use the similiar approach in
> > sendmail (aka the rulesets), no further action is needed.
>
> Thats what I thought. But I did a test where I removed an entry, and
> sendmail still had the old value cached. I'll try testing it again,
> maybe I just made a mistake. But even things like virtusertable maps,
> I always have to reload sendmail to make those changes take effect.
> The problem with the popauth map is it changes every minute, so I dont
> really want to reload sendmail every 60 seconds.

I'm watching this behavior in slightly other situation: my sendmail uses
a big map DB (some kind of virtusertable) with routing information (hash
DB with 10MB). To build it up I am using shadow map which is put into
place (using mv) after finished the map generation (may take some time
and I want to prevent sendmail either to access an uncomplete map DB or
to wait for the completition of rebuild.

This works excellent, only in rare cases some long running sendmail
process spawned from the acceptor keeps running with some old version of
the map. But this process terminates soon or later.

More problems seem to occur with the queue runner process. I've
configured a persistent queue runner. This kind of sendmail process
seems not to reopen DB maps on a regular basis. The only way to get the
current map notified is to SIGHUP the sendmail main process (acceptor)
which in turn restarts the queue runner.

Some questions arises:

* Do I have to avoid a persistent queue runner at all?

* Is it possible to force the queue runner to reopen a DB
in some interval (did noticed a map flag so far).

* aliases.db seems not to have this problem: it is not open in a the
persistent queue runner process (according to lsof). Either it is
never opened or sendmail closes it after usage? Don't know, but if
the latter is true, how can I adopt the alias.db bahavior for may own
routing DB?

Another approach would be to still use the shadow scheme, but running a
makemap into the old (removed) DB file while the new DB file is already
in place. After this is finished I move it back. The queue runner still
operates on the old DB file which has been rebuilt - some delay is not
that critical. An acceptor process has got first a new generated DB and
shortly later the rebuilt old DB file again. How about that?

Any help appreciated,
Johann

--
Johann E. Klasek Zentraler Informatikdienst - Kommunikation
Technische Universit�t Wien Tel: +43 1 58801-42049
A-1040 Wien, Wiedner Hauptstr. 8-10/020C Fax: +43 1 58801-42099
http://pgpkeys.tuwien.ac.at/ PGP Key jklasek
From: Andrzej Adam Filip on
"Johann Klasek - swap last two domainparts" <klasek+usenet(a)zid.tuwien.at.ac> wrote:
> John Von Essen <john(a)essenz.com> wrote:
>> On Oct 9, 3:45 am, ska <s...(a)mail.inf.fh-brs.de> wrote:
>> > j...(a)essenz.com wrote:
> [..]
>> > > On my relay cluster, I am scp'ing the popauth files over to the over
>> > > servers. This works, but.... I have to restart sendmail everytime the
>> > > popauth data changes.
>> >
>> > > Is there any way around this? How can you tell sendmail to reread the
>> > > map file without actually having to restart sendmail? apop3d must have
>> > > a way to do this, but I dont know it works.
>> >
> [..]
>> > Otherwise is "/etc/init.d/sendmail reload" should work.
>> >
>> > http://www.sendmail.org/~ca/email/roaming.html
>> > contains a perl script to make a popauth database, the last and final
>> > command is the "makemap" command, if you use the similiar approach in
>> > sendmail (aka the rulesets), no further action is needed.
>>
>> Thats what I thought. But I did a test where I removed an entry, and
>> sendmail still had the old value cached. I'll try testing it again,
>> maybe I just made a mistake. But even things like virtusertable maps,
>> I always have to reload sendmail to make those changes take effect.
>> The problem with the popauth map is it changes every minute, so I dont
>> really want to reload sendmail every 60 seconds.
>
> I'm watching this behavior in slightly other situation: my sendmail uses
> a big map DB (some kind of virtusertable) with routing information (hash
> DB with 10MB). To build it up I am using shadow map which is put into
> place (using mv) after finished the map generation (may take some time
> and I want to prevent sendmail either to access an uncomplete map DB or
> to wait for the completition of rebuild.
>
> This works excellent, only in rare cases some long running sendmail
> process spawned from the acceptor keeps running with some old version of
> the map. But this process terminates soon or later.
>
> More problems seem to occur with the queue runner process. I've
> configured a persistent queue runner. This kind of sendmail process
> seems not to reopen DB maps on a regular basis. The only way to get the
> current map notified is to SIGHUP the sendmail main process (acceptor)
> which in turn restarts the queue runner.
>
> Some questions arises:
>
> * Do I have to avoid a persistent queue runner at all?
>
> * Is it possible to force the queue runner to reopen a DB
> in some interval (did noticed a map flag so far).
>
> * aliases.db seems not to have this problem: it is not open in a the
> persistent queue runner process (according to lsof). Either it is
> never opened or sendmail closes it after usage? Don't know, but if
> the latter is true, how can I adopt the alias.db bahavior for may own
> routing DB?
>
> Another approach would be to still use the shadow scheme, but running a
> makemap into the old (removed) DB file while the new DB file is already
> in place. After this is finished I move it back. The queue runner still
> operates on the old DB file which has been rebuilt - some delay is not
> that critical. An acceptor process has got first a new generated DB and
> shortly later the rebuilt old DB file again. How about that?
>
> Any help appreciated,
> Johann

Yet another approach may be to create persistent pop-before-smtp daemon
serving the "popauth map" via socket map protocol over unix socket.
It should also eliminate delays between rebuilds.

Sample socket map server is provided in contrib/socketmapServer.pl in
sendmail.org distribution [you may consider using threads instead of
processes (fork)].

--
[pl>en Andrew] Andrzej Adam Filip : anfi(a)onet.eu : Andrzej.Filip(a)gmail.com
"Unlike most net.puritans, however, I feel that what OTHER consenting computers
do in the privacy of their own phone connections is their own business."
-- John Woods, jfw(a)eddie.mit.edu