John Peacock wrote:
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
For me, splitting local delivery to dspam(lmtp) and relay to
external to qmail has little to do with senders, and to the
extent it does, I'd prefer to know in queue if sender is auth'd
while not caring much if at all about relayclient, as far as
routing, checking, differentiating(clean dspam headers in
some cases, do different things if auth'd with -list and
spam/nospam-).
Hopefully received header is not spoof-able if I look at
$from_escape_at =~ s/(\100)/\x40/ ;
$auth = $received =~
s/.*(smtp-auth).*($from_escape_at).*($mta).*/$1/s ;
and rcpt already checked for spf fail by an external mta
or internal trojan spoofing the real mta here.
Incidentally, check_early_talker and header and unrec
command, av, checks would help with relay_client trojaned
pc's, ESPECIALLY if there are any trusted(relay_client)
windows pc's, so I again I might take the opposite view
of some(wouldn't spam-check-bounce relayclients though).
Personally I don't want them to poison my spam filter just
because they're trusted relayclients(whitelisted to train
as notspam i.e. ruin my precious 99% rating if they get
past protocol and header checking).
-Bob Dodds
