Hi, On Mon, Jun 20, 2011 at 8:32 AM, Jared Mauch <jared@puck.nether.net> wrote:

On Jun 20, 2011, at 8:30 AM, Bret Clark wrote:

...

Personally I would charge them for the /24 too, makes users think twice about the need for a block that large.

We do charge them for addresses already and cost doesn't come into play. We charge for assignments shorter than /28 to discourage IP hogs.

I would also give them a /64 per lan (alt: broadcast domain) as well to allow them to start working with IPv6 for their email.

- Jared

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. Bear in mind that "legitimate" in this context is referring to the justification itself, not their business model. Thanks, steve

Let them submit the IP justification form, I would like to read how spammers justify their IP usage and I would really like to see how RIR would take it. *Interetesting* Regards, Aftab A. Siddiqui On Mon, Jun 20, 2011 at 6:06 PM, Jason Baugher <jason@thebaughers.com>wrote:

On 6/20/2011 7:44 AM, Steve Richardson wrote:

...

Hi,

On Mon, Jun 20, 2011 at 8:32 AM, Jared Mauch<jared@puck.nether.net> wrote:

...

On Jun 20, 2011, at 8:30 AM, Bret Clark wrote:

Personally I would charge them for the /24 too, makes users think twice

...

about the need for a block that large.

We do charge them for addresses already and cost doesn't come into play. We charge for assignments shorter than /28 to discourage IP hogs.

I would also give them a /64 per lan (alt: broadcast domain) as well to

...

allow them to start working with IPv6 for their email.

- Jared

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. Bear in mind that "legitimate" in this context is referring to the justification itself, not their business model.

Thanks, steve

Did everyone miss that the customer didn't request a /24, they requested a "/24s worth in even more dis-contiguous blocks". I can only think of one reason why a customer would specifically ask for that. They are concerned that they'll get blacklisted. They're hoping if they do, it will be a small block of many rather than one entire block.

When customers make strange requests without giving a good explanation, I have to assume they're up to something.

Jason

On 20/06/11 6:18 AM, Leo Bicknell wrote:

Almost every customer I've dealt with who requested such a thing eventually ended up having their contract terminated for spamming.

I would use this answer in reply to the customer, and ask them to (specifically) justify their request for the discontiguous blocks.

Many of the RBL's chose to increase the size of their blocks to put more pressure on ISP's. So if you give them /29's in 10 different blocks they will block the /24 in each, then a /23 in each, and so on. Basically this becomes a quick way for you to get 100% of your address space blocked, and make the rest of your customers really unhappy. When the RBL's see you gave them a bunch of small blocks in different supernets they assume you are spammer friendly.

And mention all of this as well. If you don't have a special fee you charge when you have to deal with cleaning up or recovering contaminated IPs, include one with this next allocation. Theory: Since their current userbase is not currently creating a spam problem, they are doing one of two things: 1) They are going after a more risky new userbase (e.g. looking at providing services for more spammy customers). 2) They are *concerned* about the possibility of accidentally acquiring a more risky new userbase, and proactively designing their network to have the least collateral damage (to themselves) if such a customer should appear on their network. This would be prudent, good business even. Except for how it prepares for a business shift to #1. The big risk it that they are going to try to sell you on theory #2 when their real business plan is theory #1. I would charge a significant extra fee for discontiguous address space, enough that you can afford to carefully assign the rest of the block to non-web-non-mail-server uses, to not put other customers at risk. jc

2011/6/20 Leo Bicknell <bicknell@ufp.org>:

In a message written on Mon, Jun 20, 2011 at 08:01:24AM -0700, JC Dill wrote:

...

I would use this answer in reply to the customer, and ask them to (specifically) justify their request for the discontiguous blocks.

That's like asking them to state the obvious...

Or, just don't offer it.  Make them fit in one block, giving them 3 months to renumber into a single, larger block if necessary.

Well, forcing a periodic renumbering whenever adress gets freed and there's a potential agregation is a good thing. It should be stated in service agreements, IMHO.

It sends a strong message you're willing to give them all the space they need, but won't help them evade RBL's.

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. 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. -- Jérôme Nicolle

