On Sep 21, 2005, at 5:23 PM, email builder wrote:
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 ... but who not to whitelist? And, what if
half of your user/customer base does NOT want you to white list aol but
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.
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).
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)
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.
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.
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.
