Re: Arrogant RBL list maintainers

[Michael Holstein]

> 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

[Steven Champeon]

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

[Matthew Petach]

On Wed, Dec 16, 2009 at 9:07 PM,   wrote:
> 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... :)
>

So, it's uncool to do as long as you're small, but once you're big enough,
it's OK to do.  I wonder what the crossover point is?  If you're an
up-and-coming
gorilla, but you're only 400 pounds, do you get a regexp and a waiver?  What
about if you're only 200 pounds?  100 pounds?
Are we putting an artificial barrier in place, blocking new entrants into the
space by grandfathering existing mail providers, but steadfastly keeping
the gate closed against new providers trying to enter the marketplace?
Are we guilty of collusion, gathering in virtual spaces like this to agree on
how we can put rules in place to prevent any would-be mail hosting
companies from being able to compete on a level playing field?  At
what point does the FTC decide that we've crossed a line in cooperating
to keep these newcomers from doing business in our territory?

No, I don't think we've crossed the line yet--but it does make me
sit up and think about the various permutations and combinations
that might arise out of conversations like this, and how they could
be misinterpreted by government regulators.

I suppose it's best if I make it very abundantly clear that I'm not
speaking for my employer in any way, shape, or form here; I'm
just ruminating after dinner with a full stomach and an empty head
on my own time, just as me, nothing more.

Matt

Re: Arrogant RBL list maintainers

[Valdis . Kletnieks]

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

[Mike Lieman]

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

[William Pitcock]

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

[Mark Scholten]

> -Original Message-
> From: Michelle Sullivan [mailto:matt...@sorbs.net]
> Sent: Wednesday, December 16, 2009 6:09 PM
> To: nanog@nanog.org
> Subject: 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"...
As you probably know RIPE is located in the Netherlands and following Dutch
law and not German law (however they are very similar). Publishing persons
(done by RIPE in the whois database) is something that could be changed in
the future (if I look to the current law in the Netherlands and SIDN did
change the policy about whois information).
> 
> Love to hear the legal battle on that one! 
> 
> 
> Michelle

Re: Arrogant RBL list maintainers

[Steven Champeon]

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

[Michelle Sullivan]

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

[Niels Bakker]

* 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

[Jack Bates]

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

[Matthew Petach]

On Wed, Dec 16, 2009 at 5:21 AM,   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

[Michelle Sullivan]

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! 


Michelle

Re: Arrogant RBL list maintainers

[Michelle Sullivan]

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

[Michelle Sullivan]

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/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 Maintainers (

Re: Arrogant RBL list maintainers

[Sean Donelan]

On Wed, 16 Dec 2009, James Hess wrote:

On Tue, Dec 15, 2009 at 11:30 PM, Adam Armstrong  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

[Jack Bates]

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

[Valdis . Kletnieks]

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

[William Herrin]

On Wed, Dec 16, 2009 at 7:06 AM, Mike Lieman  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  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: 
Falls Church, VA 22042-3004

Re: Arrogant RBL list maintainers

[Rich Kulawiec]

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

[Mike Lieman]

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  wrote:

> On 16/12/2009 06:12, James Hess wrote:
>
>> On Tue, Dec 15, 2009 at 11:30 PM, Adam Armstrong
>>  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

[Adam Armstrong]

On 16/12/2009 06:12, James Hess wrote:

On Tue, Dec 15, 2009 at 11:30 PM, Adam Armstrong  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

[Suresh Ramasubramanian]

Security by obscurity, in this day and age? :)

On Wed, Dec 16, 2009 at 11:42 AM, James Hess  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

[James Hess]

On Tue, Dec 15, 2009 at 11:30 PM, Adam Armstrong  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

[Adam Armstrong]

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

[Rich Kulawiec]

[ 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

[John Levine]

>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: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)

[Steven Champeon]

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)

Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)

[Michael Thomas]

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)

[Joe Abley]

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: Arrogant RBL list maintainers

[Joe Greco]

> 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: Arrogant RBL list maintainers

[Raymond Dijkxhoorn]

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

[Sven Olaf Kamphuis]

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

[Raymond Dijkxhoorn]

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

[Sven Olaf Kamphuis]

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

Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)

[Michael Thomas]

On 12/10/2009 08:38 AM, Mark Andrews wrote:

In message<4b211da6.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: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)

[Mark Andrews]

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: Arrogant RBL list maintainers

[Michael Holstein]

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

[Steven Champeon]

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

[Steven Champeon]

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)

[Michael Thomas]

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

[Steven Champeon]

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/

best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)

[Steven Champeon]

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

[Michael Holstein]

> 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

Re: Arrogant RBL list maintainers

[Dave CROCKER]

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

[Sam Hayes Merritt, III]

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

[Ronald Cotoni]

On Thu, Dec 10, 2009 at 8:20 AM, Tony Finch  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    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

[Tony Finch]

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.finchhttp://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

Re: Arrogant RBL list maintainers

[Chris Edwards]

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

[Mikael Abrahamsson]

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

RE: Arrogant RBL list maintainers

[Frank Bulk]

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

[Frank Bulk]

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

[John Levine]

>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

[Jon Lewis]

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

[Michael Holstein]

> 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

[Michael Holstein]

> 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

[John Levine]

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

[Valdis . Kletnieks]

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

[Ken Chase]

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

[Seth Mattinen]

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

[Michael Holstein]

> 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

[Seth Mattinen]

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

[Michael Holstein]

> 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

[Christopher Morrow]

On Wed, Dec 9, 2009 at 11:57 AM, William Herrin
 wrote:

> If you haven't made the effort to set up and secure a mail server then

perhaps his ISP does something dumb (like verizon does) and only
delegates to one server, which may/may-not be available at the time of
the incident? (or is blocked/down/something-else from the observation
point)

btw: why won't verizon (fios/dsl folk I mean) delegate to more than 1
customer DNS server??

-Chris

Re: Arrogant RBL list maintainers

[Jon Lewis]

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

[Seth Mattinen]

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

[Patrick Muldoon]

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]

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
wrote:

> On Wed, Dec 9, 2009 at 10:18 AM, Sven Olaf Kamphuis
>  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: 
> Falls Church, VA 22042-3004
>
>

Re: Arrogant RBL list maintainers

[William Herrin]

On Wed, Dec 9, 2009 at 10:18 AM, Sven Olaf Kamphuis
 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: 
Falls Church, VA 22042-3004