Op 20 jun 2011, om 23:24 heeft Tony Finch het volgende geschreven:

On 20 Jun 2011, at 16:26, Jérôme Nicolle <jerome@ceriz.fr> wrote:

...

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.

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. 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

Op 20 jun 2011, om 23:55 heeft John Levine het volgende geschreven:

...

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.

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

2011/6/20 John Levine <johnl@iecc.com>:

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. -- Jérôme Nicolle

2011/6/20 Tony Finch <dot@dotat.at>:

An organization that blocks 90% of spam with no false positives is incredibly useful.

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... -- Jérôme Nicolle

2011/6/20 David Miller <dmiller@tiggee.com>:

OK.  I'll bite.  What particular "internet best practices" are Spamhaus trampling on?

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. -- Jérôme Nicolle 06 19 31 27 14

2011/6/21 Tony Finch <dot@dotat.at>:

Spamhaus. And none of your complaints apply to them.

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. -- Jérôme Nicolle

Hi Jason, On Mon, Jun 20, 2011 at 9:06 AM, Jason Baugher <jason@thebaughers.com> wrote:

Did everyone miss that the customer didn't request a /24, they requested a "/24s worth in even more dis-contiguous blocks". I can only think of one reason why a customer would specifically ask for that. They are concerned that they'll get blacklisted. They're hoping if they do, it will be a small block of many rather than one entire block.

When customers make strange requests without giving a good explanation, I have to assume they're up to something.

Jason

They provided an explanation, describing how the IPs were going to be used. Yes, part of it does have to do with being blocked, which *definitely* concerns me. One thing they do say is that they need several IPs per block to assign to their MTAs to handle such a large amount of email (3 to 5 million per day). Being primarily focused on layers 1 through 4, I don't have an incredible amount of experience with high volume email server configuration, so I have no idea if they are feeding me a line of BS or not. 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. Thanks, steve

On Mon, 20 Jun 2011 09:26:30 EDT, Steve Richardson said:

*definitely* concerns me. One thing they do say is that they need several IPs per block to assign to their MTAs to handle such a large amount of email (3 to 5 million per day). Being primarily focused on layers 1 through 4, I don't have an incredible amount of experience with high volume email server configuration, so I have no idea if they are feeding me a line of BS or not.

It's BS. 5M a day is only about 60 per second, not at all a problem for a single IP address running properly configured SMTP software. For comparison, in the mid-90s, I was moving 1M RCPT TO's a day (and probably half that number of envelopes) on a Listserv host using Sendmail on an IBM RS6000-220 - a whole whopping 66MZ Power 604E processor and something like 64M of RAM (The same basic firepower as an old Apple 6600 Mac, if you remember them...) Doing 10M messages a day on a single box is *easy* these days - the hardest part is getting a disk subsystem that survives all the fsync() beating most MTAs like to dish out....

On Mon, Jun 20, 2011 at 09:26:30AM -0400, Steve Richardson wrote:

Hi Jason,

On Mon, Jun 20, 2011 at 9:06 AM, Jason Baugher <jason@thebaughers.com> wrote:

...

Did everyone miss that the customer didn't request a /24, they requested a "/24s worth in even more dis-contiguous blocks". I can only think of one reason why a customer would specifically ask for that. They are concerned that they'll get blacklisted. They're hoping if they do, it will be a small block of many rather than one entire block.

When customers make strange requests without giving a good explanation, I have to assume they're up to something.

Jason

They provided an explanation, describing how the IPs were going to be used. Yes, part of it does have to do with being blocked, which *definitely* concerns me. One thing they do say is that they need several IPs per block to assign to their MTAs to handle such a large amount of email (3 to 5 million per day). Being primarily focused on layers 1 through 4, I don't have an incredible amount of experience with high volume email server configuration, so I have no idea if they are feeding me a line of BS or not.

