Mailing List Archive

> How do you configure qmail to deal with a large number
> of MX'ed hosts. For example if I have a server which is the MX
> for 1000 PC's do I have to have each pc in the rpchosts and locals
> file or is there a mechanism for this kind of stuff?

rcpthosts is a control on outbound mail passing through your machine, i.e.
it controls the use of your machine as a mail relay. so, unless i
misunderstand your question, rcpthosts has nothing to do with it, unless
all of those hosts you're the MX for will also be using you as a smarthost
for their outgoing mail. in that case (unless you want to open up and
not have a rcpthosts file at all) you'll want to cause RELAYCLIENT to
be set for those machines, using one of the methods in the FAQ.

as for locals, are you the final destination for these PCs? or are you
forwarding for them, as a secondary MX?

paul
---------------------
paul fox, pgf@foxharp.boston.ma.us (arlington, ma)
'91 VX800, DoD #1462, AMA #545601

Paul Fox <pgf@foxharp.boston.ma.us> writes:
>
> > How do you configure qmail to deal with a large number
> > of MX'ed hosts. For example if I have a server which is the MX
> > for 1000 PC's do I have to have each pc in the rpchosts and locals
> > file or is there a mechanism for this kind of stuff?
>
>rcpthosts is a control on outbound mail passing through your machine, i.e.
>it controls the use of your machine as a mail relay. so, unless i
>misunderstand your question, rcpthosts has nothing to do with it, unless
>all of those hosts you're the MX for will also be using you as a smarthost
>for their outgoing mail.
>

Er...that's not true, Paul. The rcpthosts file controls which domains
the smtp daemon will *receive* mail for. It doesn't matter whether that
mail is forwarded elsewhere or placed into local mailboxes or maildirs.

The answer to the question is:

It depends on which addresses will appear on incoming mail.
If the users on those 1,000 PCs will use return addresses
with the individual PC names (e.g. user@pcname.domain.com),
then all those hostnames will need to be in the rcpthosts
file. If the users don't have the hostnames in their return
addresses (e.g. user@domain.com), then just the domain name
will be sufficient.

The key is: Learn (or dictate) the format of the return addresses
the users will have in their outgoing messages. Set the rcpthosts
file appropriately.

As you mentioned, Paul, modifying the RELAYCLIENT environment variable
is necessary if those PCs use the qmail machine as the outgoing mail
relay.

-Greg
--
Greg Andrews West Coast Online
Unix System Administrator 5800 Redwood Drive
gerg@wco.com Rohnert Park CA 94928
(yes, 'greg' backwards) 1-800-WCO-INTERNET

> Er...that's not true, Paul. The rcpthosts file controls which domains
> the smtp daemon will *receive* mail for. It doesn't matter whether that
> mail is forwarded elsewhere or placed into local mailboxes or maildirs.
oops. you're right, of course. i was describing what i wish, rather
than what is. :-) what i wish is that virtualdomains, locals, rcpthosts
were all non-overlapping, and that rcpthosts were the set of _additional_
domains for which we will accept mail. but that's not the way it works.

paul
---------------------
paul fox, pgf@foxharp.boston.ma.us (arlington, ma)

On Feb 12, 13:15, Greg Andrews wrote:
> The key is: Learn (or dictate) the format of the return addresses
> the users will have in their outgoing messages. Set the rcpthosts
> file appropriately.
>
> As you mentioned, Paul, modifying the RELAYCLIENT environment variable
> is necessary if those PCs use the qmail machine as the outgoing mail
> relay.

Hmm. I guess I can set RELAYCLIENT to the massaged output of dig for
all machines in my domain. That way if the MX record points to "me"
then I set RELAYCLIENT to it and let it be, else it gets set to the
real MX and bounces.

I guess I can live with that. Though it would be darn nice if qmail
could do a host lookup and see if the target is MX'ed to "me" and then
not worry if rcpthosts contains it. There is little point in making
two changes when you can make only one in the host table. After all,
from what I see, qmail does understand MX records so I don't see why
it needs local confirmation of the info.

