> >> We removed sorbs. I don't think it's even open for debate at the
> >> current
> >> point.
> >> If places like hotmail mx's end up on the blacklist you *will* have
> >> upset
> >> customers.
> >
> > Yeah. It would be nice if there were a blacklist out there that took
> > the
> > best of all the others but refused to list things like hotmail for
> > those of
> > us who are in the situation of having users who expect connectivity to
> > Hotmail and their ilk. Yes, it sucks, but this is what it is to have
> > paying
> > customers with friends who use MSN, etc, etc.
> >
>
> So, then, where should they draw that line? Let in hotmail, yahoo,
> aol, verizon, and earthlink
yes. i don't think any administrator with paying customers to please would
be happy if any of these were blacklisted.
> ... 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?
using something as strict as a RBL that lists Hotmail can only be useful for
scoring but not as an outright block. I really don't think people who
regularly correspond or who have to support ppl who correspond with hotmail
users would argue with that. Sounds like you aren't one of those ppl.
> 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.
> does want you to whitelist hotmail ... while the other half of your
> base is exactly the opposite? It isn't a solvable problem, IMO.
> Everyone will want to draw the line differently, so there wont be an
> easy solution of that nature.
But BLOCKING all mails from somewhere like Hotmail *IS* a decision that
someone has made which is not acceptable to we who support large user bases.
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 -- you HAVE to work from there, meaning that then if stuff doesn't
score where your users like it, they have to adjust their own SA settings
(ours do it on their own through a SquirrelMail interface).
> 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? Our job is to avoid that - it's
obviously not workable at least for those in a position like the one I've
described. So we have to stop using SORBS at the outset. And I'm pretty sad
to do it, because so far it has been one of the best front-line defenses
we've had. In general I think they are great, but this hotmail thing is NOT
workable in our situation, and probably in many others
Or are you saying I should sit around all day and monitor ever-changing lists
of potential spammer IPs and manually adjust our MTA white/black lists?
That's not exactly realistic, so I'm not sure what you are suggesting (I
think I am about to find out...)
> 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.
> (I'm also trying to get this for SURBL and RFC-Ignorant, but SURBL is
> taking some time, and RFC-I is unresponsive to my requests)
Don't get me wrong, I am fully supportive of the people taking their time to
run those services (where would we be without them), but their general lack
of responsiveness seems strange -- no matter which service it is, I always
hear people say things about how non-responsive they are. Is it that they
can't manage to parse through the number of insulting inquiries they get from
the legit ones? Are these people that overworked? Seems like being more
responsive, even if to just tell spam-friendly ISPs to take a hike, would
give them more credibility. SPEWS seems to be the most common target of this
criticism, but I've heard it for SORBS, etc too
> If I wanted to be sure that hotmail didn't get in there, I would add
> their to the grep -v expression (or pipe it through another layer of
> grep -v). If a host gets listed that my users need to hear from, then
> they can notify me, and I'll do the same there.
OK fine, but then you are taking over part of the RBL job. We have done a
little of this too, by having a very small number of hosts whitelisted in our
MTA, but that's a hack at best. And I have better things to do with my time,
frankly, than manage something that is so fast changing. And most RBLs (as
you have found) are not set up to work like that. I'd rather not piece
together a kludge that pulls apart the logic of RBLing. There is no reason
someone can't start a new RBL (there are lots out there) that is aimed at the
needs I have described. If only I had the time....
> 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.
> If you can't depend upon any particular RBL to never contain addresses
> you want to listen to, then you need to take one of those two
> strategies.
No, there is a third - don't use the RBL as a front-line defense mechanism.
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
