eric <[EMAIL PROTECTED]> wrote:
> 
> > > > Use tcpserver to refuse all connections from pm0.net.  Voila, no more
> > > > problem.
> > > 
> > > tcpserver (unless patched) requires IP ADDRESSES.
> > 
> > No longer true.  tcpserver accepts hostnames just fine, with appropriate
> > syntax.  See the documentation for tcpserver for details.
[...] 
> Thinking this might be what I was looking for, I tried putting both
> "=.pm0.net:deny" and "=pm0.net:deny" successively into a test.cdb and
> then ran the following (with results shown (the results were the 
> same in both cases)):
> 
> $ tcprulescheck test.cdb ofr.pm0.net
> default:
> allow connection 

The tcprules syntax above is the correct one; the problem here is you're
not invoking tcprulescheck properly.  It takes the remote host
information in an environment variable, not as an argument.
 
> > > And, pm0.net is not the only one I'm having problems with -
> > > edirectnetwork.net is another.  And I'm sure there are others, but
> > > these two are by far the biggest problems.
> > 
> > So refuse mail from them as well.  There's no law that says you have to
> > accept SMTP connections from everyone on the planet.  Perhaps they'll
> > clean up their act if they can't reach half their list members.
> 
> OK, so now the burden is back on me to keep up with who I need to block
> and who I don't.  I'd rather have the software do it automatically if
> possible, and the easiest way to that would be checking for valid users.

Life as a mailserver administrator isn't easy :).
 
> vdelivermail currently has two possible options for dealing with 
> "no mailbox" situations.  1) deliver a copy of the undeliverable 
> message to an actual Mailbox (default to postmaster) or send a
> bounce message.  Looks like I might end up hacking on vdelivermail
> until it yields a third option...  sending undeliverable messages
> to /dev/null.

Perhaps it already works if you specify the default mbox you want it to
deliver to is /dev/null?
 
> That still doesn't inform the broken list managers of their problem,
> but at least it will unclog my outbound queue of wasted bounces.

The other way to handle this would be to throw away _outgoing_ mail
destined to that host (i.e. the bounces you're generating) before they
go over the wire.  You can do this with virtualdomains and an
appropriate dot-qmail file containing only a comment.

Charles
-- 
-----------------------------------------------------------------------
Charles Cazabon                            <[EMAIL PROTECTED]>
GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
-----------------------------------------------------------------------

Reply via email to