Vlad


--
Vladimir Gabrielescu NBCS System Programmer 1-908-445-4785
vgabriel@toolbox.rutgers.edu http://nbcs.rutgers.edu/~vgabriel/
Someone should have labeled the future 'some assembly required'

On Wed, 12 Feb 1997, Vladimir Gabrielescu wrote:

> I guess I can live with that. Though it would be darn nice if qmail
> could do a host lookup and see if the target is MX'ed to "me" and then
> not worry if rcpthosts contains it. There is little point in making
> two changes when you can make only one in the host table. After all,
> from what I see, qmail does understand MX records so I don't see why
> it needs local confirmation of the info.

Because everyone can set up a MX pointing to you..

Regards,
Armin

--
Armin Gruner

Muc.DE e.V. Tel./Fax: 089 / 3243695
Frankfurter Ring 193a mailto:systems@muc.de
80807 Muenchen WWW: http://www.muc.de/

On Feb 13, 0:04, Armin Gruner wrote:

> Because everyone can set up a MX pointing to you..
>

Well not really. What I meant was that I would do that hack for all
the machines in my domain (rutgers.edu). We control our name servers
and host tables so I can be pretty sure if foo.rutgers.edu is MX'ed
to "me" that that's that way it should be. I suppose I will use the
our two class B's by yp address rather then *.rutgers.edu for the sake
of name spoofing.

Vlad



--
Vladimir Gabrielescu NBCS System Programmer 1-908-445-4785
vgabriel@toolbox.rutgers.edu http://nbcs.rutgers.edu/~vgabriel/
Someone should have labeled the future 'some assembly required'

> Well not really. What I meant was that I would do that hack for all
> the machines in my domain (rutgers.edu). We control our name servers
> and host tables so I can be pretty sure if foo.rutgers.edu is MX'ed
> to "me" that that's that way it should be. I suppose I will use the
> our two class B's by yp address rather then *.rutgers.edu for the sake
> of name spoofing.
>
> Vlad

Yes, really. If I controlled a spammer like moneyworld.com, then I point
all the mail for "hostile-replies.moneyworld.com" to lochaber.rutgers.edu,
then you get to take it *all*.

Capiche?

-Peter

On Feb 12, 18:20, Peter C. Norton wrote:
> Yes, really. If I controlled a spammer like moneyworld.com, then I point
> all the mail for "hostile-replies.moneyworld.com" to lochaber.rutgers.edu,
> then you get to take it *all*.

Right, I understand that. However I wouldn't do the hack for
"hostile-replies.moneyworld.com". The hack would only take place if the
mail is directed to host in my domain. For example if foo.moneyworld.com
is MX'ed to lochaber.rutgers.edu I will quietly drop the mail. However if
foo.rutgers.edu is MX'ed to lochaber in the host table then I will take
that at face value. I know this is a bit confusing.

Vlad


--
Vladimir Gabrielescu NBCS System Programmer 1-908-445-4785
vgabriel@toolbox.rutgers.edu http://nbcs.rutgers.edu/~vgabriel/
Someone should have labeled the future 'some assembly required'

Er...that's not true, Paul. The rcpthosts file controls which domains
the smtp daemon will *receive* mail for. It doesn't matter whether that
mail is forwarded elsewhere or placed into local mailboxes or maildirs.

This sounds consistent with the "official" description of
rcpthosts. But then why can't I send a message to remote hosts (ie,
not in rcpthosts) as long as I have rcpthosts? This is under Linux.

Thx
Mate

M\'at\'e Wierdl Department of Mathematical Sciences
mw@moni.msci.memphis.edu University of Memphis

>
> Er...that's not true, Paul. The rcpthosts file controls which domains
> the smtp daemon will *receive* mail for. It doesn't matter whether that
> mail is forwarded elsewhere or placed into local mailboxes or maildirs.
>
> This sounds consistent with the "official" description of
> rcpthosts. But then why can't I send a message to remote hosts (ie,
> not in rcpthosts) as long as I have rcpthosts? This is under Linux.
>

