In /var/log/mail/smtp/current log gile I'm getting following errors (many lines).
@400000004519c19833a6ec5c rblsmtpd: xx.xx.xx.xx pid 4587: 451 temporary RBL lookup error
Is this because, one of the rbl site is down? Due to this incoming emails are coming very very slow.
For now I disabled rbl in toaster-watcher.conf.
Can anybody has more information on this?
Like, are these errors normal?
Should I try to enable rbl in toaster-watcher.conf and see whether these errors go away?
Are should I try by disabling each RBL URL in toaster-watcher.conf, to see which one is causing these errors?
I appreciate your help.
run toaster-watcher.pl by hand, with the -v flag and see which one it gets stuck on and remove that one. Also, do you have functional DNS?
thanks. I enabled toaster_debug in toaster-watcher.conf and ran
toaster-watcher.pl by hand. And I found the RBL site which is down and
disabled that.
By the way, toaster-watcher.pl should automatically disable the RBL sites which are sown. right?
May be this is a bug in toaster-watcher.pl ?
I can't find a way to do this, but is it possible to make it just allow mail to be delivered when it cant contact an RBL? I set the rbl timeout low, but I get that "temporary rbl lookup" error and i'd rather my users are able to send mail, and I'll put up with some extra spam while a given RBL is down.
Quote from: kilorat on October 16, 2006, 12:55:50 PM
I can't find a way to do this, but is it possible to make it just allow mail to be delivered when it cant contact an RBL? I set the rbl timeout low, but I get that "temporary rbl lookup" error and i'd rather my users are able to send mail, and I'll put up with some extra spam while a given RBL is down.
The SMTP connection does "fail open" and allow mail to be delivered if the RBL is down. However, it only does so after the timeout interval. So, it will still work, it just makes the connection take a long time. You can alter this with the dns timeout setting.
if it fails open, then why do wen end up with 451s?
Because the RBL passes the test at test time, and then stops working before the next test. During that time, it doesn't receive a failure, but normally a timeout error.
Quote from: matt on December 25, 2006, 09:45:07 PM
Because the RBL passes the test at test time, and then stops working before the next test. During that time, it doesn't receive a failure, but normally a timeout error.
which begets the question, can the rbl check itself fail open? is that a fucntion of the way rblsmtpd works or the way that qmail/toaster interprets a timeout?
i understand failing for a timeout on the sender's reverse DNS, but this behavior makes mail delivery dependant on all of the RBLs staying up, which i don't find particularly desirable.
Quote from: jerm on January 26, 2007, 12:03:10 PM
Quote from: matt on December 25, 2006, 09:45:07 PM
Because the RBL passes the test at test time, and then stops working before the next test. During that time, it doesn't receive a failure, but normally a timeout error.
which begets the question, can the rbl check itself fail open? is that a fucntion of the way rblsmtpd works or the way that qmail/toaster interprets a timeout?
An RBL may fail open, but we'll detect it. Take a look at how the tests work. There is a check for both a positive and negative result that, if answered incorrectly (or not answered) cause that RBL to fail out and be excluded.
The only time we have problems is when an RBL is really slow, say because of a DDoS attack. We test, it works. A minute later, it's unavailable and causing us problems. We fail it the next time toaster-watcher.pl runs, but then it's back up 10 minutes later, for a minute or two. There's really not much better we could do. You don't want to be querying the RBL server every 10 seconds to make sure it's up, at least not by default.
i guess what i'm not understanding is, what's the downside of failing-safe on an RBL timeout?
if it's going to get taken out of the lineup on the next TW run anyway, then we're not giving anything up by not reporting it as a failure.
Failing safe would solve the very issue to which you say, "There's really not much better we could do"
What benefit do we derive from an rbl timeout not failing safe? failing safe costs us nothing and avoids problems when an RBL is getting DDOSed. So I ask again, what is the downside of failing safe?
jerm
The downside, it would seem is quite obvious, is more spam. If a DNSBL is having problems, then we defer emails while it's broken. In the grand scheme of things, that's not a big deal. A 451 error is basically, "oops, I have a problem here, come back later." so its not like we're risking losing email.
We were referring to two different things in regards to failing open. I was talking about how we test the DNSBL and upon re-reading this thread, I think you all were speaking of the default behavior or rblsmtpd. That is set to fail closed, but if you want to fail open, just set rbl_enable_fail_closed = 0 in toaster-watcher.conf and you'll get what you want.
This is excellent FAQ material and I'd appreciate if someone were to compose this into a FAQ entry.
Matt
Quote from: matt on February 08, 2007, 06:06:15 PM
We were referring to two different things in regards to failing open. I was talking about how we test the DNSBL and upon re-reading this thread, I think you all were speaking of the default behavior or rblsmtpd.
that explains a lot.... thanks :)
and thanks for the option