Re: [Exim] Problems with relaying with DNS errors

Top Page
Delete this message
Reply to this message
Author: Dave C.
Date:  
To: Christopher Curtis
CC: Exim Users Mailing List
Subject: Re: [Exim] Problems with relaying with DNS errors
On Mon, 4 Feb 2002, Christopher Curtis wrote:

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


Well, normally contacting them isnt they way to get off - changing
whatever caused them to get on in the first place is the way to do it.
It sounds like in this case terminating the spammer's website(s) would
be the ticket.

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


Nonono.. Use numeric IP addresses (and networks) in exim config
settings, rather than host names. Then exim doesnt have to rely on the
DNS when doing those checks..

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


Then instead of putting

! relay.com

in sender_verify_hosts_callback, put

! IP.AD.RE.SS

where that is the IP address of the host "relay.com" (host A I assume?),
or if its an entire network of machines, you can use eg, 1.2.3.4/24 in
there to specify that..

Dont use the DNS for identifying machines you are receiving mail from,
use numeric IP addresses..

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


--