are you using an MUA (like mh) which connects to your own SMTP port
to send outgoing mail, rather than invoking sendmail the "normal" way?

paul
---------------------
paul fox, pgf@foxharp.boston.ma.us (arlington, ma)

On Wed, 12 Feb 1997, Vladimir Gabrielescu wrote:
> On Feb 12, 18:20, Peter C. Norton wrote:
> > Yes, really. If I controlled a spammer like moneyworld.com, then I point
> > all the mail for "hostile-replies.moneyworld.com" to lochaber.rutgers.edu,
> > then you get to take it *all*.
> Right, I understand that. However I wouldn't do the hack for
> "hostile-replies.moneyworld.com". The hack would only take place if the
> mail is directed to host in my domain. For example if foo.moneyworld.com
> is MX'ed to lochaber.rutgers.edu I will quietly drop the mail. However if
> foo.rutgers.edu is MX'ed to lochaber in the host table then I will take
> that at face value. I know this is a bit confusing.

That hack would be have to be interesting. What if instead of just
MX'ing, they decided to CNAME hated-jerks.moneyworld.com to
lochaber.rutgers.edu? Such a hack would have to discount CNAME's that
originated outside of rutgers.ed, but still allow CNAMES that come from
domains that are controlled by rutgers staff or students.

-Peter

"Vladimir Gabrielescu" <vgabriel@lochaber.rutgers.edu> writes:
>On Feb 12, 13:15, Greg Andrews wrote:
>> The key is: Learn (or dictate) the format of the return addresses
>> the users will have in their outgoing messages. Set the rcpthosts
>> file appropriately.
>>
>> As you mentioned, Paul, modifying the RELAYCLIENT environment variable
>> is necessary if those PCs use the qmail machine as the outgoing mail
>> relay.
>
>Hmm. I guess I can set RELAYCLIENT to the massaged output of dig for
>all machines in my domain. That way if the MX record points to "me"
>then I set RELAYCLIENT to it and let it be, else it gets set to the
>real MX and bounces.
>

No, you run tcp wrappers or Dan's tcpserver. When it recognizes a
connection from a list of IP addresses you've created, it sets the
*environment variable* RELAYCLIENT to null. That makes qmail-smtpd
ignore the rcpthosts file.

Under those conditions, those IP addresses will be able to use
your qmail machine to relay mail anywhere. Other IP addresses
will only be able to use your qmail machines to relay to the
domains in your rcpthosts file.

There you have it. Internet sites can't relay mail to other
sites through you. They can only send mail to your local PCs.
Your PCs can conveniently relay mail through you to wherever
they want.

>
>I guess I can live with that. Though it would be darn nice if qmail
>could do a host lookup and see if the target is MX'ed to "me" and then
>not worry if rcpthosts contains it. There is little point in making
>two changes when you can make only one in the host table. After all,
>from what I see, qmail does understand MX records so I don't see why
>it needs local confirmation of the info.
>

As others have pointed out, it's trivial for a malicious site to
point MX, CNAME, or A records to your hosts instead of theirs.

How would qmail get information it can trust in order to filter out
bogus DNS records like that? Should it read a config file on the
local host? Bingo! There's the rcpthosts file. And there's no
need for the DNS code to read the file when it's simpler for the
SMTP daemon to do it.

-Greg
--
Greg Andrews West Coast Online
Unix System Administrator 5800 Redwood Drive
gerg@wco.com Rohnert Park CA 94928
(yes, 'greg' backwards) 1-800-WCO-INTERNET

Mate Wierdl <mw@wierdlmpc.msci.memphis.edu> writes:
>
> Er...that's not true, Paul. The rcpthosts file controls which domains
> the smtp daemon will *receive* mail for. It doesn't matter whether that
> mail is forwarded elsewhere or placed into local mailboxes or maildirs.
>
>This sounds consistent with the "official" description of
>rcpthosts. But then why can't I send a message to remote hosts (ie,
>not in rcpthosts) as long as I have rcpthosts? This is under Linux.
>

