Re: [Exim] Problems with relaying with DNS errors

On Mon, 4 Feb 2002, Dave C. wrote:

> Well, the object of the RBL's is exactly that, to make it not
> economically feasable to do business with companies that host spammers.
> If they are on the RBL, its because they allow/permit/assist/send spam.

This is getting confused. We spent tens if not hundreds of thousands of
dollars moving equipment and setting up a Colo. Nobody is going to go
with another move anytime soon, especially based on an email problem.

> You (or your bosses/etc, after you explain the matter to them) should
> threaten to take your business elsewhere if your colo provider doesnt do
> whatever is necesarry to get their IP's off the RBL. Often just the
> threat will get them into action.

Well, I have notified the facility. They have said that they are working
on it. They notified their customer, and I am told that they both have
notified the RBL. I found one RBL site blocking them, and they had no way
to contact them. I have no idea what other RBLs list this Colo.

We may be getting new lines put in the facility for our own use, which
would solve the problem, but I have this problem until that time.

> > > I'm still a little fuzzy on what you are trying to do - I gather you
> > > have a server at another location, that is on non-RBL'd address space,
> > > that you want to relay for the server that is on the RBL'd space?
> >
> > Absolutely. Not RBL'd, but saturated.
>
> The one that is on not-RBL'd space is saturated, or the other one?

The non-RBL'd space is very near saturation, and firewalling and response
issues recommend the server that wants to send mail live close by the
other equipment, ie, in the 32 RBL'd Cs.

> > Seems so easy, doesn't it?
> >
> > That works until DNS dies, then the relayed messages, instead of getting
> > temporary DNS type errors, get "Cannot Validate" 5xx errors with nasty
> > returns and customers don't get their receipts, lost passwords, etc.
>
> So dont use hostnames, use host IP addresses exclusively instead.

So you want me to write my own MTA that doesn't 500 on DNS errors? Or are
you saying that I should ask people to enter their email address in the
form of IP addresses?

> By the way, you do know if you have say, the 'class c' 1.2.3.0 as your
> block, you can list that entire block (in, say relay_host_accept) by
> entering:

I am aware of CIDR notation, and I host_accept_relay for 1 IP address.




Let me restate the problem:

Machine A can't mail cuz its RBLd
Machine B can mail, but it can't be Machine A.
Machine B accepts mail from Machine A to relay
Machine A uses Machine B as a smarthost.
Machine A needs to tell somebody something via email
Machine A talks to Machine B and says:
MAIL FROM: foo@???
RCPT TO: somebody@???
...
Machine B gets the message.
*plonk* DNS dies
Machine B now hits sender_verify_callback
DNS is still dead
Machine B says:
i can't do dns
550 user unknown
Machine A gets a dead letter

Now, normally, there's this whole "Can't do it, will retry for 4 days,
yadda yadda bing bang". Ain't happening - I get no user instead. The
rest of the day goes to crap. I want normal retrys going on here.
sender_verify_callback may have nothing to do with it EXCEPT: I do sender
callback verification AND I've told Exim to NOT do it for Machine A.


> > > > > > sender_verify_hosts_callback = !a.com : !b.com : ... : !relay.com
> > > > > > sender_verify_callback_domains = !a.com : !b.com : ... : !relay.com
> >
> > doesn't seem to help. :(
>
> I think you are misunderstanding what those two options do, they dont

I understand fully well what they do. And if they fail because they
ignore the !relay.com and DNS is down, they make 550s out of every message
and I get an inbox full of dead mail 2 seconds after they go out. And if
they don't ignore it, they can't resolve the destination and make 550s out
of every message. The subject says nothing about callback - it says
problems with relaying and dns timeouts.

Chris