Re: Arrogant RBL list maintainers
on Wed, Dec 16, 2009 at 09:27:06PM -0500, Mike Lieman wrote: ...and if people used static and dynamic keywords in DNS as I suggested in my previously mentioned draft, What are the words for static and dynamic in Lower Sorbian? I was bored so I looked them up. :-) dynamic: dynamika static: statik Dynamic was easy, translate to German dynamik, then to Lower Sorbian. Static doesn't seem to translate directly (a translation for statische wasn't in the online dictionary I found, but statik was). Either way, it's actually pretty close to English. But the point stands; some synonyms for static tokens from around the world: biz bus client /cliente commercial / commercio corp corporate corporativo cust ded dedicated emp / empresa fija (South America) fix fixee (FR) fixo (PT-BR) fx (JP, often used with bflets) sta / stat / static and some for dynamics: da dhcp dia dial dinamic (South America) dip du / dup dyn dynamic / dynamicip pool res And again, that doesn't even begin to address the mixins like resnets and NATs and other weirdnesses that lie outside this simplistic dichotomy. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/
Re: Arrogant RBL list maintainers
dynamic: dynamika static: statik One wonders how this will be handled when the flood of non-Latin domains starts. Are these RBL maintainers really going to figure out how many different ways there are to say the (English/Latin) equivalent of static in Chinese, Cyrillic, Swahili, etc. Cheers, Michael Holstein Cleveland State University
Re: Arrogant RBL list maintainers
On 16/12/2009 06:12, James Hess wrote: On Tue, Dec 15, 2009 at 11:30 PM, Adam Armstrongli...@memetic.org wrote: personally, i'd recommend not being a dick and setting valid *meaningful* reverse dns for things relaying mail. Many sites don't use names that will necessarily be meaningful to an outsider. Sometimes the non-meaningful name is the actual hostname and the _only_ name that machine is known by, even if the name appears generic or contains an IP. Host naming is a matter of local network policy, and the RFCs that pertain to hostnames specify syntax requirements only. Some sites might want to avoid certain meaningful RDNS entries since spammers, hackers, and other abusive users that scan IP ranges can utilize the RDNS to facilitate their activities. All reverse DNS information is in the hands of the enemy. For example, when spammers' IP scanning efforts find that an IP address reverses to mail.example.com the spammer will know to try @example.come-mail addresses for their dictionary-based brute-force spamming. On the other hand, if the MTA's IP reverses to something like a152.x.example.net. As is common for many domains. Spammers coming in by scanning large ranges of IPs, have no pointer to report the mailserver they discovered is @example.com inbound (or outbound) mail. The 1970s called and asked for its security policy back :( I would have thought that asking for the MXes for example.com would have told them what the inbound mailserver is... adam.
Re: Arrogant RBL list maintainers
Wouldn't SPF ( RFC 4408) tell people more about where the real mailservers are than some half-baked idea of trying to enforce what hostnames should look like? What's the word for 'mail server' in Lower Sorbian, and does your algorithm properly detect it in a hostname? See the problem here? On Wed, Dec 16, 2009 at 6:49 AM, Adam Armstrong li...@memetic.org wrote: On 16/12/2009 06:12, James Hess wrote: On Tue, Dec 15, 2009 at 11:30 PM, Adam Armstrongli...@memetic.org wrote: personally, i'd recommend not being a dick and setting valid *meaningful* reverse dns for things relaying mail. Many sites don't use names that will necessarily be meaningful to an outsider. Sometimes the non-meaningful name is the actual hostname and the _only_ name that machine is known by, even if the name appears generic or contains an IP. Host naming is a matter of local network policy, and the RFCs that pertain to hostnames specify syntax requirements only. Some sites might want to avoid certain meaningful RDNS entries since spammers, hackers, and other abusive users that scan IP ranges can utilize the RDNS to facilitate their activities. All reverse DNS information is in the hands of the enemy. For example, when spammers' IP scanning efforts find that an IP address reverses to mail.example.com the spammer will know to try @example.come-mail addresses for their dictionary-based brute-force spamming. On the other hand, if the MTA's IP reverses to something like a152.x.example.net. As is common for many domains. Spammers coming in by scanning large ranges of IPs, have no pointer to report the mailserver they discovered is @example.com inbound (or outbound) mail. The 1970s called and asked for its security policy back :( I would have thought that asking for the MXes for example.com would have told them what the inbound mailserver is... adam.
Re: Arrogant RBL list maintainers
On Wed, Dec 16, 2009 at 12:12:22AM -0600, James Hess wrote: Many sites don't use names that will necessarily be meaningful to an outsider. Then they should expect issues with mail acceptance by outsiders. Some sites might want to avoid certain meaningful RDNS entries since spammers, hackers, and other abusive users that scan IP ranges can utilize the RDNS to facilitate their activities. This is nonsense. RDNS/DNS naming choices are a trivial obstacle to spammers et.al. who went over this speed bump at 70 MPH years ago and have been accelerating ever since. This kind of security-by-obscurity tactic is far more likely to draw their attention than evade it, as any site using it has in effect run up a large flag with we don't understand security basics written on it and thus made itself an attractive target. ---Rsk
Re: Arrogant RBL list maintainers
On Wed, Dec 16, 2009 at 7:06 AM, Mike Lieman mikelie...@gmail.com wrote: Wouldn't SPF ( RFC 4408) tell people more about where the real mailservers are than some half-baked idea of trying to enforce what hostnames should look like? What's the word for 'mail server' in Lower Sorbian, and does your algorithm properly detect it in a hostname? See the problem here? Mike, If you really want to know, download the spamassassin code and start reading. You'll find both the answers to how names are checked and rankings of empirical effectiveness. On Wed, Dec 16, 2009 at 7:15 AM, Rich Kulawiec r...@gsp.org wrote: This is nonsense. RDNS/DNS naming choices are a trivial obstacle to spammers et.al. who went over this speed bump at 70 MPH years ago and have been accelerating ever since. This kind of security-by-obscurity tactic is far more likely to draw their attention than evade it, as any site using it has in effect run up a large flag with we don't understand security basics written on it and thus made itself an attractive target. Rich, This depends on the spammer and his methodology. A significant fraction of spam, perhaps the majority, originates from hijacked user PCs. For this subset of spam sources, adjusting the RNDS is an insurmountable obstacle. There's no magic bullet for stopping spam but there are a lot of heuristics which eliminate a useful fraction. Using the RDNS to make an educated guess about whether a particular machine's owners intend it to operate as a mail server is such a heuristic. If you must whine about antispam techniques, whine about something important. Filtering by IP address in a bazillion private block and permit lists makes it very hard for large legitimate mailing list operators to renumber when changing ISPs. The new IP address isn't on any of the permit lists yet and it may be on block lists as a result if its prior user. This pushes list operators towards PI, BGP and consuming expensive real estate in your routers for a protocol which is otherwise relatively trivial to renumber. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Arrogant RBL list maintainers
On Wed, 16 Dec 2009 07:06:55 EST, Mike Lieman said: What's the word for 'mail server' in Lower Sorbian, and does your algorithm properly detect it in a hostname? See the problem here? When the hostname at that IP address is exactly one incremented character different than the preceding address, and one decremented character different than the following address, and that pattern holds across a /24, they're probably not mail servers. Nobody has 256 'frzzmabs-1'..'frzzzmabs-256' servers in the same /24 for *anything* user-facing. pgp1v1l1qkWiJ.pgp Description: PGP signature
Re: Arrogant RBL list maintainers
valdis.kletni...@vt.edu wrote: When the hostname at that IP address is exactly one incremented character different than the preceding address, and one decremented character different than the following address, and that pattern holds across a /24, they're probably not mail servers. Nobody has 256 'frzzmabs-1'..'frzzzmabs-256' servers in the same /24 for *anything* user-facing. Mental note, don't setup 253 generic servers in the same /24 for dynamic allocation and usage by the load balancers and proxy servers. Check. Jack
Re: Arrogant RBL list maintainers
On Wed, 16 Dec 2009, James Hess wrote: On Tue, Dec 15, 2009 at 11:30 PM, Adam Armstrong li...@memetic.org wrote: personally, i'd recommend not being a dick and setting valid *meaningful* reverse dns for things relaying mail. Many sites don't use names that will necessarily be meaningful to an outsider. Sometimes the non-meaningful name is the actual hostname and the _only_ name that machine is known by, even if the name appears generic or contains an IP. Host naming is a matter of local network policy, and the RFCs that pertain to hostnames specify syntax requirements only. You can implement your local network policies to use mail server hostnames which match generic looking strings, and other operators can implemenent their local network policies to refuse mail from hosts which match generic looking hostname strings. In the battle of local network policies, you will always lose because there are always more other networks. If you want to interoperate with other operator's networks, you will probably need to follow more than just your local network policies. Folks have said what the problem is, and how to fix it. If the original poster wants to stand on principles, he will continue to have problems getting other networks to accept connections from his mail servers. On the other hand, if he wants to fix this mail acceptance problem, he now knows what he needs to do. The great thing about RFCs is anyone can write one. The bad thing about RFCs is anyone can write one.
Re: Arrogant RBL list maintainers
Ronald Cotoni wrote: Very true. At my old place of employment a DUHL listed an ip since before my previous company existed. For some reason, when we obtained it, they still listed it. Sounds like a bug in the DUHL bot to me. Also the standard makes a lot of sense. You may be on Trend Micros DUHL by following the rules on SORBS DUHL and vica versa. Makes life a pain. If you set non generic rDNS or generic following their suggestions you'd be removed from the SORBS DUHL pretty much automagically (a request initiates the rescan) - there is manual stuff on my behalf but nothing for a requestor to worry about. The only reason you wouldn't be is if you had a listing and too short a TTL for the robot to accept the delisting request... A reply would result in a human (usually me) processing netblocks of /24 or greater (greater as in number of IPs) providing the TTLs were not shorter than 1 hour. That is well documented in many places. Seems according to their rules if you follow the SORBS DUHL rules you'll also be delisted from them. To add my $0.02 I agree with many of the replies... If you have one generic pattern for a /16 you either: Don't care to setup DNS. Don't know how to setup DNS. Don't care what's in the netblock. Don't have the competency to run a network/mailserver/dnsserver/insert what ever. In all the cases above I would not want your mail as it is 99.999% likely to be abusive in nature (spam, viruses etc.) Oh and many know I don't care if you are Peer1, Level 3 or Joe Blows Backyard VISP in outback Australia, you're all the same to me, you should all have competent people on staff, the only thing that changes between you is the number of *your* customers, and the amount you charge. Similar issues apply when looking at *.edu's vs *.com's, *.au's, and *.mt's. Just because you come from a certain country or certain type of establishment, doesn't make you different, it's only the number of people you service, you should still have competent staff. If you don't have enough staff that's not my problem (nor the rest of the world's) though it usually results in our problem when abuse starts flowing. I know most here are the admins and staff, so sorry if it sounds like I'm having a go at you guys, but really most on this list are the competent admins, a minority being people learning (nothing wrong with that!) but unfortunately there are some who are not and they don't care that they are not. I know that makes me an arrogant w***er, or another one of those Arrogant RBL list maintainers but think about it, and think about the following... Would you like to be prioritised down the queue because someone else was supposedly more important? . What happens to the poor mum and dad VISP in Somalia that never gets delisted because Telstra is logging 100's of tickets every day because their super size and constant rotating listings? . What happens if Telstra have a single IP blocked and Sprint come along and request delisting for a spamming customer's netspace they once hosted? Should we (RBL Maintainers, SORBS or anyone else) push the largest ISP in Australia out of the way for the bigger USA based Sprint? If not should we push the mum and dad operation out of the way for Telstra? . The obvious answer is if you have signed SLAs then you should adhere to those SLAs as a minimum and give better service if time allows... Hands up those who have an SLA (free or not) with an RBL maintainer... I don't expect to see any hands... . my answer to the question above is a very obvious take every issue in order, and if you get a super high priority issue, deal with it if necessary, but size of the ISP (or size of the admin's d***) is _not_ the prioritising factor. Note: Names chosen and mentioned above have no baring on any current abuse level or any logged issue, they are for example only. I don't want answers to the questions, I know some will post to the list or me regardless... it's stuff for *you* to think about when dealing with organisations such as RBLs.. especially when they are volunteer run. A little example about arrogance when it comes to ISPs... I know at least one member of this list (an ISP) has posted to every address in GFI in the last few days that they could think of (including the CEOs email) because their spamming netblocks have not been delisted. They have previously stated they would not deal with SORBS, so what changed, well as they found out in an email, nothing, they still need to log a support ticket, and their out of band request just pushed them down the queue. Sad thing based on their ticket ID, had they waited another 2 hours they would have been answered, now they have 112 manual processing tickets before theirs. I'm sure they'll guess who they are, I'd advise them to be patient or they might push themselves down further. ... and then of course there are some RBL
Re: Arrogant RBL list maintainers
Mikael Abrahamsson wrote: On Wed, 9 Dec 2009, Frank Bulk wrote: Two sides of an SP's coin: I want to maximize my e-mail servers' deliverability, so I make sure those have appropriately named PTRs and make sure that outbound messages aren't spammy; I also want to restrict The point he was trying to make is that there is no standard for what those appropriately named PTRs should look like. He has forward/reverse that is perfectly ok according to standard (forward/reverse matches) and if he had a automatic dictionary for naming those IPs instead of putting the IPs there, things would be different. If people want to make standards on how to put information into DNS for RBL use, they should take it to the IETF and make a standard out of it, not just ad-hoc I did.. a number of people went out of their way to bury it. One of who would do anything to bury anything SORBS does (I think we all know who that was.) create something of their own and expect everybody else to conform. If there is an industry standard (which the replies here seem to indicate), that should be written down and standardized by the people who actually make money out of it, in this case Trend Micro. This would remove the problem of having to maintain tens or hundred points of contacts for what is dynamic dialup space which is the problem right now as there are a lot of RBLs to deal with. Creating a standard on what to put in WHOIS/DNS for dynamic/static/infrastructure would make a lot of sense, seems nobody is doing it though. 100% with you ...and if people used static and dynamic keywords in DNS as I suggested in my previously mentioned draft, there would be *NO NEED* for DUL/DUHL/PBL lists at all because people could create a very simple set of patterns to match and therefore the RBLs would be unneccessary.. (and it would save me about 10 hours a day, every day of the week, every week of the year!) Currently I have a few 100 patterns and I know another on this list has more like the region of 10k patterns to do what in reality one should be able to do in 2 (10 at the most!). At 10k patterns it becomes a lot cheaper to use DUL/DUHL/DYNABLOCK to block dynamics, does anyone wonder why people do? Regards, Michelle
Re: Arrogant RBL list maintainers
Please reply to the list, not me and the list! Sven Olaf Kamphuis wrote: thing is that it's illegal to maintain a database with personal details which ip addresses according to various german courts are (don't ask.. mmk? ;) ofcourse we all know ip addresses identify nodes on a network, not persons, but the germans seem to mainain a different view on this, despite us isps being the owners of the internet and not the german government ;). therefore we are not even -allowed- to cooperate with trend micro *grin* sometimes laws really come in handy you know ;) Based on what you say there, then the RIPE whois database cannot contain the information either because it to would be maintaining a database of personal details... Love to hear the legal battle on that one! grin Michelle
Re: Arrogant RBL list maintainers
On Wed, Dec 16, 2009 at 5:21 AM, valdis.kletni...@vt.edu wrote: On Wed, 16 Dec 2009 07:06:55 EST, Mike Lieman said: What's the word for 'mail server' in Lower Sorbian, and does your algorithm properly detect it in a hostname? See the problem here? When the hostname at that IP address is exactly one incremented character different than the preceding address, and one decremented character different than the following address, and that pattern holds across a /24, they're probably not mail servers. Nobody has 256 'frzzmabs-1'..'frzzzmabs-256' servers in the same /24 for *anything* user-facing. You clearly haven't set up webmail farms to handle half a billion accounts before. ^_^; We name our (many thousands of) webmail front end boxes as webXYYZZ.mail.$site.yahoo.com, so for cluster 3, farm 57, you end up with a string of hosts all in a row like web35701.mail.mud.yahoo.com web35702.mail.mud.yahoo.com web35703.mail.mud.yahoo.com web35704.mail.mud.yahoo.com web35705.mail.mud.yahoo.com web35706.mail.mud.yahoo.com web35707.mail.mud.yahoo.com web35708.mail.mud.yahoo.com ...etc... Take a look at the reverse DNS for the entire 66.163.178.0/23 subnet; you'll find that when you're doing things at large scale, you can't really get away from having sequentially numbered reverse DNS entries all in a row, exactly as you seem to think Nobody has. :/ Matt
Re: Arrogant RBL list maintainers
Matthew Petach wrote: Take a look at the reverse DNS for the entire 66.163.178.0/23 subnet; you'll find that when you're doing things at large scale, you can't really get away from having sequentially numbered reverse DNS entries all in a row, exactly as you seem to think Nobody has. :/ Of course not. Everyone is small like me. Having more than 10 mail servers? How dare you use incremental numbers on such a large scale! Jack
Re: Arrogant RBL list maintainers
* matt...@sorbs.net (Michelle Sullivan) [Wed 16 Dec 2009, 17:41 CET]: [..] . The obvious answer is if you have signed SLAs then you should adhere to those SLAs as a minimum and give better service if time allows... Hands up those who have an SLA (free or not) with an RBL maintainer... I don't expect to see any hands... How much would you charge a company for it to get taken off immediately after it hits your list? -- Niels.
Re: Arrogant RBL list maintainers
Niels Bakker wrote: * matt...@sorbs.net (Michelle Sullivan) [Wed 16 Dec 2009, 17:41 CET]: [..] . The obvious answer is if you have signed SLAs then you should adhere to those SLAs as a minimum and give better service if time allows... Hands up those who have an SLA (free or not) with an RBL maintainer... I don't expect to see any hands... How much would you charge a company for it to get taken off immediately after it hits your list? Nothing. I don't believe in such a practice because it would be fraught with the danger of being accused of pandering to spammers, extortion and blackmail. Its bad enough requiring a donation to charity for expedited delisting of just the spam DB entries. As for an SLA the only type I would consider (hypothetically) is a we will provide a phone/pager number for you to call or we will answer your ticket by email within x hours type SLA. In either case there would be a clause the states clearly that the SLA does not provide any sort of guaranteed delisting. Michelle PS: Have been asked to take this off list by someone who didn't identify themselves as a list manager, but they did it politely and I respect that, so all future replies from me to this thread will be offlist. Please feel free to reply to me *offlist*. Thanks.
Re: Arrogant RBL list maintainers
on Wed, Dec 16, 2009 at 06:01:51PM +0100, Michelle Sullivan wrote: ...and if people used static and dynamic keywords in DNS as I suggested in my previously mentioned draft, there would be *NO NEED* for DUL/DUHL/PBL lists at all because people could create a very simple set of patterns to match and therefore the RBLs would be unneccessary.. (and it would save me about 10 hours a day, every day of the week, every week of the year!) Currently I have a few 100 patterns and I know another on this list has more like the region of 10k patterns to do what in reality one should be able to do in 2 (10 at the most!). At 10k patterns it becomes a lot cheaper to use DUL/DUHL/DYNABLOCK to block dynamics, does anyone wonder why people do? 10K? Ha! Try 47086, as of the most recent release. Of course, those are all fully-qualified, and we deal with a much broader spectrum of classifications than just 'dynamic/static', because that a host is static doesn't mean much these days. As for the idea that you could make do with 2 patterns, as I've said elsewhere this is incredibly wishful thinking and Anglocentric, to boot, but the principle behind proper labeling is sound in a general sense. It just doesn't happen to be that way in the real world, which is full of non-English speaking netadmins and varieties of assignment beyond a simplistic dynamic/static split. For instance, resnets, which are usually statically assigned to a room, but not a given computer from one semester to another. Or my dynamic cable modem IP, which I've had for years, through four changes in our static office numbering/naming (three moves, four providers). Or NATs, which are static but allow dynamic users behind them to emit and receive traffic. Or Web hosts, which have the shared reputation of dynamics (on shared hosting, anyway). Or cloud computing, which is a dog's breakfast of mixed static (elastic) and dynamically instantiated entities (though some simple efforts to clarify which are which in the PTRs would help that somewhat). Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/
Re: Arrogant RBL list maintainers
Hi, On Thu, 2009-12-10 at 16:55 +, Sven Olaf Kamphuis wrote: thing is that it's illegal to maintain a database with personal details which ip addresses according to various german courts are (don't ask.. mmk? ;) ofcourse we all know ip addresses identify nodes on a network, not persons, but the germans seem to mainain a different view on this, despite us isps being the owners of the internet and not the german government ;). therefore we are not even -allowed- to cooperate with trend micro *grin* You're Swedish, not German. So that doesn't really apply to you. I'm pretty sure that if you just update the WHOIS and say it's static assignments, that they will in fact remove you. Your network hosts e-trash anyway (thepiratebay), so I can hardly blame them for assuming everything on your network is rotten. sometimes laws really come in handy you know ;) Sometimes *valid* laws come in handy. Citing laws that do not, at all, apply to you, is not handy. In fact if you are citing it in some circumstances, it is fraud. William
Re: Arrogant RBL list maintainers
...and if people used static and dynamic keywords in DNS as I suggested in my previously mentioned draft, What are the words for static and dynamic in Lower Sorbian?
Re: Arrogant RBL list maintainers
On Wed, 16 Dec 2009 09:21:42 PST, Matthew Petach said: You clearly haven't set up webmail farms to handle half a billion accounts before. ^_^; Yes, but we all already know who those 800 pound gorillas are. If you're doing automagic handling of this sort of DNS data, and not using a regexp to prevent auto-blocking any of the 800 pound gorillas... :) pgpAYbdi2iWe1.pgp Description: PGP signature
Re: Arrogant RBL list maintainers
[ Note: you're not talking about the RBL. You're talking about a DNSBL or RHSBL, which are generic terms. The RBL is a specific DNSBL and, as far as I know, does not have a listing policy related to this discussion. ] On Wed, Dec 09, 2009 at 03:18:47PM +, Sven Olaf Kamphuis wrote: because they just assume that working, rfc compliant, reverse dns that just-so-happens to be automatically generated would indicate dynamic ip space.. It has long since become a best practice in mail server operations to pre-emptively blacklist all such space on sight. This is common knowledge among everyone who's kept pace with the field, and is an entirely appropriate reaction to what's sometimes called the rise of the zombies. Real mail servers have non-generic, matching forward and reverse DNS with real hostnames. The farther hostnames move from that, the more problems can be expected. Nobody particularly likes this, as the work necessary in compiling such lists is onerous. But it is one of the most effective (in terms of FP and FN rates as well as resource costs) anti-spam measures available. ---Rsk
Re: Arrogant RBL list maintainers
On 09/12/2009 15:18, Sven Olaf Kamphuis wrote: a84-22-xx-xx.cb3rob.net. as it's RFC complient and we cannot be fucked to haha. and what precisely did you expect? that's not really what most people would consider valid reverse dns for a mail relay. (operational practice often beats RFC where they exist, and more often than not fills in where they don't). personally, i'd recommend not being a dick and setting valid *meaningful* reverse dns for things relaying mail. (i also notice that in later replies you claim that they're breaking eu data laws, but you seem to have bleeted on enough about how you think data is something that should be in the public domain, so you can download movies, err i mean, be like totally free man.) adama.
Re: Arrogant RBL list maintainers
On Tue, Dec 15, 2009 at 11:30 PM, Adam Armstrong li...@memetic.org wrote: personally, i'd recommend not being a dick and setting valid *meaningful* reverse dns for things relaying mail. Many sites don't use names that will necessarily be meaningful to an outsider. Sometimes the non-meaningful name is the actual hostname and the _only_ name that machine is known by, even if the name appears generic or contains an IP. Host naming is a matter of local network policy, and the RFCs that pertain to hostnames specify syntax requirements only. Some sites might want to avoid certain meaningful RDNS entries since spammers, hackers, and other abusive users that scan IP ranges can utilize the RDNS to facilitate their activities. All reverse DNS information is in the hands of the enemy. For example, when spammers' IP scanning efforts find that an IP address reverses to mail.example.com the spammer will know to try @example.come-mail addresses for their dictionary-based brute-force spamming. On the other hand, if the MTA's IP reverses to something like a152.x.example.net. As is common for many domains. Spammers coming in by scanning large ranges of IPs, have no pointer to report the mailserver they discovered is @example.com inbound (or outbound) mail. Since the RDNS domain is different, and in fact generic, which helps avoid assisting the spammer in identifying the IP as an inbound mail server. -- -J
Re: Arrogant RBL list maintainers
Security by obscurity, in this day and age? :) On Wed, Dec 16, 2009 at 11:42 AM, James Hess mysi...@gmail.com wrote: As is common for many domains. Spammers coming in by scanning large ranges of IPs, have no pointer to report the mailserver they discovered is �...@example.com inbound (or outbound) mail. Since the RDNS domain is different, and in fact generic, which helps avoid assisting the spammer in identifying the IP as an inbound mail server. -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Arrogant RBL list maintainers
On Wed, 9 Dec 2009, Michael Holstein wrote: | Their initial email said : | | [snip] | Trend Micro Notification: 137.148.0.0/16 added to DUL | [snip] Oh dear. I can see why many sites that once used MAPS now don't :-(
Re: Arrogant RBL list maintainers
On Thu, 10 Dec 2009, Chris Edwards wrote: On Wed, 9 Dec 2009, Michael Holstein wrote: | Their initial email said : | | [snip] | Trend Micro Notification: 137.148.0.0/16 added to DUL | [snip] Oh dear. I can see why many sites that once used MAPS now don't :-( It isn't just idiocy like this thread. They never expire entries from the RBL, even when IP address space changes hands. The most stupid thing is that they will not accept bug reports from their customers, insisting that they come from the sender (not recipient). WTF?! Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
Re: Arrogant RBL list maintainers
On Thu, Dec 10, 2009 at 8:20 AM, Tony Finch d...@dotat.at wrote: On Thu, 10 Dec 2009, Chris Edwards wrote: On Wed, 9 Dec 2009, Michael Holstein wrote: | Their initial email said : | | [snip] | Trend Micro Notification: 137.148.0.0/16 added to DUL | [snip] Oh dear. I can see why many sites that once used MAPS now don't :-( It isn't just idiocy like this thread. They never expire entries from the RBL, even when IP address space changes hands. The most stupid thing is that they will not accept bug reports from their customers, insisting that they come from the sender (not recipient). WTF?! Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. Very true. At my old place of employment a DUHL listed an ip since before my previous company existed. For some reason, when we obtained it, they still listed it. Sounds like a bug in the DUHL bot to me. Also the standard makes a lot of sense. You may be on Trend Micros DUHL by following the rules on SORBS DUHL and vica versa. Makes life a pain.
RE: Arrogant RBL list maintainers
Creating a standard on what to put in WHOIS/DNS for dynamic/static/infrastructure would make a lot of sense, seems nobody is doing it though. As previously noted in this thread, msulli...@sorbs did a fairly good job of documenting this in an RFC draft. I'd say its still the primary goto to point people at for how to do things the right way. http://tools.ietf.org/html/draft-msullivan-dnsop-generic-naming-schemes-00 sam
Re: Arrogant RBL list maintainers
On 12/10/2009 7:29 AM, Sam Hayes Merritt, III wrote: As previously noted in this thread, msulli...@sorbs did a fairly good job of documenting this in an RFC draft. I'd say its still the primary goto to point people at for how to do things the right way. http://tools.ietf.org/html/draft-msullivan-dnsop-generic-naming-schemes-00 The time to pursue something like this in the IETF is when there is a substantial industry consensus that it is the right approach and that the folks supporting it will actually use it. Are those of you who have participated in this thread willing to conform to the model specified in this draft? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Arrogant RBL list maintainers
Is your network setup so chaotic that you don't know what address chunks are allocated by DHCP or PPP? Aww .. stop it, just stop. I could send the .vsd of the network overview to everyone and there'd still be someone that'd chime in and say Ha! you moron .. you used ORANGE lines to interconnect things, nobody ever does it that way. We've drifted wy O/T here. But to answer a few questions : Maybe you misunderstood them? What's trunking a VLAN across the core for a printers subnet have to do with anything? They were asking you to tell them which of your subnets are dynamic and which are static, presumably so they could remove your /16 and list just the bits of it that really are dynamic or otherwise appropriate for their list. We break the /16 up into /23s and /24s (and a few /22s) based on building/router and security class (along with a bunch of 1918 space that we only NAT internally). What would be more chaotic? .. further dividing a /24 just to put static stuff within a (^2) boundary? Like many places, we run seperate internal and external DNS .. when a user requests a static IP, they can opt to make it external, but few do, since we point out that when they do that, they loose the anonymity of the generic rDNS. An internal DNS entry might look like : lastname-modelnumber.router.building.csuohio.edu While the external entry might look like : csu-137-148-19-3.csuohio.edu People that need remote access use our WebVPN (or client VPN) and can then use the internal DNS to find their machine. There's little motivation to create a static unless it's a server or printer. Does it matter if they label your non e-mail server IPs as dynamic space, and therefore put it on their DUL? No, not at all. As I've said all along, my beef was that as a mail-abuse DNSBL provider, they were taking issue with our naming scheme for things that had nothing to do with email. As several have already recognized, we are doing the mail part correctly .. there are exactly 4 IPs that are permitted to send mail to the Internet .. FOUR of them, all of which have proper A=PTR, SPFv1 records, abuse@ contacts, etc. /thread Regards, Michael Holstein Cleveland State University
best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
on Thu, Dec 10, 2009 at 09:29:15AM -0600, Sam Hayes Merritt, III wrote: Creating a standard on what to put in WHOIS/DNS for dynamic/static/infrastructure would make a lot of sense, seems nobody is doing it though. As previously noted in this thread, msulli...@sorbs did a fairly good job of documenting this in an RFC draft. I'd say its still the primary goto to point people at for how to do things the right way. http://tools.ietf.org/html/draft-msullivan-dnsop-generic-naming-schemes-00 There's also Dan Senie and Andrew Sullivan's draft: http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06 ...which basically boils down to if you're not using rDNS to project a clear picture of the intended uses of a given IP, you're screwed. Or maybe that's just my read. I've written up my thoughts on naming and why it matters in a series of posts on my Web site; this is the cumulative wisdom acquired after six years or more of collecting and attempting to classify naming conventions worldwide. We're at close to 47K patterns for over 18K domains worldwide, so I think it's safe to say I've seen my share of this stuff and can draw general observations. In a nutshell, if you're not clearly indicating mail sources as mail sources, don't expect great deliverability. If you're running a Web hosting shop and don't have rate-limited outbound smarthosts, expect all your clients' mail to be suspected of being phishing scams. If you run a corporate network that allows unsecured outbound port 25 via NAT, you lose. If you run a university network (or part of one) without clearly distinguishing between server infrastructure and student-use end nodes, you really might want to rethink that. And if you're a consumer ISP that allows both static and dynamic assignments or serves both residential and commercial under the same useless generic naming convention, you are Making It Harder for the rest of us, which is an automatic upgrade path to reflexive blocking of all traffic. Oh, and if it's out of your control or what you consider your responsibility, SWIP it and label it clearly so we can figure out what it is and decide whether we want it as part of our view of the Internet. Keep your whois up to date and indicate if nothing else whether a given block is static or dynamically assigned, residential or corporate. Full archive here: http://enemieslist.com/news/archives/gripes/ Of particular interest, perhaps: http://enemieslist.com/news/archives/2009/06/principles.html http://enemieslist.com/news/archives/2009/06/basic_principle.html http://enemieslist.com/news/archives/2009/06/basic_principle_1.html http://enemieslist.com/news/archives/2009/06/basic_principle_2.html http://enemieslist.com/news/archives/2009/06/a_few_thoughts_1.html http://enemieslist.com/news/archives/2009/07/why_we_suspect.html http://enemieslist.com/news/archives/2009/07/a_passionate_cr.html but the whole archive is full of examples of DNS stupidity, for your enjoyment, and as an expression of years of pent up frustration. ;) Cheers, Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/
Re: Arrogant RBL list maintainers
on Thu, Dec 10, 2009 at 10:48:05AM -0500, Michael Holstein wrote: Like many places, we run seperate internal and external DNS .. when a user requests a static IP, they can opt to make it external, but few do, since we point out that when they do that, they loose the anonymity of the generic rDNS. An internal DNS entry might look like : lastname-modelnumber.router.building.csuohio.edu While the external entry might look like : csu-137-148-19-3.csuohio.edu At least at one point in 2003, you also used, eg finance137-148-212-227.dhcp.csuohio.edu [137.148.212.227] which kindly pointed out that the IP was dynamically assigned (or at least suggested it, I know DHCP can push statics, too). I have the pattern for the csu-n-n-n-n.csuohio.edu naming convention above marked as 'static/lan' - should I have this down as 'natproxy/unknown' instead? Or 'static/unknown'? Or 'static/wan'? I'm a bit confused by what it means to have an internal static public IP, I guess. Or are you saying that they have the option of making their chosen internal name also visible via external DNS lookups, with all IPs being public just not all visible via custom names to the outside? -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
On 12/10/2009 07:54 AM, Steven Champeon wrote: In a nutshell, if you're not clearly indicating mail sources as mail sources, don't expect great deliverability. If you're running a Web hosting shop and don't have rate-limited outbound smarthosts, expect all your clients' mail to be suspected of being phishing scams. If you run a corporate network that allows unsecured outbound port 25 via NAT, you lose. If you run a university network (or part of one) without clearly distinguishing between server infrastructure and student-use end nodes, you really might want to rethink that. And if you're a consumer ISP that allows both static and dynamic assignments or serves both residential and commercial under the same useless generic naming convention, you are Making It Harder for the rest of us, which is an automatic upgrade path to reflexive blocking of all traffic. Oh, and if it's out of your control or what you consider your responsibility, SWIP it and label it clearly so we can figure out what it is and decide whether we want it as part of our view of the Internet. Keep your whois up to date and indicate if nothing else whether a given block is static or dynamically assigned, residential or corporate. I'd say that Mikael Abrahamsson's sentiment (or at least the way I read it) would be a better start: take a step back and ask what the problem is. Naming conventions blah, blah, blah all started from the _lack_ of a standard and trying to educe knowledge from chaos. In other words, a bunch of hacks. Which doesn't work especially well, especially when every RBL has its own hack. If IETF can do something here, which seems plausible, it would be to actually define the problem and _then_ write a protocol to fit the needs of the problem. Maybe it's using DNS, maybe it's not. Maybe it uses naming conventions (ick), probably it does not. But if it were standardized, it would at least be predictable which the current situation manifestly is not. To Crocker's point though: if IETF came up with a way to publish your network's dynamic space (assuming that's The Problem!), would operators do that? Or is this another case where the energy barrier is too high? Mike
Re: Arrogant RBL list maintainers
on Thu, Dec 10, 2009 at 07:43:36AM -0800, Dave CROCKER wrote: On 12/10/2009 7:29 AM, Sam Hayes Merritt, III wrote: As previously noted in this thread, msulli...@sorbs did a fairly good job of documenting this in an RFC draft. I'd say its still the primary goto to point people at for how to do things the right way. http://tools.ietf.org/html/draft-msullivan-dnsop-generic-naming-schemes-00 The time to pursue something like this in the IETF is when there is a substantial industry consensus that it is the right approach and that the folks supporting it will actually use it. Are those of you who have participated in this thread willing to conform to the model specified in this draft? That draft has a few issues; perhaps foremost is the Anglocentric choice of names. Why should a Pole care to name his poczta mail? Or a Brazilian name his correio using an English term? But that's a minor point, and there aren't *that* many variations on mx vs mail vs smtp, etc in non-English languages. If anything, I'd have liked to have seen a more widespread use of the protocol as a canonical name for a box providing service for that protocol, but www's ship sailed a long time ago... M. Sullivan's proposals for the most part, however, conform to the best of current practice as far as I can determine from having looked at several hundred thousand hosts and tens of thousands of naming conventions over the past few years. There are probably ways the proposals could be expanded to cover other edge cases or to conform to current practices (properly naming NATs, VPN hosts, University resnets, vps instead of shared, perhaps, dealing with cloud computing, Web and other proxies). And there are certainly plenty of other network situations that might be covered in a future draft, certainly more than I could describe here. The bottom line is that people *are* using rDNS/PTR naming as a means to help them determine policy. It's not abstract, it's happening. I'd love to see some way to define emission policies for a given netblock that could be queried in real-time, by the receiving services, but I suspect that's a long way off. Until then, clear and informative labeling is the best way to go. Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
on Thu, Dec 10, 2009 at 08:11:18AM -0800, Michael Thomas wrote: I'd say that Mikael Abrahamsson's sentiment (or at least the way I read it) would be a better start: take a step back and ask what the problem is. Well, as I see it, the problem is a widespread and systemic failure to prevent massive abuses from being perpetrated by unauthorized software in the control of entities other than the administrators of those networks and servers in question, resulting in a near-total breakdown of trust in any given unknown host's reputation, resulting in desparate attempts to gain insight into which hosts might be trusted and which not, using what means may be available (naming, whois, DNSBLs, etc.) Naming conventions blah, blah, blah all started from the _lack_ of a standard and trying to educe knowledge from chaos. In other words, a bunch of hacks. Which doesn't work especially well, especially when every RBL has its own hack. Well, I'd like to think my approach (name-based, rather than IP-based) works fairly well, going as it does in the names you give your IPs and whatever other public information may be available, but I understand your frustration with the various approaches used by IP-based DULs; I can also understand the lack of patience on the side of the DUL operators. The situation is a mess. If IETF can do something here, which seems plausible, it would be to actually define the problem and _then_ write a protocol to fit the needs of the problem. Maybe it's using DNS, maybe it's not. Maybe it uses naming conventions (ick), probably it does not. But if it were standardized, it would at least be predictable which the current situation manifestly is not. Like it or not, naming conventions are useful and powerful and widespread. Would you rather have to deal with inbound mail from 134.25.177.41-get-allinone-adsl-and-free-webhosting-for-only-r189.saol.com or 196-200-118.isnigeria or one-of-hosts-our-net.dn.cv.ua [194.146.136.24] or dressless-debate.volia.net [77.123.181.13] or dont-blame-admin-its-a-dsl-pool-251-41.wobline.de or cable-66-103-40-69.clarenville.dyn.personainc.net [66.103.40.69] or 200.72.157.254: pcdibujante2.eiser.local ? To Crocker's point though: if IETF came up with a way to publish your network's dynamic space (assuming that's The Problem!), would operators do that? Or is this another case where the energy barrier is too high? It's not just dynamics, either. Static generic IPs also emit spam and abuse. Finding all the dynamics on the Net would only stop from half to maybe two thirds of the traffic we see, for example. http://enemieslist.com/news/archives/2009/07/why_we_suspect.html Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/
Re: Arrogant RBL list maintainers
I'm a bit confused by what it means to have an internal static public IP internal means behind the firewall (which everything is, transparently). We don't NAT because we don't have to .. the 1918 space is used for stuff we don't want to be routable (like thermostats). that they have the option of making their chosen internal name also visible via external DNS lookups, with all IPs being public just not all visible via custom names to the outside? Correct. When you request a DNS entry, there's a little box on the webform that says external? .. and if you check it, the same entry gets put in the outward-facing DNS (both A and PTR). Otherwise it stays the default csu-x-x-x-x.csuohio.edu, regardless of what it is on the inside. Regards, Michael Holstein Cleveland State Unviersity
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
In message 4b211da6.9000...@mtcc.com, Michael Thomas writes: On 12/10/2009 07:54 AM, Steven Champeon wrote: In a nutshell, if you're not clearly indicating mail sources as mail sources, don't expect great deliverability. If you're running a Web hosting shop and don't have rate-limited outbound smarthosts, expect all your clients' mail to be suspected of being phishing scams. If you run a corporate network that allows unsecured outbound port 25 via NAT, you lose. If you run a university network (or part of one) without clearly distinguishing between server infrastructure and student-use end nodes, you really might want to rethink that. And if you're a consumer ISP that allows both static and dynamic assignments or serves both residential and commercial under the same useless generic naming convention, you are Making It Harder for the rest of us, which is an automatic upgrade path to reflexive blocking of all traffic. Oh, and if it's out of your control or what you consider your responsibility, SWIP it and label it clearly so we can figure out what it is and decide whether we want it as part of our view of the Internet. Keep your whois up to date and indicate if nothing else whether a given block is static or dynamically assigned, residential or corporate. I'd say that Mikael Abrahamsson's sentiment (or at least the way I read it) would be a better start: take a step back and ask what the problem is. Naming conventions blah, blah, blah all started from the _lack_ of a standard and trying to educe knowledge from chaos. In other words, a bunch of hacks. Which doesn't work especially well, especially when every RBL has its own hack. If IETF can do something here, which seems plausible, it would be to actually define the problem and _then_ write a protocol to fit the needs of the problem. Maybe it's using DNS, maybe it's not. Maybe it uses naming conventions (ick), probably it does not. But if it were standardized, it would at least be predictable which the current situation manifestly is not. To Crocker's point though: if IETF came up with a way to publish your network's dynamic space (assuming that's The Problem!), would operators do that? Or is this another case where the energy barrier is too high? Mike The way to do this is to put other data in the ip6.arpa/in-addr.arpa and stop trying to infer things from the PTR records. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
On 12/10/2009 08:38 AM, Mark Andrews wrote: In message4b211da6.9000...@mtcc.com, Michael Thomas writes: To Crocker's point though: if IETF came up with a way to publish your network's dynamic space (assuming that's The Problem!), would operators do that? Or is this another case where the energy barrier is too high? Mike The way to do this is to put other data in the ip6.arpa/in-addr.arpa and stop trying to infer things from the PTR records. Sigh. What is the this to which you refer? The problem space here is what's important. And I think it's worth considering that port 25 isn't the only abuse vector anymore. Mike
Re: Arrogant RBL list maintainers
On 12/10/2009 7:29 AM, Sam Hayes Merritt, III wrote: As previously noted in this thread, msulli...@sorbs did a fairly good job of documenting this in an RFC draft. I'd say its still the primary goto to point people at for how to do things the right way. http://tools.ietf.org/html/draft-msullivan-dnsop-generic-naming-schemes-00 The time to pursue something like this in the IETF is when there is a substantial industry consensus that it is the right approach and that the folks supporting it will actually use it. Are those of you who have participated in this thread willing to conform to the model specified in this draft? no, as having PTR records in dot seperated form could potentially cause confusion with normal ip addresses in case the search domain is the same. we stick to the must start with an alphabetic and not contain dots method, as in a84-22-123-123 not as in 84.22.123.123.bla.cb3rob.com (which actually are also the host names on the devices on those ips in most cases (although customers are ofcourse free to change that after the control has been given over to them in case of rented out servers). as for the rest of it, i really don't see why we should specifically mark static space as being static space as it's simply the de-facto standard, anything else (dhcp, radius, etc) is -optional- and requires extra protocols, so just mark dynamic ip space explicitly instead (if anything) It's also a thing that does not belong in dns but rather in whois if anywhere at all. RBLs are neither authorised (EU privacy laws anyone?), nor the appointed authority to keep databases on whats static or not. RIRs -are-, if anyone should maintain a database on such things, i'd be the rirs (which they have, it's called whois, it just lacks a field that indicates the type of assignment method used. but i guess that would quickly end the selling point of such databases, as who needs Trend Micro if either DNS or whois already contained all required data to just make your mailservers check it in real-time. Anyway, i wish Trend Micro all the luck with maintaining their little database in the age of IPv6 and decaying SMTP use anyway (we nowadays prefer methods like skype, msn, jabber for most of our communications, SMTP has been considered end-of-life for the past 5 years or so over here in our companies, guess why, because it hardly ever works, thanks to companies like Trend Micro just making up their own little standards. it's just a bit annoying for customers that happen to want to send SMTP based (legacy) email to parties that use their RBL, that's all, but indeed, their list will rapidly be removed by any party using it that finds out about their criteria to be removed (as they seem to add a lot of stuff by default as being dynamic, kinda the wrong way around ;) spam is -not- what will eventually kill all support for smtp (that can be easily solved by adding a header field with a unique password for each contact you have approved, and bouncing everything that doesnt contain one ;), shitty amateuristic RBL lists and graylisting (so your urgent mail arrives 20 minutes late) is what's killing smtp support. the only reason -we- still run it is that RIPE etc do not support other address types in whois and mailinglists (such as nanog) still use it. as it's neither peer to peer anymore, nor real-time (with a lot of parties blocking port 25), nor very certain that your message actually will be delivered anymore. We prefer the pre-approved contact list method anyway, you may notice our emails have this X-CONTACT-FILTER-MATCH: nanog header at the bottom, added by our contact-filter software (kinda like procmail but different) as nanog happens to be the super secret password for this list. business cards etc all contain a unique password, as when you don't know us and we don't know you, you have no business mailing us, same as on skype and msn contact lists. methods like that could ofcourse be implemented in the protocol SMTP itself and in all the clients so it could become a proper mail header at one point, removing the need for all the other crap that only slows the exchange of mail down and lessens its reliability and doesn't really stop spam anyway ;). we don't feel that: - dns is the proper place to distinquish between address assignment methods - dns should be relevant for SMTP to work anyway - RBLs should be authorative to maintain databases of address assignment methods (although the EU privacy laws take it a bit too far, prohibiting companies in germany where we are from even storing IP addresses in the first place ;) - RBLs are an effective method to stop spam (it stops -some-.. not -all-) - Making SMTP less reliable and less fast is a good way to go forward if we want to keep the SMTP protocol around in the future. - Making it impossible to use SMTP in a peer-to-peer fashion on eyeball networks and therefore not very real-time anymore is a good idea. furthermore, trend micro is
Re: Arrogant RBL list maintainers
Hi! RBLs are neither authorised (EU privacy laws anyone?), nor the appointed authority to keep databases on whats static or not. RIRs -are-, if anyone should maintain a database on such things, i'd be the rirs (which they have, it's called whois, it just lacks a field that indicates the type of assignment method used. Who cares!? This is something between the ISP using them and YOU. If people want to make use of ANY datasource thats their own thing. They are not forced to use it at all. There is no EU law or anything involved here. There are blacklists that block .CN, so what, up to you to use it it not. Same with iptables, you can also filter anything you like there, yourselve. No EU law telling anything about that. Stick to the point, solve your issue with the party receiving your mails. they dediced to use the list, and most likely were not forced to do so. If you want to mail with them, fix your reverses. If not, no problem either. But stop whining :) Byem, Raymond.
Re: Arrogant RBL list maintainers
thing is that it's illegal to maintain a database with personal details which ip addresses according to various german courts are (don't ask.. mmk? ;) ofcourse we all know ip addresses identify nodes on a network, not persons, but the germans seem to mainain a different view on this, despite us isps being the owners of the internet and not the german government ;). therefore we are not even -allowed- to cooperate with trend micro *grin* sometimes laws really come in handy you know ;) -- Sven Olaf Kamphuis CB3ROB Ltd. Co. KG DataServices Phone: +31/87-8747479 Skype: CB3ROB MSN: s...@cb3rob.net C.V.: http://www.linkedin.com/in/cb3rob Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Thu, 10 Dec 2009, Raymond Dijkxhoorn wrote: Hi! RBLs are neither authorised (EU privacy laws anyone?), nor the appointed authority to keep databases on whats static or not. RIRs -are-, if anyone should maintain a database on such things, i'd be the rirs (which they have, it's called whois, it just lacks a field that indicates the type of assignment method used. Who cares!? This is something between the ISP using them and YOU. If people want to make use of ANY datasource thats their own thing. They are not forced to use it at all. There is no EU law or anything involved here. There are blacklists that block .CN, so what, up to you to use it it not. Same with iptables, you can also filter anything you like there, yourselve. No EU law telling anything about that. Stick to the point, solve your issue with the party receiving your mails. they dediced to use the list, and most likely were not forced to do so. If you want to mail with them, fix your reverses. If not, no problem either. But stop whining :) Byem, Raymond. X-CONTACT-FILTER-MATCH: nanog
Re: Arrogant RBL list maintainers
Hi! thing is that it's illegal to maintain a database with personal details which ip addresses according to various german courts are (don't ask.. mmk? ;) ofcourse we all know ip addresses identify nodes on a network, not persons, but the germans seem to mainain a different view on this, despite us isps being the owners of the internet and not the german government ;). therefore we are not even -allowed- to cooperate with trend micro *grin* sometimes laws really come in handy you know ;) I am not a german neither do i live there. This is nanog, not denog ;) Ok and how many german blacklists are in use? There are reasons most of the blacklists are not based there. Its a silly story and you should focus on the ISP using the list and not some legal thing. Thats irrelevant here. Technically i dont see any new points and stick to the old story. Contact that ISP and negotiate with them. Good luck. bye, Raymond.
Re: Arrogant RBL list maintainers
RBLs are neither authorised (EU privacy laws anyone?), nor the appointed authority to keep databases on whats static or not. RIRs -are-, if anyone should maintain a database on such things, i'd be the rirs (which they have, it's called whois, it just lacks a field that indicates the type of assignment method used. Please don't be ridiculous. Of course DNSBL's are authorized to do this. There is no compulsory use; if I choose to USE a DNSBL, I am electing to allow them to assist me in making decisions about who I receive mail from. If you receive a request for information about your address space from a DNSBL operator, there is no compulsory requirement for you to respond. If you choose to provide it, you authorize the DNSBL to share that information. If you do not, the DNSBL may take whatever action it considers appropriate. Do you believe that some further authorization is required? If so, please explain... because there are businesses whose business models revolve around providing much more detailed information about IP address usage. Your next obvious reply will probably be that some EU privacy law somehow considers this to be personally identifiable information of some sort; however, that is simply ridiculous. One bit of information about whether the address is a dynamic or static allocation is not PII, it's a bit of information that describes the network operator's intended use of the address. The only way it could be construed as PII is to note that it might be an address assigned to a person. However, you can assign both static and dynamic addresses to a person. Since the person in question could be anyone, interchangeably, it is obviously not PII. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
On 2009-12-10, at 16:42, Michael Thomas wrote: On 12/10/2009 08:38 AM, Mark Andrews wrote: The way to do this is to put other data in the ip6.arpa/in-addr.arpa and stop trying to infer things from the PTR records. Sigh. What is the this to which you refer? I think Mark means the question of whether a particular address is statically-assigned or dynamically-assigned, but... The problem space here is what's important. And I think it's worth considering that port 25 isn't the only abuse vector anymore. ... I agree that there's no clear limit to the kind of questions we could come up with that we could answer in such a way. Maybe we don't need to boil the ocean, though. $ORIGIN 90.212.90.in-addr.arpa. @ SOA ... @ NS ... ; 13 PTR calamari.hopcount.ca. 13 HINFO Apple-Mac-Mini Mac OS X Server 13 RP jabley.hopcount.ca. . 13 TXT dynamic ; * RP jabley.hopcount.ca. . * HINFO Nothing Unallocated * TXT unallocated, should source no traffic Joe
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
On 12/10/2009 09:06 AM, Joe Abley wrote: On 2009-12-10, at 16:42, Michael Thomas wrote: On 12/10/2009 08:38 AM, Mark Andrews wrote: The way to do this is to put other data in the ip6.arpa/in-addr.arpa and stop trying to infer things from the PTR records. Sigh. What is the this to which you refer? I think Mark means the question of whether a particular address is statically-assigned or dynamically-assigned, but... Which assumes that that's the question that actually needs to be answered. The problem space here is what's important. And I think it's worth considering that port 25 isn't the only abuse vector anymore. ... I agree that there's no clear limit to the kind of questions we could come up with that we could answer in such a way. Maybe we don't need to boil the ocean, though. Sure, but positing the deployment of any infrastructure comes at a huge cost. Making certain that you're solving the right problem should be the first concern, since it's so expensive. $ORIGIN 90.212.90.in-addr.arpa. @ SOA ... @ NS ... ; 13 PTR calamari.hopcount.ca. 13 HINFO Apple-Mac-Mini Mac OS X Server 13 RP jabley.hopcount.ca. . 13 TXT dynamic See, that makes the assumption that that is the right question. Is it really though? Dynamic vs static is a placeholder for authorized for this role or not, right? And not a very good one when you start to consider the larger world of protocols. I don't think it's boiling the ocean to ask the question of what the producers and consumers of that information are actually looking for. Mike ; * RP jabley.hopcount.ca. . * HINFO Nothing Unallocated * TXT unallocated, should source no traffic Joe
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
on Thu, Dec 10, 2009 at 09:27:44AM -0800, Michael Thomas wrote: On 12/10/2009 09:06 AM, Joe Abley wrote: I think Mark means the question of whether a particular address is statically-assigned or dynamically-assigned, but... Which assumes that that's the question that actually needs to be answered. Well, it seems to be a question that folks at MAAWG are currently trying to answer; I know of at least one effort to coordinate standard means of publishing your dynamics between various MAAWG members, so it seems to be a question that does need to be answered. I'd agree that it's not the only question - see my post on why we consider generic statics suspect. I think in the end, we'll see anyone without a custom, clear, legible, name indicating that a host should be sending mail simply having their mail refused. ... I agree that there's no clear limit to the kind of questions we could come up with that we could answer in such a way. Maybe we don't need to boil the ocean, though. Sure, but positing the deployment of any infrastructure comes at a huge cost. Yeah, for example, it took Road Runner something on the order of 18 months to move all of their residential account PTRs under 'res.rr.com', and their business class under 'biz.rr.com'. They're a bit of a special case, as they're more of a franchise than a single entity, but still. They came to realize that doing so was useful and good, so they did it. And kudos to them for doing so. Making certain that you're solving the right problem should be the first concern, since it's so expensive. All I'm saying, and feel free to do with this what you will, is that there is a demand for means for assigning reputation to IPs based partly on their PTR records; antispam appliance vendors, reputation service providers, carrier class cable and telco companies and ISPs, are all exploring or actively using PTR naming classification as one of those means. You can either recognize this and make your networks more transparent to such enquries, or not. Whois is not the only answer; without a way to quickly associate a PTR with a whois record that happens to say dynamic residential or static business (to use the most broad of available classifications) in real time by DNS lookup or other means, your detailed whois records are useless in direct, practical terms, to postmasters and spam filtering software and others. Spamhaus PBL is one answer, mapping IPs based on ISP-provided information or Spamhaus researcher-discovered information, into zones to be used for rejecting mail. SORBS DUL works in similar way, and makes assumptions on the basis of rDNS scans at the /24 level (among other mechanisms). Enemieslist uses whatever information we can to classify PTR naming; whois, Web sites, price lists and a la carte menus (do they charge extra for static IPs?, do they even provide static IPs?, etc.) and then bases that classification on the name of the remote host at connect time - so we don't have the same falls in a suspicious /24 problem seen so often with SORBS and now MAPS DUL, but just because a customer /can/ ask for and pay for and receive a custom PTR for their mail server doesn't mean they always do - just that over time, they will have to or face poor deliverability, hassles, and the like. But the bottom line is that failure to provide transparency via PTRs is a problem, particularly for deliverability, whether directly (your mail server is named rrcs-12-34-56-78.se.biz.rr.com, which is static but generic, so would be scored suspicious via Enemieslist) or indirectly (your mail server is in a block of generic PTRs that may be static or dynamically assigned based on vague rDNS, so it ended up in a SORBS DUL listing) or (your mail server is in a block with no custom rDNS that the whois record doesn't indicate is static, so ended up in a PBL listing due to lack of cooperation from the ISP), and so on and so on. Of course it makes it easier for me, and Spamhaus, and SORBS, and Trend, if the networking community helps us make these determinations and pass along the proper and appropriate classifications, so that our users and licensees can use our data to make fine-grained policy decisions. Also true is that doing this stuff right can be difficult, or expensive, but I think the point to take away here is that it's already being done, and you can either help, or be an obstacle to progress. Asking whether this is the right question isn't terribly helpful /now/, given that debates have raged here and on mailop and in other forums for years. I prefer to look at the available data (spamtraps, filters, mail flow analyses, etc.) and do something /now/ that is helpful to people wishing to ameliorate abuse /now/. And for the moment, as for the past six years, associating classifications with PTRs based on their naming is a very effective strategy, and one which we're going to continue to use. Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w:
Re: Arrogant RBL list maintainers
thing is that it's illegal to maintain a database with personal details which ip addresses according to various german courts are (don't ask.. I've actually looked at some of the German decisions, and I didn't see anything that would be a problem for DNSBLs But if you're getting legal advice from the same wizard who told you to do this: Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. I can understand why your impressions of the law would be so mistaken. R's, John
Re: Arrogant RBL list maintainers
On Wed, Dec 9, 2009 at 10:18 AM, Sven Olaf Kamphuis s...@cyberbunker.com wrote: We've noticed that Trend Micro mail-abuse.com just assumes ips are dynamic by default, because they just assume that working, rfc compliant, reverse dns that just-so-happens to be automatically generated would indicate dynamic ip space. Sven, Which is it? By default or because it looks automatically generated? By default would seem to be a problem. Automatically generated, not so much. If you haven't made the effort to set up and secure a mail server then you shouldn't be talking smtp to the hosts mail-abuse.com is used to protect. If you haven't bothered to set the reverse DNS to match your server's name then you haven't made the effort, at least not with a modicum of competence. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Arrogant RBL list maintainers
Is there an RFC detailing that specific text strings must be used for static v. dynamic addresses? I can understanding keeping rDNS in sync, but that's not the issue here, is it? On Wed, Dec 9, 2009 at 11:57 AM, William Herrin herrin-na...@dirtside.comwrote: On Wed, Dec 9, 2009 at 10:18 AM, Sven Olaf Kamphuis s...@cyberbunker.com wrote: We've noticed that Trend Micro mail-abuse.com just assumes ips are dynamic by default, because they just assume that working, rfc compliant, reverse dns that just-so-happens to be automatically generated would indicate dynamic ip space. Sven, Which is it? By default or because it looks automatically generated? By default would seem to be a problem. Automatically generated, not so much. If you haven't made the effort to set up and secure a mail server then you shouldn't be talking smtp to the hosts mail-abuse.com is used to protect. If you haven't bothered to set the reverse DNS to match your server's name then you haven't made the effort, at least not with a modicum of competence. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Arrogant RBL list maintainers
On Dec 9, 2009, at 12:11 PM, Mike Lieman wrote: Is there an RFC detailing that specific text strings must be used for static v. dynamic addresses? Well there is this draft Document, FWIW, http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt Which contains suggestions.. -Patrick -- Patrick Muldoon Network/Software Engineer INOC (http://www.inoc.net) PGPKEY (http://www.inoc.net/~doon) Key ID: 0x370D752C Please send all spam to my main address, r...@localhost
Re: Arrogant RBL list maintainers
Mike Lieman wrote: Is there an RFC detailing that specific text strings must be used for static v. dynamic addresses? I can understanding keeping rDNS in sync, but that's not the issue here, is it? There is no RFC that I'm aware of, but I'd say it's pretty common for PTR records that contain the IP address itself to be regarded as dynamic or mass generated. Both of those qualities can indicate the source is not serious about running a mail server. If one chooses this DNS scheme for their mail servers they're playing with fire. ~Seth
Re: Arrogant RBL list maintainers
On Wed, 9 Dec 2009, Mike Lieman wrote: Is there an RFC detailing that specific text strings must be used for static v. dynamic addresses? There's this expired draft http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt But really, the rdns should just clearly indicate the use of the IPs if you're going to do generic/script generated rDNS. a84-22-96-117.cb3rob.net doesn't tell me anything except that this IP is part of a large block of generic rDNS. Something like a84-22-96-117.static.cb3rob.net at least indicates that the IPs are static, while a84-22-96-117.dynamic.cb3rob.net clearly indicates the space is dynamic. Doing this takes much of the guesswork out of it when others on the net need to decide should we accept mail from this IP? Keeping the indicator as close as possible to the domain helps out for things that do simple string matching. i.e. with a84-22-96-117.dynamic.cb3rob.net, it's a safe bet I don't want mail from *.dynamic.cb3rob.net. That's easier to block (with a single rule) than dynamic.a84-22-96-117.cb3rob.net. Still, if you're serious about getting mail from that IP delivered, its far better to have the PTR = the domain or system name than some generic string roughly equivalent to all the neighboring IP PTRs. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Arrogant RBL list maintainers
we've basically told them to go to hell and we advise everyone who uses their RBL lists to remove their RBLs from their configs, as what we have here is a mismanaged list. Same thing we told them (snippit of my response below). Cheers, Michael Holstein Cleveland State University [Trend] : But we will maintain our list as we see appropriate to protect our customer from spam. Suit yourself .. but you can't arbitrarily force the Internet as a whole to adopt an unwritten standard just to make your lives easier. If we encounter problems with our end-users and not being able to deliver email reliably to one of your customers, we'll have them call you, since we're complying with all the various SPAM prevention standards that presently exist. We hate SPAM as much as the next guy, but we're not going to install Bob's SPAM module anymore than we're going to do some custom DNS foolishness for Trend.
Re: Arrogant RBL list maintainers
Michael Holstein wrote: Suit yourself .. but you can't arbitrarily force the Internet as a whole to adopt an unwritten standard just to make your lives easier. If we encounter problems with our end-users and not being able to deliver email reliably to one of your customers, we'll have them call you, since we're complying with all the various SPAM prevention standards that presently exist. One could argue that you are *not* complying by using a generic PTR for a mail server. Some would say that a serious mail server should have proper DNS records, others will say that you should accept mail from any IP no matter what. ~Seth
Re: Arrogant RBL list maintainers
One could argue that you are *not* complying by using a generic PTR for a mail server. Some would say that a serious mail server should have proper DNS records, others will say that you should accept mail from any IP no matter what. No, we do have it correct .. they wanted us to fix all the *other* ones (that can't even send mail because they're firewalled from doing so) .. $ dig -t mx csuohio.edu [..] ;; ANSWER SECTION: csuohio.edu.10800INMX10 antispam5.csuohio.edu. csuohio.edu.10800INMX10 antispam4.csuohio.edu. csuohio.edu.10800INMX10 antispam3.csuohio.edu. csuohio.edu.10800INMX10 antispam2.csuohio.edu. [..] ;; ADDITIONAL SECTION: antispam5.csuohio.edu.10800INA137.148.19.13 antispam4.csuohio.edu.10800INA137.148.18.13 antispam3.csuohio.edu.10800INA137.148.18.21 antispam2.csuohio.edu.10800INA137.148.19.12 (and) 13.19.148.137.in-addr.arpa domain name pointer antispam5.csuohio.edu. 13.18.148.137.in-addr.arpa domain name pointer antispam4.csuohio.edu. 21.18.148.137.in-addr.arpa domain name pointer antispam3.csuohio.edu. 12.19.148.137.in-addr.arpa domain name pointer antispam2.csuohio.edu. Cheers, Michael Holstein Cleveland State University
Re: Arrogant RBL list maintainers
Michael Holstein wrote: No, we do have it correct .. they wanted us to fix all the *other* ones (that can't even send mail because they're firewalled from doing so) .. $ dig -t mx csuohio.edu [..] ;; ANSWER SECTION: csuohio.edu.10800INMX10 antispam5.csuohio.edu. csuohio.edu.10800INMX10 antispam4.csuohio.edu. csuohio.edu.10800INMX10 antispam3.csuohio.edu. csuohio.edu.10800INMX10 antispam2.csuohio.edu. [..] ;; ADDITIONAL SECTION: antispam5.csuohio.edu.10800INA137.148.19.13 antispam4.csuohio.edu.10800INA137.148.18.13 antispam3.csuohio.edu.10800INA137.148.18.21 antispam2.csuohio.edu.10800INA137.148.19.12 (and) 13.19.148.137.in-addr.arpa domain name pointer antispam5.csuohio.edu. 13.18.148.137.in-addr.arpa domain name pointer antispam4.csuohio.edu. 21.18.148.137.in-addr.arpa domain name pointer antispam3.csuohio.edu. 12.19.148.137.in-addr.arpa domain name pointer antispam2.csuohio.edu. Ah, I must have misread. Yeah that's pretty much the accepted way to do DNS for mail servers. ~Seth
Re: Arrogant RBL list maintainers
To be clear: because the legitimate mailserver with a proper non-generic reverse was in a block with other generic reverses, they blacklisted you? That's egregiously harsh. SORBS was blocking a customer for a generic reverse entry, I gave them a legit looking reverse (that fwds properly too), solved, if a bit irritating. To require the whole BLOCK be totally legit is too much. /kc On Wed, Dec 09, 2009 at 02:48:28PM -0500, Michael Holstein's said: No, we do have it correct .. they wanted us to fix all the *other* ones (that can't even send mail because they're firewalled from doing so) .. $ dig -t mx csuohio.edu [..] ;; ANSWER SECTION: csuohio.edu.10800INMX10 antispam5.csuohio.edu. csuohio.edu.10800INMX10 antispam4.csuohio.edu. csuohio.edu.10800INMX10 antispam3.csuohio.edu. csuohio.edu.10800INMX10 antispam2.csuohio.edu. Michael Holstein Cleveland State University -- Ken Chase - k...@heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W.
Re: Arrogant RBL list maintainers
On Wed, 09 Dec 2009 15:09:20 EST, Ken Chase said: To be clear: because the legitimate mailserver with a proper non-generic reverse was in a block with other generic reverses, they blacklisted you? That's egregiously harsh. SORBS was blocking a customer for a generic reverse entry, I gave them a legit looking reverse (that fwds properly too), solved, if a bit irritating. To require the whole BLOCK be totally legit is too much. Especially if they think the block is a /24 and you think it's a /27 and somebody else entirely has the /27 either side of you. I've seen *that* sort of brain damage far too often even in recent years. RFC1519 was 16 frikking years ago, and some people *still* aren't on board. pgp1QLMZ4pMQs.pgp Description: PGP signature
Re: Arrogant RBL list maintainers
;; ANSWER SECTION: csuohio.edu.10800INMX10 antispam5.csuohio.edu. csuohio.edu.10800INMX10 antispam4.csuohio.edu. csuohio.edu.10800INMX10 antispam3.csuohio.edu. csuohio.edu.10800INMX10 antispam2.csuohio.edu. (and) 13.19.148.137.in-addr.arpa domain name pointer antispam5.csuohio.edu. 13.18.148.137.in-addr.arpa domain name pointer antispam4.csuohio.edu. 21.18.148.137.in-addr.arpa domain name pointer antispam3.csuohio.edu. 12.19.148.137.in-addr.arpa domain name pointer antispam2.csuohio.edu. All of the DNSBLs I know are about outbound mail hosts, not inbound ones. What are your sending hosts called? R's, John
Re: Arrogant RBL list maintainers
All of the DNSBLs I know are about outbound mail hosts, not inbound ones. What are your sending hosts called? Outbound goes through the same 4 boxes. We used to split it up (2 at MX10, 2 at MX20 .. reversed for outbound) but for capital (licensing/hardware) reasons we decided to do in/out through the same system. This is just first touch on the way in and last touch on the way out. We also have spfv1 records defined (albeit a rather permissive ptr ~all) .. but as I mentioned, the firewall disallows smtp to anywhere but appropriate hosts. We do still allow smtps and submission to accommodate folks that travel, as we haven't (yet) had a problem with bots using either of those services. My beef with Trend was that they were in essence telling us to re-do DNS on our /16 because they didn't like the way we did it .. despite the mail part (the one that matters) being technically correct by most everyone else's standards. Personally, I think this is just so they can have a big list when they sell it (.. our DNSBL has $x million more entries than $competitor..). Cheers, Michael Holstein Cleveland State University
Re: Arrogant RBL list maintainers
To be clear: because the legitimate mailserver with a proper non-generic reverse was in a block with other generic reverses, they blacklisted you? Their initial email said : [snip] Trend Micro Notification: 137.148.0.0/16 added to DUL [snip] and then went on to say : [snip] To work with us, please generate the following three lists: 1) TOTAL ALLOCATED SPACE – in CIDR format Please include all information for the space you announce. The total of Static and Dynamic space must equal the Total Allocated Space. 2) DYNAMIC SPACE LIST - in CIDR format 3) STATIC SPACE LIST - in CIDR Format [snip] Which was, of course, impossible .. since trunking a VLAN across the core just to have all the printers in the same /22 would be silly. After some arguing back-and-forth .. they (Trend) said : [snip] Also we don't see the IP address as static as we see the generic naming convention of *csuohio.edu* as dynamic and the WHOIS information doesn't indicate that the space is static. [snip] Seriously .. we're a college campus, not a colo. Org-Abuse roles is defined (and valid) and real people read the RFC2142 required addresses. What more do these people want? (Note: they did eventually say okay, we see the MXs as static so those aren't listed .. but not without some discussion). Cheers, Michael Holstein Cleveland State University
Re: Arrogant RBL list maintainers
On Wed, 9 Dec 2009, Michael Holstein wrote: Their initial email said : [snip] Trend Micro Notification: 137.148.0.0/16 added to DUL [snip] That's just lazy/sloppy. A quick survey of your /16 suggests that the majority of it has PTRs in the format of csu-137-148-36-160.csuohio.edu, which looks like generic rDNS...but assuming that a university has a /16 of dynamic space is just dumb...and in that quick survey of your /16, there are obvious pockets of non-generic rDNS. To work with us, please generate the following three lists: 1) TOTAL ALLOCATED SPACE in CIDR format Please include all information for the space you announce. The total of Static and Dynamic space must equal the Total Allocated Space. 2) DYNAMIC SPACE LIST - in CIDR format 3) STATIC SPACE LIST - in CIDR Format [snip] Which was, of course, impossible .. since trunking a VLAN across the core just to have all the printers in the same /22 would be silly. Maybe you misunderstood them? What's trunking a VLAN across the core for a printers subnet have to do with anything? They were asking you to tell them which of your subnets are dynamic and which are static, presumably so they could remove your /16 and list just the bits of it that really are dynamic or otherwise appropriate for their list. Also we don't see the IP address as static as we see the generic naming convention of *csuohio.edu* as dynamic and the WHOIS information doesn't indicate that the space is static. [snip] It really sounds like you were dealing with an idiot and would have done well to see if there was any other individual at Trend/MAPS with maintenance access to their DUL. Seriously .. we're a college campus, not a colo. Org-Abuse roles is defined (and valid) and real people read the RFC2142 required addresses. What more do these people want? -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Arrogant RBL list maintainers
1) TOTAL ALLOCATED SPACE in CIDR format Please include all information for the space you announce. The total of Static and Dynamic space must equal the Total Allocated Space. 2) DYNAMIC SPACE LIST - in CIDR format 3) STATIC SPACE LIST - in CIDR Format [snip] Which was, of course, impossible .. since trunking a VLAN across the core just to have all the printers in the same /22 would be silly. Is your network setup so chaotic that you don't know what address chunks are allocated by DHCP or PPP? They're not asking you to aggregate your printers, they're just asking which ranges are dynamic, since mail directly from dynamic ranges is about 99.999% bot spam. If you really don't know what's dynamic, I can't say I blame them for assuming the worst. R's, John
RE: Arrogant RBL list maintainers
Michael: I've seen their form, too. I think you're reading too much into their policies/requests. Does it matter if they label your non e-mail server IPs as dynamic space, and therefore put it on their DUL? Frank -Original Message- From: Michael Holstein [mailto:michael.holst...@csuohio.edu] Sent: Wednesday, December 09, 2009 3:18 PM To: Ken Chase Cc: nanog@nanog.org Subject: Re: Arrogant RBL list maintainers To be clear: because the legitimate mailserver with a proper non-generic reverse was in a block with other generic reverses, they blacklisted you? Their initial email said : [snip] Trend Micro Notification: 137.148.0.0/16 added to DUL [snip] and then went on to say : [snip] To work with us, please generate the following three lists: 1) TOTAL ALLOCATED SPACE - in CIDR format Please include all information for the space you announce. The total of Static and Dynamic space must equal the Total Allocated Space. 2) DYNAMIC SPACE LIST - in CIDR format 3) STATIC SPACE LIST - in CIDR Format [snip] Which was, of course, impossible .. since trunking a VLAN across the core just to have all the printers in the same /22 would be silly. After some arguing back-and-forth .. they (Trend) said : [snip] Also we don't see the IP address as static as we see the generic naming convention of *csuohio.edu* as dynamic and the WHOIS information doesn't indicate that the space is static. [snip] Seriously .. we're a college campus, not a colo. Org-Abuse roles is defined (and valid) and real people read the RFC2142 required addresses. What more do these people want? (Note: they did eventually say okay, we see the MXs as static so those aren't listed .. but not without some discussion). Cheers, Michael Holstein Cleveland State University
RE: Arrogant RBL list maintainers
Each network can decide how they want to run their network, and Trend Micro can make any list they like, but if cb3rob.net wants to send e-mail to other networks that use Trend Micro's list for spam control, cb3rob.net will have to decide whether to comply with the other network's rules, even if those rules seem unreasonable. Two sides of an SP's coin: I want to maximize my e-mail servers' deliverability, so I make sure those have appropriately named PTRs and make sure that outbound messages aren't spammy; I also want to restrict deliverability of e-mail from my dynamic space, so I have appropriately named PTRs so that others don't have to guess what kind of host it is. Perhaps I forgot those customers with static hosts and that want to send e-mail -- I make sure those PTRs are well-named, too. Frank -Original Message- From: Seth Mattinen [mailto:se...@rollernet.us] Sent: Wednesday, December 09, 2009 1:24 PM To: nanog@nanog.org Subject: Re: Arrogant RBL list maintainers Michael Holstein wrote: Suit yourself .. but you can't arbitrarily force the Internet as a whole to adopt an unwritten standard just to make your lives easier. If we encounter problems with our end-users and not being able to deliver email reliably to one of your customers, we'll have them call you, since we're complying with all the various SPAM prevention standards that presently exist. One could argue that you are *not* complying by using a generic PTR for a mail server. Some would say that a serious mail server should have proper DNS records, others will say that you should accept mail from any IP no matter what. ~Seth
RE: Arrogant RBL list maintainers
On Wed, 9 Dec 2009, Frank Bulk wrote: Two sides of an SP's coin: I want to maximize my e-mail servers' deliverability, so I make sure those have appropriately named PTRs and make sure that outbound messages aren't spammy; I also want to restrict The point he was trying to make is that there is no standard for what those appropriately named PTRs should look like. He has forward/reverse that is perfectly ok according to standard (forward/reverse matches) and if he had a automatic dictionary for naming those IPs instead of putting the IPs there, things would be different. If people want to make standards on how to put information into DNS for RBL use, they should take it to the IETF and make a standard out of it, not just ad-hoc create something of their own and expect everybody else to conform. If there is an industry standard (which the replies here seem to indicate), that should be written down and standardized by the people who actually make money out of it, in this case Trend Micro. This would remove the problem of having to maintain tens or hundred points of contacts for what is dynamic dialup space which is the problem right now as there are a lot of RBLs to deal with. Creating a standard on what to put in WHOIS/DNS for dynamic/static/infrastructure would make a lot of sense, seems nobody is doing it though. -- Mikael Abrahamssonemail: swm...@swm.pp.se