Of course you can do that. You simply can't do it via SMTP.
(you can via the sendmail replacement or qmail-inject).

If you need to give certain machines the ability to do it
via SMTP, see FAQ entry 3.4.

-Greg
--
Greg Andrews West Coast Online
Unix System Administrator 5800 Redwood Drive
gerg@wco.com Rohnert Park CA 94928
(yes, 'greg' backwards) 1-800-WCO-INTERNET

On Feb 12, 16:49, Greg Andrews wrote:
> How would qmail get information it can trust in order to filter out
> bogus DNS records like that? Should it read a config file on the
> local host? Bingo! There's the rcpthosts file. And there's no
> need for the DNS code to read the file when it's simpler for the
> SMTP daemon to do it.

That is a simple and elegant solution when you have a realtivly simple
network. In my case I have over 1k pc's and macs MX'ed to somthing or
other and there are always more being added. There are two problems with
qmail in that case

a) Who wants to type over 1000 entries in a file?
b) How do I maintain it current when I don't necesarly control
when and where the pc's are being installed and configured (diff.
group does that)

If rcpthosts would at least support netgroups ... Even that would be
better then just a list. The list just doesnt scale.

Vlad

--
Vladimir Gabrielescu NBCS System Programmer 1-908-445-4785
vgabriel@toolbox.rutgers.edu http://nbcs.rutgers.edu/~vgabriel/
Someone should have labeled the future 'some assembly required'

At 09:19 AM 2/13/97 -0500, you wrote:
>On Feb 12, 16:49, Greg Andrews wrote:
>> How would qmail get information it can trust in order to filter out
>> bogus DNS records like that? Should it read a config file on the
>> local host? Bingo! There's the rcpthosts file. And there's no
>> need for the DNS code to read the file when it's simpler for the
>> SMTP daemon to do it.
>
>That is a simple and elegant solution when you have a realtivly simple
>network.

Yes, they are nice, aren't they :)

>In my case I have over 1k pc's and macs MX'ed to somthing or
>other and there are always more being added. There are two problems with
>qmail in that case
>
>a) Who wants to type over 1000 entries in a file?

No one, agreed, although I imagine it wouldn't be to hard to write up
something to do a zone transfer for your domain, and add the appropriate
MX records to rpcthosts. [Unix related rant at end...]

>b) How do I maintain it current when I don't necesarly control
>when and where the pc's are being installed and configured (diff.
>group does that)

Well, if answer to point A is acceptable, you could even put it as a
cron job :)

>If rcpthosts would at least support netgroups ... Even that would be
>better then just a list. The list just doesnt scale.

Agreed, but I think if putting in the library calls to lookup the QMAIL
daemon usernames is said to bloat the code, I'd imagine that this would
be as bad, if not worse.

***

