Quinn Comendant wrote:
> On Wed, 22 Nov 2006 09:07:05 -0700, Eric "Shubes" wrote:
>> Given that it'd be possible to see how long the rbl lookup takes, the
>> problem becomes how to 'remember' not to use that rbl any more. As things
>> presently work, each smtp session is a separate process, and there's no way
>> for one instance to 'remember' what another has done. You'd need to update
>> the blacklists file, and restart qmail. Not something you'd want to do from
>> within rblsmtpd.
>
> Do you mean with the timeout solution? It won't need to remember...
> the timeout is applied each time a connection is made.
> Yes that means if there is a bad blacklist,
> EVERY smtp connection will last as long as the timeout (5 seconds).
No, the timeout solution is something different. If the timeout were 5
seconds, it'd be a continual 5 second *delay* (not duration) of each smtp
connection. Certainly better than what's happening now, but far from optimal.
The rblsmtpd program *might* be able to be patched to timeout the dns_ip4
call (it's a C function), but how it would be done isn't readily apparent to
me (my C's a bit rusty). The timeout that's presently there of the smtp
session simply exits, which is easy enough to do. In this case though, the
process would need to resume on interrupt, and I'm not quite sure how to
code that. I'm sure that an accomplished C programmer could hack it though,
and I could probably figure it out eventually, but I'm not very experienced
with catching signals (the method used to implement the timeout). Also,
dns_ip4 is done for both rbls and anti-rbls, so that processing should
probably be done in one place instead of two as it is now. Note, djb's code
isn't as well structured as it might be. It might be *slightly* more
efficient the way it is written though.
>
>> I'm thinking that a script which would maintain the blacklists file as
>> previously mentioned would still be a good thing to have, regardless if
>> rblsmtpd can be patched or not.
>
> I still think so too.
I think the script deserves a higher priority, as it's more of a permanent
solution instead of a bandaid (worthwhile none the less). Plus, I know I can
code the script. I'm not so sure about the rblsmtpd patch.
> Another feature is timing the DNSRBLs and sorting them by their response
> speeds,
> putting the fastest ones first in the blacklists control file.
> As I understand it they are processed in order
This is true. I've read the code.
> and if the fastest ones are queried first blocking messages would be quicker.
Not necessarily. I think you'd need to look at the probability of each rbl
getting a hit, and rank them that way, unless a particular list is
consistently much slower than the others. I'm guessing that they're all
pretty close, but I could be wrong. It be an interesting exercise to see
what order produced the best performance.
> Not a speed up for SMTP connections where messages do come through. Just an
> option.
I'm going to leave it as a manual process for now. You can put them in any
sequence you like, and the program processes them in that sequence.
> Also this script would need to query the servers directly, so as to not be
> skewed by dns caches.
I've thought about this. I read somewhere today that all DNS servers cache,
so I've been thinking of generating a random IP address to use in the dig
command in order to avoid this as much as possible. If you can think of
another way to get around this, I'm all ears.
> An alternative version of this script is one that is run as part of the
> /var/qmail/supervise/smtp/run script or integrated into qmailctl (probably
the latter is better).
I don't see why this would be necessary if it's run every 15 minutes anyway.
You could plug it in wherever you'd like though.
>The blacklists control file is parsed and checked during smtp server
start/restart.
> If a DNSRBL is unresponsive, just display a message:
> "Blacklist xxx.yyy.com not available, skipping...".
That's pretty much what it would do. I don't know if I can have it use the
smtp log for messages or not, but I'll look into it. Logging will not be a
high priority, as you can see what lists are being used at any time by
looking at the blacklists file or smtp processes (ps).
> I know it seems like DBSRBLs are going up and down every day,
> but there should be a lot of stability in this infrastructure as it is.
> Running a DNSRBL-testing utility every hour really should *not* be necessary.
You're right. It'd be nice to have an insurance policy though, especially on
a high volume high availability server. On a lightweight server it's not
such a big deal.
> Quinn
>
--
-Eric 'shubes'
---------------------------------------------------------------------
QmailToaster hosted by: VR Hosted <http://www.vr.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