I've worked at a company that did managed services (including the pipe and address range) of a "legitimate" bulk mailer[1], and the logic provided to you is "legit", as far as it goes -- that is to say, what they're saying is probably why they really want the space (whether it's a legitimate justification for the allocation of IP space as per current policies is a different matter). Basically, what your customer wants is to evade big e-mail providers' anti-spam measures. From their perspective, of course, I'm sure they think they're doing the "right thing", and the people they're delivering to really, really want this e-mail, and it's just the nasty e-mail provider getting in the way. As I understand it, a common technique at these big providers is to have reputation for IP addresses by spamminess, as an element of the overall determination of whether a particular e-mail is spam. If an address doesn't have a reputation (yet), then it's rate limited, to limit the damage that a new spammer can do before the e-mail provider gets feedback (from users) about whether the e-mail they're getting is spam or not. This reputation score (presumably) extends to the /24 (and probably, to a lesser extent, the WHOIS block, but I'm not as confident about that bit). What makes me think you're being scammed is that, for all the troubles we had with our customer, they never needed more address space once they'd gotten a good reputation for their initial allocation. Maybe my customer just didn't grow as much as yours did, so their spamcannon didn't need any more barrels. Still, I'm led to believe that once an IP address has good reputation, it should be effectively unlimited, so if they need more addresses it's because the current ones don't have real good rep...

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.

You are correct; as far as I know ARIN doesn't take those as valid justifications if you need to go back to them for more space, so you can't either. At this point they've admitted to you that they're shitting on your good name, and setting you up for headaches down the line (dealing with complaints from people who don't like their spam, having to clean up the IP addresses they discard when they're useless (or they leave). In techie utopia, you'd be able to sting them a fairly hefty surety to cover the costs associated with cleaning up their shit -- and then tell them that the IP addresses they've already got are enough, and if they need more capacity, they should clean up the addresses they've got. In reality, though, unless you've got management with a far more cavalier attitude to revenue than mine did, they won't do anything to piss off a customer who is, in their eyes, quite the cash cow. I'm mildly surprised that you got to evaluate their address request to the degree you have; I predict that any attempts to actually deny them more space (let alone extract additional compensation for their destruction of your resources) will be overridden by management. - Matt [1] I use scare quotes because as far as I'm concerned, if your business model is based on sending lots of e-mail, sooner or later you're going to be sending spam because that's what makes you the money. If you didn't personally collect the addresses, you're in for a world of hurt, and if you don't know that, you don't deserve to be in the business of bulk e-mail, and if you do know that, then at best you're a spammer-by-proxy. -- Q: Why do Marxists only drink herbal tea? A: Because proper tea is theft. -- Chris Suslowicz, in the Monastery

On 6/20/11 5:44 AM, Steve Richardson wrote:

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. Bear in mind that "legitimate" in this context is referring to the justification itself, not their business model.

Then just give them /64s randomly from under a single /48. ;) ~Seth

On Jun 20, 2011, at 5:52 27PM, John Levine wrote:

...

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.

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

On Jun 20, 2011, at 10:22 45PM, John R. Levine wrote:

...

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.

Then take out the developer net (or make it a VPN) but the rest remains. --Steve Bellovin, https://www.cs.columbia.edu/~smb

On Mon, Jun 20, 2011 at 5:30 PM, Bret Clark <bclark@spectraaccess.com>wrote:

On 06/20/2011 08:13 AM, Steve Richardson wrote:

...

What I'd like to know is whether there is a legitimate use for so many addresses in discontiguous networks besides spam? I am trying my best to give them the benefit of the doubt here, because they do work directly with Spamhaus to not be listed (I realize reasons on both sides why this could be) and searches on Google and spam newsgroups for their highest traffic email domains yield next to nothing, given the amount of email they say they send out.

Well, not so sure I would worry about legit or not legit use...while ISP's are looked at being the police, legally law enforcement are the ones to pursue illegal use. But it sounds like you've done you're home work and they sound legit. Have them fill out an IP Justification form (as ARIN requires i) and go from there. I wouldn't worry about providing them the /24. Personally I would charge them for the /24 too, makes users think twice about the need for a block that large.

Well its my responsbility (being an ISP) to know whether it is legit or not, because if it is legitimate than it will take My ASN to pollute the internet because I don't see if the customer has its own ASN. My reputation will be at stake because I failed to recognize the difference between policing or doing my business the right way.. Best Wishes, Aftab A. Siddiqui