Unix rant: I really wish, in a shell script (I'm using bash), an application
such as nslookup would take it's input from the script when called, so that

#/bin/sh
nslookup
ls -t MX switch.com > mx.out
exit
#process mx.out as required, etc.

would work. Or, am I missing something...

Of course, I just played around and found named-xfer, so

#!/bin/sh
PATH=$PATH:/usr/libexec
DOMAIN=your.domain
DOMAINSERVER=server.your.domain
QMAILHOST=your.qmail.host
#
#named-xfer -z $DOMAIN -f zone.out $DOMAINSERVER
grep MX.*$QMAILHOST zone.out | awk -F' ' '{ print $1 }'

Seems to be a reasonable method...
-------------------------
John C. Ring, Jr.
jcring@switch.com
Network Specialist
Union Switch & Signal Inc.

John C. Ring, Jr. writes:
>Unix rant: I really wish, in a shell script (I'm using bash), an application
>such as nslookup would take it's input from the script when called, so that
>
>#/bin/sh
>nslookup
>ls -t MX switch.com > mx.out
>exit
>#process mx.out as required, etc.
>
>would work. Or, am I missing something...

Did you try either of these?

echo "ls -t MX switch.com > mx.out" | nslookup
or
nslookup <<!
ls -t MX switch.com > mx.out
exit
!

--
Eric Krohn

> named-xfer -z $DOMAIN -f zone.out $DOMAINSERVER

you should find a copy of "dig", which does everything nslookup
does, and sticks a little closer to the protocol, making it clearer
what's going on, imho. your example would be written:

dig @$DOMAINSERVER $DOMAIN axfr > zone.out

paul
---------------------
paul fox, pgf@foxharp.boston.ma.us (arlington, ma)

Vladimir Gabrielescu <vgabriel@lochaber.rutgers.edu> writes:
>On Feb 12, 16:49, Greg Andrews wrote:
>> How would qmail get information it can trust in order to filter out
>> bogus DNS records like that? Should it read a config file on the
>> local host? Bingo! There's the rcpthosts file. And there's no
>> need for the DNS code to read the file when it's simpler for the
>> SMTP daemon to do it.
>
>That is a simple and elegant solution when you have a realtivly simple
>network. In my case I have over 1k pc's and macs MX'ed to somthing or
>other and there are always more being added.
>

That's very similar to my setup. My company (wco.com) is an ISP
serving just over 1000 virtual domains for our customers. We add
or delete a couple domains every few days. All the domains are
MXed to a single qmail machine, and the qmail machine forwards
the messages to a variety of other machines, both on our internal
network and on other parts of the Internet.

I speak from experience. It works.

>
>There are two problems with qmail in that case
>
>a) Who wants to type over 1000 entries in a file?
>

I wrote perl scripts to create and maintain the entries in my
control/rcpthosts, control/virtualdomains, and users/append
files (as well as the 5000 .qmail files that control the
message forwarding).

>
>b) How do I maintain it current when I don't necesarly control
>when and where the pc's are being installed and configured (diff.
>group does that)
>

Who does the DNS? If your department adds or deletes the DNS entries
for these PCs, then you already have sufficient control. Add the
entries to the qmail files as part of the procedure to add MX records.

If the DNS for different departments or networks is delegated to
their own machines, yet you have to maintain a single mail host
to catch all the mail, then it's a somewhat tougher problem.
It's still not insurmountable. See my next response, below.

>
>If rcpthosts would at least support netgroups ... Even that would be
>better then just a list. The list just doesnt scale.
>

Have you looked at the description of how rcpthosts is used (in the
qmail-smtpd man page)? It supports wildcards.

All of these PCs have names within the rutgers.edu domain (or some
subdomain(s) of rutgers.edu), right? An rcpthosts entry like this:

.rutgers.edu

will accept mail for any subdomains under rutgers.edu (even multiple
ones like "user@hostname.department.rutgers.edu"). Alternatively,
you can list the particular subdomains that your mail machine will
be handling, so others will be refused:

.compsci.rutgers.edu
.law.rutgers.edu
.finearts.rutgers.edu

As far as I can tell from the descriptions of your network, using
wildcards will reduce the entries in your rcpthosts file down to a
manageable number.


That would seem to take care of accepting messages onto your qmail
machine. The next hurdle is forwarding them. Do you need to forward
mail to all of these PCs? Do you need to deliver the messages into
local mailboxes (to be picked up via POP3)? Both?

-Greg
--
Greg Andrews West Coast Online
Unix System Administrator 5800 Redwood Drive
gerg@wco.com Rohnert Park CA 94928
(yes, 'greg' backwards) 1-800-WCO-INTERNET

On Feb 13, 13:37, Greg Andrews wrote:
[snip]
> Have you looked at the description of how rcpthosts is used (in the
> qmail-smtpd man page)? It supports wildcards.
>
> All of these PCs have names within the rutgers.edu domain (or some
> subdomain(s) of rutgers.edu), right? An rcpthosts entry like this:
>
> .rutgers.edu
>
> will accept mail for any subdomains under rutgers.edu (even multiple
> ones like "user@hostname.department.rutgers.edu"). Alternatively,
> you can list the particular subdomains that your mail machine will
> be handling, so others will be refused:


