Front page | perl.qpsmtpd |
Postings from June 2005
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 DoddsThread Previous | Thread Next