An organization that blocks 90% of spam with no false positives is incredibly useful.
Tony.
Using a greylisting system is equally effective without the black list part.
My milter-greylist installation is aimed at allowing as much mail through as it can, instead of the other way around. Milter-greylist has a nice urlcheck feature and/or ldap verification for users. In my case it's a PHP script.
If I can verify the IP to be inside a /22 of the MX records, www records or domain records that is sufficient to bypass the greylisting. The timers are also quite lenient. Just 15 minutes of wait is enough, of they are persistent if we've seen them before by domain. We get the email regardless and phone calls are rare, and I never run the risk of never getting the email.
This has turned out to be a really effective way to allow normal email through without much delay. After just 2 days at work it's whitelisted over 75% of the active domains we do business with.
We have about 17 domains and I know what the poster is asking, we've been emailing our customers before, subscribed customers none the less. We've had our share of blacklisting before. And we even sent the emails with unsubscribe links.
But some of them will click the "report this as spam" link in their favourite mail agent as a means to unsubscribe. I mean, clicking a link is hard. The end result is that we end up on various block lists. It's a good thing that the email servers at large isps are often sensible enough to let the email through.
Some of the smaller ones had rather odd draconian limits set. This makes the situation for all of us worse.
Regards,
Seth
< SNIP />
Unless many contiguous blocks are assigned as different objects : a
RBL must NOT presume of one end-user's inetnum unless it has been
cathed doing nasty things AND didn't comply to abuse@ requests.
An RBL *can* do whatever an RBL wants to do.
An RBL *can* block an entire allocation for whatever reason they chose including - a single spam message with no requests sent to abuse@ or any contact of any kind with the group allocated the space.
The only "control" over an RBL is their desire to remain relevant by preserving an opinion of accuracy in the minds of end users. If end users believe that an RBL is no longer meeting their needs, then they will stop using that RBL.
But most RBL managers are shitheads anyway, so help them evade,
that'll be one more proof of spamhaus&co. uselessness and negative
impact on the Internet's best practices.
OK. I'll bite. What particular "internet best practices" are Spamhaus trampling on?
-DMM
Greylisting and reverse-DNS checks alone blocks 95-98% with no impact
on mail sent from properly maintained mail servers. RBLs are only
usefull for lazy mailadmins, and to save some network and CPU
resources while avoiding greylisting and rDNS. But it implies you
fully trust the RBL author, and some really ain't trustworthy.
I'd rather loose some mails from poorly managed domains than rely on
any external almighty authority, it looks to me like an incentive to
consider SMTP administration seriously rather than using default
settings from the package maintainer...
My feeling is that (paraphrasing here) "we might get blocked
occasionally" and "we need this many IPs on our MTAs because they
can't handle the load" are *not* legitimate reasons for requesting
so many addresses.
It is definitely not your job to help spammers evade blocking. If
someone's blocking their mail, that's a message to stop sending it,
not to try to sneak it in the back door. The valid scenarios for
spreading out IPs are so rare (and generally involve guys with guns)
that you can ignore them.
Legitimate bulk senders want their IPs in a compact block so they can
set up feedback loops from ISPs and stop sending mail that people
don't want. As other people have noted, you can send vast amounts of
mail from a small number of IPs, and anyone big enough to have a valid
need for a lot of address space is also big enough that you have
already heard of them.
Friendly threat: around here, if we know that an ISP is hands out IP
ranges for snowshoe spamming, we often block their entire address
range preemptively to avoid the tedium of blocking it one little chunk
at a time.
R's,
John
They have inquired about IPv6 already, but it's only gone so far as
that. I would gladly give them a /64 and be done with it, but my
concern is that they are going to want several /64 subnets for the
same reason and I don't really *think* it's a legitimate reason.
No legitimate mailer needs more than one /64 per physical network.
Same reason.
R's,
John
An organization that blocks 90% of spam with no false positives is
incredibly useful.
Using a greylisting system is equally effective without the black
list part.
Hi. I'm the guy who wrote the CEAS paper on greylisting.
Greylisting is useful, but anyone who thinks it's a substitute for
DNSBLs has never run a large mail system.
R's,
John
We use the black lists for scoring spam messages, but we never outright block messages. I was not implying that blacklists are not useful at all. I just see things in shades of grey over black and white.
Of the 17 domains we have with roughly 250 users it does well enough.
Regards,
Seth
RBL's are often seen as an "easy solution" to a quite complex problem.
Most mail administrators are relying on them so blindly that some may
forget to evaluate an RBL's pertinence regarding their particular
needs.
Providing such an "easy" way to avoid learning how to provide your
mail service definitely has a bad influence for the overall quality of
mail services. That's a first negative impact : letting noobs think
they can manage a mail server because "the magic RBLs seems to solve
my major issue" without looking to further side-effects.
Next in line, RBL managers don't even try to contact abuse@ or
postmaster@. So mail admins can't use them as a way to improve their
setups. Well, of course, it probably started with large corporation
routing ther abuse@bigestrmailserviceonearth.com to /dev/null, but
that's not the point : if you pretend to improve mail services, do it
right : use abuse@ and postmaster@ before blacklisting (note : botnets
sending from forged domains have to be considered differently of
course, but the rDNS check often fits that part quite well).
Last but not least, some RBLs are extorsion scams requiring one to pay
to get it's inetnum removed from any blacklist. It might be just an
incentive to help a non-profit charity cause, it still smells like a
mafia-related scam to me.
Let the RBLs' maintainers clean up their front doors before asking for
any legitimacy. Right now, relying on them is either stupidity or
lazyness. But if you can point me to any serious organisation
providing a real value-added service maintained by real professionals,
those who performs thorough checks _before_ putting a legitimaite mail
server in a blacklist, then i'd enjoy benchmarking it on a test
domain. Just let me doubt it'll be of any good regarding how
efficients is a properly managed mail server with just a few tech
tricks.
Hi. I'm the guy who wrote the CEAS paper on greylisting.
URL ?
Greylisting is useful, but anyone who thinks it's a substitute for
DNSBLs has never run a large mail system.
You're right, greylisting on a large system may not be efficient as it
won't block everything and will eat-up quite a lot of system
ressources. But it's a good start once basic protocol-checks have
already eliminated the 80% amount of bullshit sent from botnets.
My point is : combining server-side checks of different nature is
often enough to avoid the use of RBLs and still provide a goode
quality of service. It probably won't scale to comcast' or AOL' MXs
but it's way better than relying on an external authority for your
corporate or personnal mailserver.
Seth,
Hi. I'm the guy who wrote the CEAS paper on greylisting.
URL ?
They don't have Google where you are, huh?
You're right, greylisting on a large system may not be efficient as it
won't block everything and will eat-up quite a lot of system
ressources. But it's a good start once basic protocol-checks have
already eliminated the 80% amount of bullshit sent from botnets.
Most of us use DNSBLs like the CBL or Spamhaus XBL to catch the botnet mail. It's a lot easier to let them tune their protocol quirk checker than to do it myself.
R's,
John
Spamhaus. And none of your complaints apply to them.
Tony.
I do believe in this one paragraph, we know who the real shithead is.
Noted and filed away for future use.
Oh really ? So the blame is to throw at Google Docs administrators for
beeing blacklisted (on the SBL, which should contain only "verified
spam source", thus implying discussion with the service manager) ? And
BTW, who is Spamhaus to claim any legitimacy about who can or can't
register a domain ? (referal to the .at phishing campaign).
Alright, those are probably exceptions, and _some_ lists may be
usefull, but obviously noone can claim to have an efficient "zero
false-positive" list. Blindly relying on those lists _will_ lead to
false positives and are a comodity for mail server administrators that
might lead to sloopy filtering and weaker control over their mail
infrastructure.
Also, such lists are _centralized_ systems that *might* (worst case
scenario) be spotted for attacks. What would be your mail
infrastructure load if you rely on a list that disapear overnight ?
Yeah, right, anycasted DNS infrastructure, redundancy over 4
continents, that's fine for most of us ('til it fails).
In my opinion, the use of RBLs as a first level filter for incoming
mail, instead of greylisting, rDNS and strict protocol compliance
(cluttered with some Exchange bug-compatibility perhaps), is less
reliable, so it's against what I shall consider as a best practice.
I hope that clarifies my point of view, and please excuse me for the
previous insults, I just have a hard time reading "hey, my critical
services are dependant of an external, centralized entity with no
transparency and that's good for the Internet" without compulsive
expressions including F. words.
Note that the OP spoke of assigning them one /64, rather than one per
physical net. I also note that ARIN, at least, suggests "/56 for small
sites, those expected to need only a few subnets over the next 5 years",
which would seem to include this site even without their justification.
All they need -- or, I suspect, need to assert -- is to have
multiple physical networks. They can claim a production net, a DMZ,
a management net, a back-end net for their databases, a developer
net, and no one would question an architecture like that....
--Steve Bellovin, https://www.cs.columbia.edu/~smb
All they need -- or, I suspect, need to assert -- is to have
multiple physical networks. They can claim a production net, a DMZ,
a management net, a back-end net for their databases, a developer
net, and no one would question an architecture like that....
My impression is that this is about a client whose stuff is all hosted in a single data center.
R's,
John
Then take out the developer net (or make it a VPN) but the rest remains.
--Steve Bellovin, https://www.cs.columbia.edu/~smb
Meant to send this to the list.
They have inquired about IPv6 already, but it's only gone so far as
that. I would gladly give them a /64 and be done with it, but my
concern is that they are going to want several /64 subnets for the
same reason and I don't really *think* it's a legitimate reason.No legitimate mailer needs more than one /64 per physical network.
Same reason.R's,
John
This is my feeling exactly. The unfortunate part is, they seem to be
close with another customer of ours with whom we've had a very good
professional and non-shady working relationship for a number of years.
My feeling is that they simply do not fully know what they are doing.
I believe that they think they are doing things in a technically
clever way, but in reality, it just makes them look incredibly shady.
As I said, they've been a customer for about 7 years now and for the
amount of email that they send, the complaints are at a bare minimum.
I've seen much worse much quicker when a customer's box becomes an
open spam relay.
That said, the decision has been made to not provide them the
addresses. In addition, we are going to force them to renumber into a
much smaller block of contiguous IPs. I am of the firm belief of many
others on here that for customers whose business deals primarily in
email, there is no legitimate reason to have multiple discontiguous
blocks. We've dished out assignments like this before, but I've only
seen it requested by companies that do *legal* security vulnerability
scans.
Thanks,
steve