Hmm. Does it support wildcards in IP addresses? If so then I can
live with it. Most of these PC's are grouped in large subnets.

> That would seem to take care of accepting messages onto your qmail
> machine. The next hurdle is forwarding them. Do you need to forward
> mail to all of these PCs? Do you need to deliver the messages into
> local mailboxes (to be picked up via POP3)? Both?

I'm not worried about that. The PC's are not supposed to recive any mail
and rearly do we get any for them but when we do we need to be able to
catch it.

For now I came up with a command line with about 8 pipes and built around
dig that maintains the files. I can also live with this option.

Also ... Why do I need both "foo" and "foo.domain" in these files?
Is there anyway to only keep one?

Vlad


--
Vladimir Gabrielescu NBCS System Programmer 1-908-445-4785
vgabriel@toolbox.rutgers.edu http://nbcs.rutgers.edu/~vgabriel/
Someone should have labeled the future 'some assembly required'

Vladimir Gabrielescu <vgabriel@lochaber.rutgers.edu>
>On Feb 13, 13:37, Greg Andrews wrote:
>>
>> Have you looked at the description of how rcpthosts is used (in the
>> qmail-smtpd man page)? It supports wildcards.
>>
>
>Hmm. Does it support wildcards in IP addresses? If so then I can
>live with it. Most of these PC's are grouped in large subnets.
>

Why have you suddenly switched to talking about IP addresses?
The rcpthosts file is matched against the message's recipient
address. Are you trying to say you'll receive mail addressed
to IP numbers (vgabriel@[128.6.134.25]) instead of host/domain
names (vgabriel@lochaber.rutgers.edu)??

If these PCs are grouped into subnets, aren't their hostnames
also grouped into subdomains?

>
>Also ... Why do I need both "foo" and "foo.domain" in these files?
>Is there anyway to only keep one?
>

Earlier in this thread I said:

The answer to the question is:

It depends on which addresses will appear on incoming mail.


If you don't anticipate receiving messages addressed to "foo" or
"foo.domain", then they don't need to be in rcpthosts.

HOWEVER,

Think carefully. Remember that bounce messages return to the
address in the envelope, not the message headers. When qmail
performs rewriting on an incomplete sender address, it might
attach "foo.domain". When the bounce comes back to that address,
it'll be dropped if "foo.domain" isn't in rcpthosts.

My advice would be to keep "foo" and "foo.domain" in rcpthosts
for a month or two and see from the log if any mail comes in for
those names. If none, yank them from rcpthosts. If some, then
find out why and keep them if there are good reasons (or correct
the errors if the reasons are bad).

-Greg
--
Greg Andrews West Coast Online
Unix System Administrator 5800 Redwood Drive
gerg@wco.com Rohnert Park CA 94928
(yes, 'greg' backwards) 1-800-WCO-INTERNET

On Feb 13, 14:50, Greg Andrews wrote:
> Why have you suddenly switched to talking about IP addresses?
> The rcpthosts file is matched against the message's recipient
> address. Are you trying to say you'll receive mail addressed
> to IP numbers (vgabriel@[128.6.134.25]) instead of host/domain
> names (vgabriel@lochaber.rutgers.edu)??

Silly me, to assume that a reverse lookup may be done. From where
I stand the right thing to do is be able to list only one address
and qmail to figure out the rest of the possible permutations.

> If these PCs are grouped into subnets, aren't their hostnames
> also grouped into subdomains?

I'm sorry but what does one have to do with the other? No they
are not subdomained for admistrative reasons.

> If you don't anticipate receiving messages addressed to "foo" or
> "foo.domain", then they don't need to be in rcpthosts.

Well, meaning no offence to the author, I personaly think that is
the wrong thing to do. I understand the design goals of simplicity
and "smallness" but there is a fine line between that and making it
to simple. I mean how many people still use ed? It's small and simple
but ... However I think that qmail has a couple of great features and
I will most likely recommned it as a serious contender to sendmail.

