> "Charles Cazabon" <[EMAIL PROTECTED]> wrote
> eric <[EMAIL PROTECTED]> wrote:
> >
> > > "Charles Cazabon" <[EMAIL PROTECTED]> wrote:
> > >
> > > Why is it ridiculous? Mail sometimes can't be delivered; hosts are
> > > down, networks are down, services are down or busy, users make typos.
> > > "A few" depends on a lot of things; if your server handles a hundred
> > > messages a day, maybe "a few" == 5 or 10. If your server handles
> > > millions of messages a day, "a few" might be in the tens of thousands.
> >
> > It's ridiculous because if qmail-send could do the lookup and
> > reject for invalid users, I would not have hardly any bounced
> > messages.
>
> qmail-send doesn't have anything to do with accepting mail over the
> network; it doesn't care. qmail-smtpd has that job, assisted by
> tcpserver. qmail-smtpd doesn't know anything about local users or
> virtual domains or anything; it's part of the security design of qmail
> to segment/separate the tasks involved. Giving qmail-smtpd knowledge of
> users, domains, etc violates that separation.
>
Typo... I meant qmail-smtpd.
> > > Okay, so whoever runs postmastergeneral.com needs to be educated about
> > > running mailing lists. No surprise there.
> >
> > Yep. But getting them to change is gonna be darn near impossible.
>
> If you (and others) start refusing to accept mail from them (my last
> suggestion), they may start to care very quickly. I would guess their
> business depends on it (I know nothing about them).
>
> > Someone, somewhere must have come up with a workaround/patch for this.
>
> Yes; someone did post a patch to the qmail list which basically copied
> all of qmail-send's checks into qmail-smtpd. I don't think it's
> commonly used, as I haven't seen it mentioned since. You should be able
> to find it in the list archives.
>
Searching archives...
> > > > Instead, it relies on the qmail-local (or in my case, vdelivermail
> > > > since I'm using vpopmail) to send a bounce. However, it looks like
> > > > postmastergeneral.com (and others) is not removing addresses from
> > > > lists based on the bounce messages that I'm sending.
> > >
> > > So the problem is with them, not qmail.
> >
> > Again, getting them to change will be darn near impossible. But, the real
> > point here is that I'm wondering if there is any way to change the default
> > bounce message to something they will process.
>
> It's easy to change the format of the bounce messages, but why do it?
> qmail's bounces messages are _easier_ to parse than most other MTAs.
> See http://cr.yp.to/proto/qsbmf.txt for a description of the format. If
> you do want to change the bounce messages, please adhere to QSBMF.
>
I would only do it if would help. If it won't help, I don't want to
change it.
> > > > Anybody got any ideas on how to solve this?
> > >
> > > 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.
Maybe I'm just a complete dolt, but I can find no mention in the man pages
of it accepting hostnames. I'm looking at the man pages on DJB's website
for version 0.88 (which happens to be what I'm running). I'm testing
some stuff hoping to "luck up" on the "appropriate syntax."
I did find the following two lines in the man for tcprules:
4. =$TCPREMOTEHOST, if $TCPREMOTEHOST is set;
6. shorter and shorter suffixes of $TCPREMOTEHOST starting with a dot,
preceded by =, if $TCPREMOTEHOST is set;
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
>
> > 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.
> > PLUS, there is legitimate mail coming in from both of those servers
> > for valid users. Doing it this way, I'd be blocking that as well.
>
> Yes -- that's the whole idea. Those "legitimate" users then start
> complaining to their provider, who probably cares more about the people
> who send them money each month.
>
Nope. My users start to complain to me becaues they're not receiving
their joke-of-the-day mails, but their getting everything else. Then
I have to spend a ton of time EDUMACATING them. Not necessarily a
bad thing, but it can very time consuming trying to explain to an
80 year old woman why she's no longer getting the prayer-chain emails
that she lives and dies for...
It's not the best long term solution, but if I could get it working,
I'd take it for now.
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.
That still doesn't inform the broken list managers of their problem,
but at least it will unclog my outbound queue of wasted bounces.
Eric Calvert
