Re: Breaking the internet (hotels, guestnet style)

[Jens Link]

Owen DeLong  writes:

> I expect my connections to my mail server to actually reach my mail
> server.  I use TLS and SMTP AUTH as well as IMAP/SSL.  Many of the "just
> works" settings in question break these things badly.

One of my customers has an appliance for his WLAN guest access access
which filters out  records. :-( 

j...@bowmore:~$ dig  www.quux.de @8.8.8.8 +short
j...@bowmore:~$ 

Jens
-- 
-
| Foelderichstr. 40  | 13595 Berlin, Germany | +49-151-18721264 |
| http://www.quux.de | http://blog.quux.de   | jabber: jensl...@guug.de |
-

"Cool" ISPs

[Steven Bellovin]

Some folks on this list may be interested in Ars Technica's take on "cool" 
ISPs: 
http://arstechnica.com/tech-policy/news/2009/12/the-coolest-isp-in-the-world.ars
  (note: I neither endorse nor condemn any of the ideas, ISPs, etc.  In other 
words, don't blame me if you disagree...)

--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: "Cool" ISPs

[Benjamin BILLON]

Cocorico!

Another way to measure coolness of ISPs is to check how they're engaged 
with common people. Several Free.fr managers (including Xavier Niel and 
Rani Assaf) participate personally on the FRnOG mailing-list (in 
addition to Free.fr newsgroups). Some SFR employees also read FRnOG. 
None of Orange AFAIK.


Steven Bellovin a écrit :

Some folks on this list may be interested in Ars Technica's take on "cool" 
ISPs: http://arstechnica.com/tech-policy/news/2009/12/the-coolest-isp-in-the-world.ars  
(note: I neither endorse nor condemn any of the ideas, ISPs, etc.  In other words, don't 
blame me if you disagree...)

--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Breaking the internet (hotels, guestnet style)

[Owen DeLong]

On Dec 9, 2009, at 1:26 AM, Jens Link wrote:

> Owen DeLong  writes:
> 
>> I expect my connections to my mail server to actually reach my mail
>> server.  I use TLS and SMTP AUTH as well as IMAP/SSL.  Many of the "just
>> works" settings in question break these things badly.
> 
> One of my customers has an appliance for his WLAN guest access access
> which filters out  records. :-( 
> 
> j...@bowmore:~$ dig  www.quux.de @8.8.8.8 +short
> j...@bowmore:~$ 
> 
Wow... Yeah, that would definitely result in a lengthy conversation between
their tech. support department and me.

The ones that are even worse, though, are the ones that pass through 
and do RA/SLAAC advertisements, but, don't provide IPv6 connectivity.

Oh, and, I stayed at one place that didn't pass TCP/53, so, they broke
things like Blizzard authentication.

Owen

Arrogant RBL list maintainers

[Sven Olaf Kamphuis]

Hi NANOG readers,

We've noticed that Trend Micro "mail-abuse.com" just "assumes" ips are
dynamic by default, adds them to their stupid list, and then expects US to
update -their- database -for them- for free to get them off their stupid
list again. (as ofcourse our customers bug us when their email doesn't
arrive on the other side, hell they even tell the customers to bug -us- ;)

because they just assume that working, rfc compliant, reverse dns that
just-so-happens to be automatically generated would indicate dynamic ip
space.. (or actually because they think using customer-pressure is a good
way to get isps to maintain their product (their database) for them for
free).

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.

as ofcourse we neither intend to change our perfectly fine
"aXXX-XXX-XXX-XXX.cb3rob.net." reverse dns scheme, nor maintain their
database for free for them..

they've probably done the same with other isps that use simular schemes.

just to let everyone know...


-- Forwarded message --
Date: Wed, 9 Dec 2009 12:07:50 GMT
From: Adelaide Santos via RT 
To: s...@cb3rob.net
Cc: sa...@cb3rob.net
Subject: [MAPS #322153] Re: WWW remove for 84.22.XX.XX

Hello,

Thank you for this information.  The DUL list is simply a listing of IP blocks 
which use dynamic IP
assignment, and are prohibited (usually by AUP/TOS) from running servers.  Many 
ISP's voluntarily
participate in the DUL by providing us with their blocks of 
dynamically-assigned IP's.  ISPs benefit
from participating in the DUL because the amount of spam and abusive IP traffic 
originating from
their IP space is reduced, which also reduces the amount of abuse complaints 
received.  We benefit
because of increased communications and cooperation with the ISPs makes our 
lists that much
more accurate.  Everyone benefits because the DUL helps stop spam.

See also "Addition due to ISP Participation":
http://mail-abuse.com/support/nominats_dul.html

Currently, you are using a generic naming convention that does not show any 
indication of being
static. If this space is indeed static, then all rDNS must reference to static 
in the rDNS.

Here is an example of a generic naming convention:
84.22.XX.0 (a84-22-XX-0.cb3rob.net)
84.22.XX.1 (a84-22-XX-1.cb3rob.net)
<...>

Here is what you can do:
84.22.XX.0 (a84-22-XX-0.fixed.cb3rob.net)
84.22.XX.1 (customer.cb3rob.net)
84.22.XX.2 (a84-22-XX-2.fixed.cb3rob.net)
84.22.XX.3 (mail.cb3rob.net)
84.22.XX.4 (a84-22-XX-4.fixed.cb3rob.net)
<...>

Here are the naming conventions that we uses to decide if an IP or CIDRs is 
static or dynamic.

Typical static rDNS terms:
bus, biz, colo, ded, fix, mta, perm, server, smtp, static, wsip.

 Typical dynamic rDNS terms:
adsl, cable, dhcp, dialup, dsl, dyn, home, isdn, modem, pool, ppp, or res.

Trend Micro supports the Messaging Anti-Abuse Working Group (MAAWG) Best 
Practices for
Dynamic Address Sharing. Please review the Best Practices document (available at
http://www.maawg.org/about/publishedDocuments/MAAWG_Dynamic_Space_2008-06.pdf).

We need to see these changes before we can proceed with the removal. If 
changing the rDNS is not
possible, we suggest that you add a statement in the WHOIS information stating 
that this space is
statically assigned.

Thank you,
Adelaide Santos
DUL Investigator
Trend Micro Email Reputation Services
http://www.mail-abuse.com/





[s...@cb3rob.net - 2009-12-08 13:23:03 +]:

> hi "dul".
>
> none of our ips are "dynamic", as we simply don't do access networks,
> as those are lame and don't make money.
>
> this includes:
>
> 84.22.96.0/19
> 205.189.71.0/24
> 205.189.72.0/23
> 91.209.12.0/24
>
> all of which originate from AS34109 and none of which are "dynamic"
>
> furthermore, i really don't see why -we- should spend time and effort on a
> problem thats initiated on -your- end by your action of
>
> 1: incorrectly adding our ips to your list, thereby obviously causing
> problems for our customers
>
> 2: getting our customers to get us to bug you about it instead of just
> solving it with our customers directly, and therefore not forcing
> us to wasting our time with it.
>
> we generally do not interfere in 'third party' problems, and this clearly
> qualifies as one (together with dmca crap, arrogant irc networks, etc) you
> name it, we don't go and sit in the middle, just solve it with the
> customers!).
>
> as the problem is as follows: you put ips on some list therefore our
> customer cannot mail, exactly WHY should we spend manhours (and therefore
> money) to fix a problem YOU created...
>
> as i'm damn sure we never put any of our ips on some "dynamic pool" list.
>
> it's probably just your software thinking "oh automatically generated
> reverse dns" (which in our case takes the form of
> a84-22-xx-xx.cb3rob.net. as it's RFC complient and we cannot be fucked to
> make up host names for each a

AT&T blocking individual IP addresses

[Scott Howard]

As of about an hour ago AT&T appear to have started blocking access to a few
of our IP addresses. This is being done at a /32 level, and the IP addresses
above and below are still allowed through.

Has anyone seen them do this before, or know who I need to contact to get it
fixed?  AT&T won't talk to me as I'm not a customer...

Traceroute to the blocked IPs from AT&T all end at :
  5 cr2.phlpa.ip.att.net (12.122.3.226) [MPLS: Labels 20559/17406 Exp 0] 116
msec 20 msec 20 msec
  6 cr2.cl2oh.ip.att.net (12.122.2.209) [MPLS: Labels 20527/17406 Exp 0] 24
msec 20 msec 20 msec
  7 cr1.cl2oh.ip.att.net (12.122.2.125) [MPLS: Labels 0/17406 Exp 0] 24 msec
20 msec 20 msec
  8 cr82.dtrmi.ip.att.net (12.123.139.154) [MPLS: Label 16623 Exp 0] 24 msec
20 msec 20 msec
  9 gar4.dtrmi.ip.att.net (12.122.102.89) 20 msec 20 msec 20 msec
 10 12.87.238.238 [AS 7018] 24 msec 20 msec 24 msec
 11 12.87.238.237 [AS 7018] !A  *  *

Traceroute to the neighboring IP addresses don't go anywhere near the above
path, so it's apparently a blackhole of sorts.

  Scott.

Re: AT&T blocking individual IP addresses

[Dobbins, Roland]

On Dec 9, 2009, at 10:22 PM, Scott Howard wrote:

> Traceroute to the neighboring IP addresses don't go anywhere near the above 
> path, so it's apparently a blackhole of sorts.

Are they bots or C&C servers, or open DNS recursors?

---
Roland Dobbins  // 

Injustice is relatively easy to bear; what stings is justice.

-- H.L. Mencken

Re: AT&T blocking individual IP addresses

[Scott Howard]

On Wed, Dec 9, 2009 at 7:25 AM, Dobbins, Roland  wrote:

> > Traceroute to the neighboring IP addresses don't go anywhere near the
> above path, so it's apparently a blackhole of sorts.
>
> Are they bots or C&C servers, or open DNS recursors?
>

They are (authenticated-required) proxy servers with 10's of thousands of
users behind them, so it's possible that they were seeing some bot-like
traffic from them, although the volume would have been tiny compared to the
volume of legitimate traffic.

  Scott.

Re: AT&T blocking individual IP addresses

[Dobbins, Roland]

On Dec 9, 2009, at 11:03 PM, Scott Howard wrote:

> They are (authenticated-required) proxy servers with 10's of thousands of 
> users behind them, so it's possible that they were seeing some bot-like 
> traffic from them, although the volume would have been tiny compared to the 
> volume of legitimate traffic.

So, if, say, AT&T customers are getting zorched from traffic behind those 
proxies, then blocking them would make sense, no?

;>

Do you have visibility into the traffic into/out of those proxies, in order to 
determine if there's DDoS or spam or other undesirable traffic emanating from 
them?

---
Roland Dobbins  // 

Injustice is relatively easy to bear; what stings is justice.

-- H.L. Mencken

RE: Earthlink SMTP Admin Contact?

[Ryan Gelobter]

Thanks for the number, but their NOC was unable to help me. They referred me 
back to their Abuse Mailbox and abuse e-mail addresses 
(blockedbyearthl...@abuse.earthlink.net, ab...@abuse.earthlink.net). They were 
unable to provide any alternative number or e-mail address. I ended up calling 
their corporate office (404.815.0770) and spoke to an operator who confirmed 
with senior tech's that the abuse team their checks the mailbox but they 
apparently are not in the office and work from home. Senior tech support tells 
me the mail server is not blocked even though I get blocked messages and 
escalating it further would not do anything as they show it as not blocked.

Tech support uses the same procedure as the mail administrator does which is to 
e-mail blockedbyearthlink@ address with the subject BLOCKED: xxx.xxx.xxx.xxx 
(replace with the ip) and if it is blocked they will unblock you. Sadly, I 
tried that already.

Ryan G
IT Assistant/Support Technician
Limestone Networks, Inc.
r.gelob...@limestonenetworks.com
www.limestonenetworks.com
Simple.  Solid.  Superior.


-Original Message-
From: Peter Beckman [mailto:beck...@angryox.com] 
Sent: Tuesday, December 08, 2009 10:28 PM
To: Jason Williams
Cc: Ryan Gelobter; nanog@nanog.org
Subject: Re: Earthlink SMTP Admin Contact?

On Tue, 8 Dec 2009, Jason Williams wrote:

> On Dec 8, 2009, at 11:42 AM, Ryan Gelobter wrote:
>
>> Any chance there's someone from Earthlink on nanog or anyone that has 
>> contact information?
>
> Their NOC has an unlisted number: +1 404-815-0770 x22277

  Not anymore, it would seem.  NANOG Archives FTW.

---
Peter Beckman  Internet Guy
beck...@angryox.com http://www.angryox.com/
---

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

Re: Earthlink SMTP Admin Contact?

[Suresh Ramasubramanian]

Is the IP space anywhere near these -
http://www.spamhaus.org/sbl/listings.lasso?isp=limestonenetworks.com

Found 7 SBL listings for IPs under the responsibility of limestonenetworks.com

SBL82484
69.162.119.163/32   limestonenetworks.com
03-Dec-2009 18:14 GMT   BOA phish site

SBL81933
74.63.211.0/24  limestonenetworks.com
25-Nov-2009 01:23 GMT   Snowshoe spam range ("Dynabucks")

SBL81769
69.162.115.157/32   limestonenetworks.com
22-Nov-2009 21:54 GMT   Spammed malware sites on fast-flux hacked systems

SBL81707
216.245.216.64/27   limestonenetworks.com
21-Nov-2009 16:24 GMT   MMF snowshoe spam

SBL81125
216.245.222.192/26  limestonenetworks.com
10-Nov-2009 14:00 GMT   Suspected Snowshoe Spam Range

SBL78721
69.162.68.160/29limestonenetworks.com
17-Sep-2009 08:03 GMT   emailmkt.org

SBL78720
216.245.204.32/27   limestonenetworks.com
17-Sep-2009 08:01 GMT   emailmkt.org


On Wed, Dec 9, 2009 at 10:26 PM, Ryan Gelobter
 wrote:
> Thanks for the number, but their NOC was unable to help me. They referred me 
> back to their Abuse Mailbox and abuse e-mail addresses 
> (blockedbyearthl...@abuse.earthlink.net, ab...@abuse.earthlink.net). They 
> were unable to provide any alternative number or e-mail address. I ended up 
> calling their corporate office (404.815.0770) and spoke to an operator who 
> confirmed with senior tech's that the abuse team their checks the mailbox but 
> they apparently are not in the office and work from home. Senior tech support 
> tells me the mail server is not blocked even though I get blocked messages 
> and escalating it further would not do anything as they show it as not 
> blocked.
>
> Tech support uses the same procedure as the mail administrator does which is 
> to e-mail blockedbyearthlink@ address with the subject BLOCKED: 
> xxx.xxx.xxx.xxx (replace with the ip) and if it is blocked they will unblock 
> you. Sadly, I tried that already.



-- 
Suresh Ramasubramanian (ops.li...@gmail.com)

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: Breaking the internet (hotels, guestnet style) - path asumption

[bmanning]

On Wed, Dec 09, 2009 at 06:30:45AM -0800, Owen DeLong wrote:
> 
> On Dec 9, 2009, at 1:26 AM, Jens Link wrote:
> 
> > Owen DeLong  writes:
> > 
> >> I expect my connections to my mail server to actually reach my mail
> >> server.  I use TLS and SMTP AUTH as well as IMAP/SSL.  Many of the "just
> >> works" settings in question break these things badly.
> > 
> > One of my customers has an appliance for his WLAN guest access access
> > which filters out  records. :-( 
> > 
> > j...@bowmore:~$ dig  www.quux.de @8.8.8.8 +short
> > j...@bowmore:~$ 
> > 
> Wow... Yeah, that would definitely result in a lengthy conversation between
> their tech. support department and me.
> 
> The ones that are even worse, though, are the ones that pass through 
> and do RA/SLAAC advertisements, but, don't provide IPv6 connectivity.
> 
> Owen
> 

why do you presume the DNS service is in the same path as the 
TLS/SSL?

a loose reading of these posts might give the gullible the impression
that the IP datagrams between the source and the target pass through
the DNS server... which we -KNOW- is false.


--bill

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

[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: AT&T blocking individual IP addresses

[Paul Bennett]

On Wed, 09 Dec 2009 10:22:50 -0500, Scott Howard  wrote:

As of about an hour ago AT&T appear to have started blocking access to a  
few of our IP addresses.



AT&T won't talk to me as I'm not a customer...


So, wait, are they your addresses or not?



--
Paul

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

[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: Breaking the internet (hotels, guestnet style) - path asumption

[Christopher Morrow]

On Wed, Dec 9, 2009 at 12:11 PM,   wrote:

>        that the IP datagrams between the source and the target pass through
>        the DNS server... which we -KNOW- is false.

dns-tunnel

Followup regarding Joint Statement on ASN Assignment Discrepancies

[John Curran]

ARIN would like to report that it has worked with all its customers who 
received ASNs from the AS1707-AS1726 range and has provided them with 
replacement ASNs.  

Additionally, ARIN is now checking the other RIR databases and global routing 
tables just prior to issuance of any number resources (ASNs or IP address 
blocks) to ensure that there are no conflicts in issued resources.

FYI,
/John

John Curran
President and CEO
ARIN


On Nov 26, 2009, at 11:31 AM, John Curran wrote:

> ARIN and the RIPE NCC have worked together to research the issues with
> the Autonomous System Number (ASN) range AS1707-AS1726. Below is our
> analysis of what happened and a plan to resolve these issues.
> 
> It appears that prior to 1993, Renater was issued AS1707 with an AS
> name of "ASNBLOCKA".  This is the name format used to assign a block
> of ASNs, but the DDN NIC (the Defense Data Network Network Information
> Center, which was responsible for ASN assignments until 1993) recorded
> only a single assignment of AS1707, rather than the entire block of 20
> ASNs (AS1707-AS1726), as would have been expected. AS1712 was never
> registered in the DDN NIC database.
> 
> Since the proper registration was never recorded, this mistake carried
> over from the InterNIC database into ARIN's database at ARIN’s inception
> in 1997. The ASN range was not transferred to the RIPE NCC along with
> AS1707 because AS1708-AS1726 appeared to be unassigned, and thus
> remained with ARIN.
> 
> Because this is simply an error in registry data and Renater is the
> actual registrant of this entire range of ASNs (AS1707-AS1726), ARIN
> will work with its customers who received ASNs from this range in July
> and August of 2009 to provide them with replacement ASNs.  While we
> understand that this may cause some difficulty for these customers, we
> feel that this is the best path forward given the circumstances.
> 
> RIPE NCC and ARIN will update their respective databases and work with
> the IANA to ensure that the ASN registry data is properly updated for
> this range.
> 
> To prevent future issues, ARIN and RIPE NCC will implement two new
> processes for issuing new ASNs: checking all other RIR databases to
> ensure that the ASN is not previously registered, and checking BGP
> routing tables to ensure the ASN is not already found in an announced
> AS-path.  ASNs that fail either of these conditions will not be issued
> until the discrepancy has been addressed.
> 
> Regards,
> John Curran, President and CEO, ARIN
> Axek Pawlik, Managing Director, RIPE NCC
> 

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: AT&T blocking individual IP addresses

[Scott Howard]

On Wed, Dec 9, 2009 at 9:26 AM, Paul Bennett wrote:

> On Wed, 09 Dec 2009 10:22:50 -0500, Scott Howard  wrote:
>
>  As of about an hour ago AT&T appear to have started blocking access to a
>> few of our IP addresses.
>>
>
>  AT&T won't talk to me as I'm not a customer...
>>
>
> So, wait, are they your addresses or not?
>


They are our non-AT&T addresses, and AT&T was blocking access to them from
their network, so any of our customers on AT&T were unable to access our
systems.

AT&T has now resolved the problem, claiming that it was a "provisioning
error"...

Thanks,
  Scott.

Re: Breaking the internet (hotels, guestnet style)

[Stephen Sprunk]

Jens Link wrote:
> Owen DeLong  writes:
>   
>> I expect my connections to my mail server to actually reach my mail server.  
>> I use TLS and SMTP AUTH as well as IMAP/SSL.  Many of the "just works" 
>> settings in question break these things badly.
>> 
>
> One of my customers has an appliance for his WLAN guest access access
> which filters out  records. :-( 
>
> j...@bowmore:~$ dig  www.quux.de @8.8.8.8 +short
> j...@bowmore:~$ 
>   

That, unfortunately, is not uncommon.  Actually, it's one of the _less_
broken systems I've seen, since IPv4 presumably keeps working.

One major vendor of hotel guestnet equipment returns an A record for
0.0.0.1 if you do an ANY or  query for any hostname--even ones that
don't exist.  At least with WinXP, you have to disable IPv6 just to get
IPv4 to work!  Worse, their tech support sees nothing wrong with this;
if you disagree, all they'll do is offer a refund.  Unfortunately, "take
your money elsewhere" doesn't work when you've already paid for the
hotel room--and they know it.

S

-- 
Stephen Sprunk "God does not play dice."  --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSSdice at every possible opportunity." --Stephen Hawking



smime.p7s
Description: S/MIME Cryptographic Signature

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: Leaving public peering?

[Henk Steenman]

On Dec 3, 2009, at 1:00 AM, Patrick W. Gilmore wrote:

> On Dec 2, 2009, at 4:48 PM, Jonas Frey wrote:
> 
>> the DE-CIX pricing is now 500 Euro/month...since 1st october...see end
>> of that page.
>> Both DE-CIX and AMS-IX have decreased their pricing this year..almost at
>> the same time. I guess this is a move to stop company leaving public
>> exchanges...i have seen this trend, too.
> 
> That is not why LINX lowers its prices.  (I cannot say why AMS-IX lowers its 
> prices.)
> 
> LINX is a member-based organization.  The member _own_ the exchange.  They 
> are paying themselves, and they only pay themselves as much as it costs to 
> run the exchange.  With more members, more scale, and advances in equipment, 
> unit (i.e. port) costs go down.
> 
> In a cost-recovery model, that means prices drop.

For exactly the same reason AMS-IX lowered its prices.

 - Henk


> 
> LINX dropped prices mid-year 2009, and are dropping prices again in January 
> 2009.  AMS-IX dropped prices once in that time.  DE-CIX actually raised its 
> prices for many members, so they could lower their prices for others.  
> Interesting strategy
> 
> -- 
> TTFN,
> patrick
> 
> 
>> On Wed, 2009-12-02 at 22:20, Leo Bicknell wrote:
>>> In a message written on Wed, Dec 02, 2009 at 12:46:46PM -0800, Lasher, Donn 
>>> wrote:
 I realized that paid transit is down at almost obscene levels, but is
 that enough of a reason to increase hop-count, latencies, etc?
 
 Why disconnect from public mostly-free peering?
>>> 
>>> Let's look at some economics.  I'm going to pick on some folks here,
>>> solely because they have prices online and because they are, I feel,
>>> representative prices.
>>> 
>>> http://www.cogentco.com/us/
>>> 
>>> "Home of the $4 Megabit!"  So we have transit prices at $4 per megabit.
>>> 
>>> http://www.de-cix.net/content/services/public-peering.html
>>> 
>>> A 1GE link to the exchange is 1000 euro per month, which is $1505 USD at
>>> the moment, let's call it $1500 for round numbers.
>>> 
>>> Now, your 1GE exchange port really shouldn't be run past 60% or so, if
>>> you want to provide good service.  So it's really $1500 for 600Mbits,
>>> or $2.50 per Megabit.
>>> 
>>> If you're an ISP you look at this and go, humm, I take in $4 from my
>>> customer, and hand $2.50 of it right back out to an exchange operator
>>> if I use public peering, making the exchange 62% of my costs right up
>>> front.  On the other hand, if I choose wisely where I private peer I
>>> can do it at places with a one-time fee for the cable, so there is
>>> $0 in MRC.  I have to buy a router port, sure, but it's also $0 MRC,
>>> just a capital asset that can get written off over many years.
>>> 
>>> This is the math with the $4 megabit advertised price.  The halls at
>>> Nanog are awash in $2 a megabit rumors if you have large enough commits
>>> (say, a few 10GE's).  Taking in $2 and paying the exchange operator
>>> $2.50 of itwell, that's not so good. :)
>>> 
>>> Transit prices have fallen enough that MRC's for switch ports, and
>>> even MRC's for fiber runs (are any of you still in a colo that wants
>>> $500 a month for a fiber run, I didn't think so) are eating up huge
>>> chunks of the inbound revenue, and thus just don't make sense.
>>> 
>>> Now, before someone points it out, yes, DECIX's rate per megabit is
>>> lower on a 10GE and a second port, so if you can move 2 ports of 10GE of
>>> traffic you can make it a lot cheaper.  Also, Cogents $4 a megabit is
>>> probably predicated on you being in the right location and having the
>>> right commit, if you need a DS-3 in West Nowhere you'll pay a higher
>>> rate, and that helps offset some of the costs.  I've oversimplified, and
>>> it's a very complex problem for most providers; however I know many are
>>> looking at the fees for peering ports go from being in the noise to a
>>> huge part of their cost structure and that doesn't work.
>> 
>> 
>> 
> 
> 

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:

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

[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

[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: Breaking the internet (hotels, guestnet style)

[Owen DeLong]

On Dec 9, 2009, at 10:41 AM, Stephen Sprunk wrote:


Jens Link wrote:

Owen DeLong  writes:

I expect my connections to my mail server to actually reach my  
mail server.  I use TLS and SMTP AUTH as well as IMAP/SSL.  Many  
of the "just works" settings in question break these things badly.




One of my customers has an appliance for his WLAN guest access access
which filters out  records. :-(

j...@bowmore:~$ dig  www.quux.de @8.8.8.8 +short
j...@bowmore:~$



That, unfortunately, is not uncommon.  Actually, it's one of the  
_less_

broken systems I've seen, since IPv4 presumably keeps working.

One major vendor of hotel guestnet equipment returns an A record for
0.0.0.1 if you do an ANY or  query for any hostname--even ones  
that
don't exist.  At least with WinXP, you have to disable IPv6 just to  
get

IPv4 to work!  Worse, their tech support sees nothing wrong with this;
if you disagree, all they'll do is offer a refund.  Unfortunately,  
"take

your money elsewhere" doesn't work when you've already paid for the
hotel room--and they know it.

I've actually extracted significant rebates from Hotels where their  
internet

was provably broken, and, their third-party provider would not resolve
the issue.  More than just a refund of the IP fees. In one case, 1/2 the
cost of my multi-night stay.


Owen

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

[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

[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

Cogent admin request

[Chris Cariffe]

if there's a Cogent NOC admin here, can you please contact me
privately, off the list.  thanks.
-c

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

[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

[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

[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

[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

Data Centre - Advice? (Shenzhen, China)

[Scott E. MacKenzie]

Hi,

 

Does anyone have any great websites to share or advice where I can
locate all the tier one Internet Data Centre (IDC) providers in Shenzhen
China?

 

My second question would be on any advice that anyone can offer about
the problems that can be faced operating your technology foot print
inside the PRC, if there are any?

 

Warm Regards,

 

 

Scott