On Sep 21, 2005, at 11:17 PM, email builder wrote:
... but who not to whitelist?
the small guys. unfortunately, large ISPs like that have power in
the
number
of users they have. in no way do I advocate defending that as a good
thing,
but the fact that this gives them an immense amount of power to do
whatever
they want regarding rfcs and whatnot remains a reality. smaller
services are
the only organizations who are going to actually be potentially moved
to
action by landing on one of these RBLs. when was the last time SORBS
managed
to change Hotmail's policies?
Has SORBS ever really changed anyones policies? That's certainly not
what I use RBL's for. I couldn't give a rats posterior about whether
or not some spammer changes careers, or some mail server changes
configurations, or some ISP changes their appropriate use policies.
It's too bad you have such a self-centered attitude about it.
Me!? You're the one who presented the "when was the last time SORBS
..." question as though it was some universal benchmark of RBL value.
You're the one projecting their opinion onto other people here. I was
merely pointing out that it's not a universally relevant question to
determining the value of the RBL and who it chooses to block.
And, what if
half of your user/customer base does NOT want you to white list aol
but
c'mon, when was the last time someone's user base was emailing their
support
staff begging for aol to be blacklisted? beside, this is what
per-user
settings for something like SA are for.
If you're in a situation where users can have per-user settings. For
example, that doesn't work here.
Or, if that's how you're using your RBLs. People DO use rbls as block
lists, and people do use SORBS as a block list. It's hard to have
per-user settings for that.
That is rough. You might look into SQL-based SA per user settings.
It's
very handy.
Seen it. Doesn't apply to our situation.
So we have to make the opposite decision to only use those RBLs in SA
scoring. The baseline here is that you cannot outright ban whole
large
services --
Actually, yes, I can. And I have, for some periods of time (only, in
my case, it was yahoo).
Sure, but who here in their right mind thinks that's a good idea?
Any sysadmin who cares about their mail service and their institution's
ability to do business.
You shouldn't make generalizations when you have no idea about the
situation in question. I blocked Yahoo when we got mail bombed by them
(bouncing a huge volume of forged-sender messages that didn't actually
come from us). It was the responsible thing to do, in order to keep
mail flowing through our systems, so that we could keep doing business.
When the volume died down, we unblocked them.
And I'd do it again.
And, it's not just that I don't think the RBL can do it, I don't
think
that kind of thing is the job of the RBL. I think that kind of
thing
is your job (or, in my case, it's my job).
What's our job? Banning all of Hotmail?
No. Your job is to tailor the tools you use so that they fit your
organization.
SORBS job is to provide a list of sites that fit a particular
behavior.
If you want there to be exceptions to that list, then it is YOUR job
to
make those exceptions, not theirs.
Of course. Didn't you read the part of my post that started all this?
Yes, I did. And I
a) pointed out that such a service can't exist on anything approaching
a large scale (large enough to be worth running) because there is no
universal place to draw the cut-off for who to whitelist and who to not
whitelist,
b) that you can perform that service for yourself, by using their
blacklist as a starting point and trimming out those addresses that
match your whitelist, and then using that as your production list,
and
c) the combination of a and b makes it incredibly unlikely that anyone
would humor such a service idea.
Why are you so pissed off at ME for putting that out
there?
Who said anything about being pissed off?
Though, you clearly don't get what I'm saying, so it does make the
conversation rather pointless.
that you quoted ... it is performed by a script. I do no such manual
thing. I get an email every few hours that tells me what happened, I
scan it for references to networks that I am responsible for, and it
tells me "yes, I removed all of those networks from our copy of the
RBL
zone". Then I put the zone into production on my own name servers, so
that I never see those sites showing up as RBL'ed.
My point was that generally pulling apart RBL functionality and
placing part
of the onus of managing it back on the admin's plate is not going to be
something that goes over well, even if you have a nifty script that
works
with one RBL. Sorry you missed it.
a) I'm not altering RBL functionality in any way; I am altering a data
feed
b) it works for all RBLs; it is not dependent upon the RBL, it is
dependent upon the data feed format (BIND* or RBLDNSD) that the RBL
provides; I have a version of the script for each format, and call it
as appropriate to each RBL. Thus, it only takes one cron job entry for
each RBL, not one script for each RBL. And, it has been in service for
quite a while.
(* SBL used to come in BIND format, and that was my preferred format;
since they went to RBLDNSD format only, the BIND version of the script
isn't in use anymore)
Here at UCSC, we use spamhaus (both SBL and XBL). In order to make
sure my own users/customers don't get blacklisted, I have a cron job
that:
a) use rsync to get a local copy of the zones.
b) grep the files to notify me if any of my own addresses are
listed,
so that I can follow up on why.
c) grep -v the files to remove any of those addresses from the zone.
d) takes the end result and puts it into a place where my name
servers
will pick it up.
See. Automation at work. Computers are useful that way.
Yah let us know when you've scripted a way to brush your teeth too. I
just
don't get this cron thing.
What do you not get?
Alternately, you could create a set of rules that counter-weights
the
spam assassin results for those RBL checks, if they happen to be IP
addresses you need to hear from.
I actually don't think it's much of a problem if such mails get
tagged
as
spam. The user can then adjust their SA settings. The problem is
when the
mail can't get to the mailbox at all.
Ah, you see, in my environment, there's no difference there. We do
deliver all spam, but it seems that "users checking their spam
folders"
is almost unheard of around here.
Woa. This thread, from the start, has been about using SORBS as a RBL
in the
MTA to *block mails*, NOT using it for SA scoring, which is where we
will
continue to use it.
Pardon, I mispoke right there. We do both. We do RBL blocking at the
MTA, and RBL checks in SA (in case an earlier hop than the immediate
relay had been RBL'ed). But, once it gets to SA, we deliver all -- we
don't bounce/reject/discard at the SA stage.
