Elliot F wrote:
My point was that I differentiate between a local address (domains in
qmail's 'locals' file) and any rcpthosts address (domains in
'rcpthosts' file.) The two are not necessarily the same. If I did not
differentiate between local and rcpthost, then I could not
authoritatively deny recipients, because I do not know what users are
valid on domains I am only secondary for. Does that make more
sense?
Yes it does. I can only speak for myself, but I don't have anything in
the locals file except for the machine name (since I run vpopmail for
all domains). I suspect most people are running virtual domains, so I
don't /think/ there is much call for splitting locals from rcpthosts.
YMMV...
However, I have dealt with the non-local addresses in a slightly
different way. Our inbound MX boxes don't have any local accounts and
simply relay the accepted mail on the to the actual server(s). I
validate all e-mail addresses through a custom plugin that has undergone
several iterations:
1) VRFY - sure, this has been disabled on most servers to keep spammers
from performing a dictionary attack, but it is a lightweight way to
check for valid e-mails. My plugin actually limited the command based
on IP, so I could safely use this with a publically accessible server.
2) FINGER - my current scheme is to run a custom finger daemon on my
primary machine which validates addresses vs the vpopmail database.
Again, I have protected this service via tcprules, so it is not open to
random machines. This works very well (since it doens't need to spawn a
new Qpsmtpd instance for each connection).
Additionally, it should be possible to rewrite queue/smtp-forward to use
the smtproutes to directly relay mail to any server you are secondary
for (ala a proxy). This would allow you to authoritatively refuse any
mail that doesn't correspond to a valid user (as long as the remote
server is up and active) and only queue (and possibly later bounce)
messages where you aren't sure are valid. Right now, you may be
bouncing more messages than you strictly need to...
John
