Re: [Exim] Problems with relaying with DNS errors

On Mon, 4 Feb 2002, Christopher Curtis wrote:

> On Mon, 4 Feb 2002, Dave C. wrote:
>
> > On Mon, 4 Feb 2002, Christopher Curtis wrote:
> >
> > > Hello,
> > >
> > > I'm having a problem: I'm using sender_*_callback functions and providing
> > > relaying for a domain whose ISP has been RBL'd. Now, this generally works
> > > fine, but this morning we had some DNS errors, and the callback features
> > > stopped working. As a result, the mail that was supposed to be relayed
> > > was being rejected instead. The significant lines are:
> >
> > You are helping an ISP get to around an RBL??? Why on earth would you do
> > that? The RBL serves a purpose - they should correct whatever problem
> > they have that has them on the RBL instead of trying to get around it.
> >
> > Doing this will likely get *your* servers on the same blacklist.
>
> This is not the situation. We have several facilities, including one
> which we just opened. I've setup a box at this new facility expecting to
> be able to send mail. However, this facility shares IP address space with
> someone else who hosts a website that was advertised in spam sent from a
> wholly different facility. As a result, all 32 Class Cs at this new
> facility are on one or more facist RBL lists. Outblaze.com (a provider of
> free email services services) is our biggest problem, but there have been
> others as well. This is *my* mail, that I have to route around, because
> of some overzealous RBLs.

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.

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?

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)

> > > sender_verify_hosts_callback = !a.com : !b.com : ... : !relay.com
> > > sender_verify_callback_domains = !a.com : !b.com : ... : !relay.com
> >
> > > so the relaying host shouldn't even be subject to these checks, but they
> > > are, and they fail. This is an even bigger problem because many of these
> > > messages are automatically generated (password requests, receipts, etc)
> > > and cannot be easily resent.
> > >
> > > Is there a way to freeze these messages instead of rejecting them during
> > > these times of DNS woe?
> >
> > Suggestion: Use numeric IP addresses in any exim config option with
> > "hosts" in it. This is a *big* win in terms of both reliability and
> > speed.
>
> I'll do that for the callback exclusions, but that doesn't solve my
> problem. The callback depends on DNS for its routines, but if DNS is
> down, it generates a hard error to the host expecting to use me as a
> relay. That sucks because there are no users on this server - everything
> is automatically generated, and isn't easily regenerated.
>
> regards,
> Christopher
>
>

--