Vlad

--
Vladimir Gabrielescu NBCS System Programmer 1-908-445-4785
vgabriel@toolbox.rutgers.edu http://nbcs.rutgers.edu/~vgabriel/
Someone should have labeled the future 'some assembly required'

Vladimir Gabrielescu <vgabriel@lochaber.rutgers.edu> writes:
>On Feb 13, 14:50, Greg Andrews wrote:
>> Why have you suddenly switched to talking about IP addresses?
>> The rcpthosts file is matched against the message's recipient
>> address. Are you trying to say you'll receive mail addressed
>> to IP numbers (vgabriel@[128.6.134.25]) instead of host/domain
>> names (vgabriel@lochaber.rutgers.edu)??
>
>Silly me, to assume that a reverse lookup may be done. From where
>I stand the right thing to do is be able to list only one address
>and qmail to figure out the rest of the possible permutations.
>

What was wrong with the wildcard entry I suggested before? Isn't
that "listing one address"?

I've been talking about the rcpthosts file here. Are you now asking
about a different control file? The reason I ask this is I simply
don't understand your response. I explained that the domains in the
rcpthosts file are matched (compared) against the recipient address
of each incoming message. They are simple string comparisons.

If you're going to receive e-mail with the IP address after the '@',
then by all means put the machine's IP address in rcpthosts.
That is quite rare, though.

In the vast majority of cases, the address on a piece of e-mail
will have a domain name after the '@'. The SMTP daemon doesn't
need to do a bunch of PTR lookups when a simple string comparison
will do. Besides, when would the smtp daemon do these 1000 PTR
lookups? When it starts up? Remember that a new qmail-smtpd is
invoked from inet (or tcpserver) for each connection. That would
mean many redundant DNS lookups per hour (or per minute, or even
per second). What's far more efficient is one program that does
one set of PTR lookups, and stores the results in a file for the
smtp daemon to read.

The file is, of course, rcpthosts. The program could be a shell
or perl script that runs as often as is reasonable. Once per day
to minimize the DNS traffic, once per hour to quickly pick up new
machines from DNS, or any increment in between.


>> If these PCs are grouped into subnets, aren't their hostnames
>> also grouped into subdomains?
>
>I'm sorry but what does one have to do with the other? No they
>are not subdomained for admistrative reasons.
>

Subnets and subdomains don't have to have anything to do with each
other, but many organizations do split their hosts into subdomains
that match the subnets. I was just asking for a little more info
on how your network is designed, so I can offer suggestions that
are more likely to work for you.

>> If you don't anticipate receiving messages addressed to "foo" or
>> "foo.domain", then they don't need to be in rcpthosts.
>
>Well, meaning no offence to the author, I personaly think that is
>the wrong thing to do. I understand the design goals of simplicity
>and "smallness" but there is a fine line between that and making it
>to simple. I mean how many people still use ed? It's small and simple
>but ... However I think that qmail has a couple of great features and
>I will most likely recommned it as a serious contender to sendmail.
>

On the other hand, with EMACS available, why do some people still
use vi? Because sometimes the optimal tool for the job is a fast,
efficient one.

It does sound like qmail doesn't come out of the box meeting 100%
of your requirements. I had the same situation. It only met about
85% of mine. However, I filled in the remaining 15% by writing my
perl scripts and changing my department's procedures slightly.

As far as I've been able to tell from this discussion, it would be
the same for you.

-Greg
--
Greg Andrews West Coast Online
Unix System Administrator 5800 Redwood Drive
gerg@wco.com Rohnert Park CA 94928
(yes, 'greg' backwards) 1-800-WCO-INTERNET

> If you're going to receive e-mail with the IP address after the '@',
> then by all means put the machine's IP address in rcpthosts.

This is unnecessary. qmail-smtpd automatically checks for local IP
addresses and changes them into control/localiphost, default control/me.

---Dan
Put an end to unauthorized mail relaying. http://pobox.com/~djb/qmail.html