Re: [Exim] Problems with relaying with DNS errors

On Mon, 4 Feb 2002, Christopher Curtis wrote:

> On Mon, 4 Feb 2002, Dave C. wrote:
>
> > Oic.. Well, insist that the colocation facility give you different IP
> > space. Or insist that they do whatever is ncesarry to get themselves off
> > the RBL. Or take your money to another colo facility. That is the entire
> > POINT of the RBL, to make it undesirable to host a spammer or to do
> > business with someone that does.
>
> This is not economically feasible. I'm a worker ant, and this isn't
> exactly one server. The problem is that ALL IPs here are RBLs.

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.

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.

> > 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?

> > If so, then just set the server that is RBL'd to smarthost through the
> > other, and then set host_accept_relay on the non-RBL'd server to include
> > the numeric IP address(es) of the RBL'd server (and possibly also add
> > them as exclusions to your sender_verify_hosts_callback, as well, if
> > you have that setting in place for some other reason)
>
> 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.

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:

1.2.3.0/24

in a something_hosts_something entry in exim ?

I think the key to what you want is to add

host_accept_relay = (IP networks where the RBL's hosts list)

to the exim server that is on the non-rbl'ed network..

> And:
>
> > > > > 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
disable checks that would otherwise occur, they set additional checks to
perform when receiving mail from certain hosts or with sender addresses
in certain domains. Generally, the '!' is used with that when you would
normally have:

sender_verify_hosts_callback = *

to specify that you want to perform callback checking for mail coming in
from all hosts, but then you want to make specific exceptions, eg, say
you want to permit host 1.2.3.4 to send mail, and since you trust that
host, you dont want it subject to sender verification, so you do

sender_verify_hosts_callback = ! 1.2.3.4 : *

With your setting of

sender_verify_hosts_callback = ! this : ! that : ! somethingelse

You are excepting those specific hosts from the checks, and subjecting
everything else to them. If you wouldnt normally have

sender_verify_hosts_callback = *

then dont have the entry in there at all

If you don't normally use sender_verify_hosts_callback, then turn that
off entirely.. I'm not sure what you are trying to to there.. Those
options are normally used when _receiving_ mail, when you want to (try)
to make sure that the sender exists prior to accepting the mail. They
don't enable any mail to go through that wouldnt already.



> Chris
>
>

--