Re: Any Yahoo DNS admins on list?

[Nolan Berry]

There is a thread going on the outages mailing list talking about this issue.  
Seems to be no failures but increased latency to ns1.yahoo.com and 
ns3.yahoo.com with trace routes showing USA traffic hitting Asia on v6.

Nolan



> On Jan 27, 2017, at 6:30 PM, Brielle Bruns  wrote:
> 
> Hello!
> 
> Don't suppose there's a Yahoo admin in the DNS department that can 
> investigate/debug a Geolocation issue?
> 
> It appears that Yahoo's Geolocation is putting CenturyLink's IPv6 addresses 
> as being in .BR, causing not only the two CL/Qwest recursive servers 
> (205.171.2.65/205.171.3.65/2001:428::1/2001:428::2), but recusive servers 
> hosted on biz customer IPv6 6RD ranges to return non-US Yahoo servers (and be 
> agonizingly slow).
> 
> =
> View from local powerdns recursor, dual stacked, but preferring ipv6 for 
> resolving:
> 
> root@noc:~# dig mg.mail.yahoo.com @127.0.0.2
> 
> ; <<>> DiG 9.9.5-9+deb8u9-Debian <<>> mg.mail.yahoo.com @127.0.0.2
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50638
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;mg.mail.yahoo.com.INA
> 
> ;; ANSWER SECTION:
> mg.mail.yahoo.com.1349INCNAME
> fd-geoycpi-uno.gycpi.b.yahoodns.net.
> fd-geoycpi-uno.gycpi.b.yahoodns.net. 300 IN A200.152.162.161
> fd-geoycpi-uno.gycpi.b.yahoodns.net. 300 IN A200.152.162.135
> 
> ;; Query time: 240 msec
> ;; SERVER: 127.0.0.2#53(127.0.0.2)
> ;; WHEN: Fri Jan 27 17:20:52 MST 2017
> ;; MSG SIZE  rcvd: 116
> 
> =
> View from CL/Qwest IPv4 (likely dual stacked) and IPv6 recursors:
> 
> root@noc:~# dig mg.mail.yahoo.com @205.171.2.65
> 
> ; <<>> DiG 9.9.5-9+deb8u9-Debian <<>> mg.mail.yahoo.com @205.171.2.65
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8308
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;mg.mail.yahoo.com.INA
> 
> ;; ANSWER SECTION:
> mg.mail.yahoo.com.758INCNAME
> fd-geoycpi-uno.gycpi.b.yahoodns.net.
> fd-geoycpi-uno.gycpi.b.yahoodns.net. 138 IN A200.152.162.161
> fd-geoycpi-uno.gycpi.b.yahoodns.net. 138 IN A200.152.162.135
> 
> ;; Query time: 17 msec
> ;; SERVER: 205.171.2.65#53(205.171.2.65)
> ;; WHEN: Fri Jan 27 17:21:35 MST 2017
> ;; MSG SIZE  rcvd: 127
> 
> 
> root@noc:~# dig mg.mail.yahoo.com @2001:428::1
> 
> ; <<>> DiG 9.9.5-9+deb8u9-Debian <<>> mg.mail.yahoo.com @2001:428::1
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24138
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;mg.mail.yahoo.com.INA
> 
> ;; ANSWER SECTION:
> mg.mail.yahoo.com.464INCNAME
> fd-geoycpi-uno.gycpi.b.yahoodns.net.
> fd-geoycpi-uno.gycpi.b.yahoodns.net. 214 IN A200.152.162.161
> fd-geoycpi-uno.gycpi.b.yahoodns.net. 214 IN A200.152.162.135
> 
> ;; Query time: 46 msec
> ;; SERVER: 2001:428::1#53(2001:428::1)
> ;; WHEN: Fri Jan 27 17:23:38 MST 2017
> ;; MSG SIZE  rcvd: 127
> 
> =
> Google recursor for reference:
> 
> root@noc:~# dig mg.mail.yahoo.com @8.8.8.8
> 
> ; <<>> DiG 9.9.5-9+deb8u9-Debian <<>> mg.mail.yahoo.com @8.8.8.8
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13327
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;mg.mail.yahoo.com.INA
> 
> ;; ANSWER SECTION:
> mg.mail.yahoo.com.1459INCNAME
> fd-geoycpi-uno.gycpi.b.yahoodns.net.
> fd-geoycpi-uno.gycpi.b.yahoodns.net. 184 IN A216.115.100.124
> fd-geoycpi-uno.gycpi.b.yahoodns.net. 184 IN A208.71.44.31
> fd-geoycpi-uno.gycpi.b.yahoodns.net. 184 IN A216.115.100.123
> fd-geoycpi-uno.gycpi.b.yahoodns.net. 184 IN A208.71.44.30
> 
> ;; Query time: 27 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Fri Jan 27 17:21:59 MST 2017
> ;; MSG SIZE  rcvd: 159
> 
> 
> 
> For reference, CL/Qwest's IPv6 range for 6RD is 2602::/24.
> 
> This appears to be impacting Yahoo, Yahoo Mail, Flickr, etc (aka Yahoo owned 
> properties).
> 
> 
> Thanks!
> 
> -- 
> Brielle Bruns
> The Summit Open Source Development Group
> http://www.sosdg.org/ http://www.ahbl.org

Re: DNS CAA records...

[Nolan Berry]

So a quick look into this I see one potential real world example:


;; ANSWER SECTION:
google.com.129INA216.58.218.142
google.com.74411INNSns4.google.com.
google.com.74411INNSns1.google.com.
google.com.74411INNSns2.google.com.
google.com.74411INNSns3.google.com.
google.com.3054INTXT"v=spf1 include:_spf.google.com ~all"
google.com.64IN2607:f8b0:4000:802::200e
google.com.54475INTYPE257\# 19 
0005697373756573796D616E7465632E636F6D


In RFC 6844 section 7.1 it states


"IANA has assigned Resource Record Type 257 for the CAA Resource Record Type"


and I am seeing:


google.com.54475INTYPE257\# 19 
0005697373756573796D616E7465632E636F6D



Nolan Berry

Linux Systems Engineer

DNS Engineering

Rackspace Hosting


From: NANOG <nanog-boun...@nanog.org> on behalf of Eric Tykwinski 
<eric-l...@truenet.com>
Sent: Tuesday, January 17, 2017 6:04:31 PM
To: nanog list
Subject: DNS CAA records...

So I’ve come across this on Qualys and just wondering if there’s any practical 
examples out there in the wild.
I know some BIND guys are on here, so I’m sure I’m missing something from the 
RFCs.
Just wanted to test this out on my play domains before putting it out in the 
wild...

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300

Re: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization

[Nolan Berry]

System automation and life cycle management is exponentially easier when you 
have uniform environments.  I am in the process of standardizing global 
infrastructure and developing the automation process now.

Nolan


From: NANOG  on behalf of valdis.kletni...@vt.edu 

Sent: Monday, December 26, 2016 7:55 PM
To: Chris Grundemann
Cc: nanog@nanog.org
Subject: Re: Benefits (and Detriments) of Standardizing Network Equipment in a 
Global Organization

On Fri, 23 Dec 2016 15:36:10 -0500, Chris Grundemann said:

> A global hospitality organization with 100+ locations recently asked us how
> to weigh the importance of standardizing infrastructure across all their
> locations versus allowing each international location to select on their
> own kit.

The first question that comes to mind is:

Does the organization have any centralized IT, or is *that* done by
each location?  The procurement directives need to be coming from the
group that actually does day-to-day support of each location, or the
resulting culture clash will cause issues

Re: Nat

[Berry Mobley]

At 08:22 PM 12/16/2015, Randy Bush wrote:

> We need to put some pain onto everyone that is IPv4 only.

this is the oppress the workers so they will revolt theory.  load of
crap.

make ipv6 easier to deploy, especially in enterprise.  repeat the
previous sentence 42 times.


This. I'm in an enterprise with some stubborn vendors, and none of 
them are even talking about ipv6. It won't help me to move (and it 
won't help you to get well if you're here) if my users can't get to 
their stuff.


Berry 

Re: Nat

[Berry Mobley]

At 08:22 PM 12/16/2015, Randy Bush wrote:

> We need to put some pain onto everyone that is IPv4 only.

this is the oppress the workers so they will revolt theory.  load of
crap.

make ipv6 easier to deploy, especially in enterprise.  repeat the
previous sentence 42 times.


This. I'm in an enterprise with some stubborn vendors, and none of 
them are even talking about ipv6. It won't help me to move (and it 
won't help you to get well if you're here) if my users can't get to 
their stuff.


Berry 

Re: The state of TACACS+

[Berry Mobley]

At 11:06 AM 12/29/2014, you wrote:


On 12/29/2014 10:32 AM, Colton Conor wrote:
My fear would be we would hire an outsourced tech. After a certain 
amount of time we would have to let this part timer go, and would 
disabled his or her username and password in TACAS. However, if 
that tech still knows the root password they could still remotely 
login to our network and cause havoc. The thought of having to 
change the root password on hundreds of devices doesn't sound 
appealing either every time an employee is let go. To make matters 
worse we are using an outsourced firm for some network management, 
so the case of hiring and firing is fairly consistent.
You can setup your aaa in most devices so tacacs+ is allowed first 
and the local password is only usable if tacacs+ is unreachable.  In 
that case, even if you fire someone you can just remove them from 
tacacs and they can't get in.


At that point you will want to do a global password change of the 
local password since it's compromised, but it's not an immediate concern.


You should also have access lists or firewall rules on all your 
devices which only allow login from specific locations.  If you fire 
someone then you remove their access to that location (their VPN 
credentials, username and password for UNIX login, etc), which also 
makes it harder for them to log back into your network even if they 
know the local device password.


Umm...what do you guys do when the network is down?

All of our engineers know the 'default' username/pw - but it is not 
usable unless the AAA server is unreachable. I don't know of a way we 
could do circuit troubleshooting with that password locked up in a 
safe somewhere. Yes, it's a pain to change when people leave - but it 
would be a much larger pain to do deployments without it, I think.


Berry 

Re: The state of TACACS+

[Berry Mobley]

At 11:06 AM 12/29/2014, you wrote:


On 12/29/2014 10:32 AM, Colton Conor wrote:
My fear would be we would hire an outsourced tech. After a certain 
amount of time we would have to let this part timer go, and would 
disabled his or her username and password in TACAS. However, if 
that tech still knows the root password they could still remotely 
login to our network and cause havoc. The thought of having to 
change the root password on hundreds of devices doesn't sound 
appealing either every time an employee is let go. To make matters 
worse we are using an outsourced firm for some network management, 
so the case of hiring and firing is fairly consistent.
You can setup your aaa in most devices so tacacs+ is allowed first 
and the local password is only usable if tacacs+ is unreachable.  In 
that case, even if you fire someone you can just remove them from 
tacacs and they can't get in.


At that point you will want to do a global password change of the 
local password since it's compromised, but it's not an immediate concern.


You should also have access lists or firewall rules on all your 
devices which only allow login from specific locations.  If you fire 
someone then you remove their access to that location (their VPN 
credentials, username and password for UNIX login, etc), which also 
makes it harder for them to log back into your network even if they 
know the local device password.


Umm...what do you guys do when the network is down?

All of our engineers know the 'default' username/pw - but it is not 
usable unless the AAA server is unreachable. I don't know of a way we 
could do circuit troubleshooting with that password locked up in a 
safe somewhere. Yes, it's a pain to change when people leave - but it 
would be a much larger pain to do deployments without it, I think.


Berry 

Default routes on BGP routers with full feeds

[Berry Mobley]

I'm wondering how many of you who are multihomed also add default 
routes pointing to your providers from whom you are receiving full feeds.


If so, why? If not, why not?

Thanks,

Berry

Default routes on BGP routers with full feeds

[Berry Mobley]

I'm wondering how many of you who are multihomed also add default 
routes pointing to your providers from whom you are receiving full feeds.


If so, why? If not, why not?

Thanks,

Berry

Re: Recommendation on NTP appliances/devices

[Berry Mobley]

We have symmetricom (now microsemi) and are very happy with them, but we use 
the roof mounted gps antennas. They will peer with public ntp severs if that 
would work for you. 

David Hubbard dhubb...@dino.hostasaurus.com wrote:

Anyone have recommendations on NTP appliances; i.e. make, model, gps vs
cell, etc.?  Roof/outdoor/window access not available.  Would ideally
need to be able to handle bursts of up to a few thousand simultaneous
queries.  Needs IPv6 support.

Thanks!

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[berry]

 On 11/01/2013 01:08 PM, Gary Buhrmaster wrote:

[...]


 Given what we now know about the breadth of the NSA operations, and the
 likelihood that this is still only the tip of the iceberg - would anyone
 still point to NSA guidance on avoiding monitoring with any sort of
 confidence?

 There has always been cognitive dissonance in the dual roles of the NSA:
 1. The NSA monitors.
 2. The NSA provides guidance on how to avoid being monitored.

 Conflict?

 -DMM

As a local 'barbecue baron' said about his brother's competing
restaurants: I taught him everything he knows about barbecue. I just
didn't teach him everything _I_ know about barbecue.

Re: Equipment Shuffing Cart Recommendations

[Berry Mobley]

Get one of these. Lifetime warranty. We need more here because I can 
never keep up with mine.


http://www.norriscorp.com/carts/700.html



At 02:27 PM 1/21/2013, you wrote:

Anyone have any good recommendations for an equipment cart to 
shuffle IT/Telco equipment around between an office/colo ?


Id like something able to carry ~6 1U Dell servers at once, and 
maybe make it over an elevator gap without a running start. 
Collapsible would also be nice, if I can throw it in the back of a 
car once in a while is a big plus.


Thanks

-Mike

--
Michael Vallaly mvall...@nolatency.com

Re: Eaton 9130 UPS feedback

[Berry Mobley]

At 02:59 PM 11/13/2012, Seth Mattinen wrote:

Does anyone use Eaton 9130 series UPS for anything? I'm curious how
they've worked out for you.

I bought a 700VA model to give it a whirl versus the traditional APC
since the Eaton is an online type with static bypass and also does some
high efficiency thing where it normally stays on bypass, but the first
thing it did on the bench was have the inverter/rectifier or bypass
section catch on fire and destroy itself.


My basic rule is that if the first one I buy catches fire, I don't 
buy any more.


Berry 

Color vision for network techs

[Berry Mobley]

Hello,

Do any of you do any color vision screening in your interview 
process? How do those of you with color vision impairments 
compensate? I'd never considered this until I was in one of our 
facilities with my son (who has limited color vision) and we had a 
discussion about the LEDs. He could only determine on/off - not 
amber/red/green on the equipment we had. I'm wondering if we need a 
color vision requirement (or test) as part of our hiring requirements.


Berry Mobley

Re: Level 3 BGP Advertisements

[Berry Mobley]

[...]

Please, unless you really know why you need to do otherwise, just 
originate your aggregates.


+1

Wake on LAN in the enterprise

[Berry Mobley]

Hello...

I'm trying to get a handle on implementation of wake-on-lan in an 
enterprise environment.  Cisco gear, lots of subnets.  I've made it 
work with directed broadcasts, but I'd really rather not have 40 or 
50 'ip helper-address x.x.x.bcastaddr' statements on the vlans with 
the SMS servers.


Are there any enterprises that are doing this for large (100+) 
numbers of subnets?  I can't find a single example anywhere with more 
than 2 networks.


I've searched the Cisco-NSP archives as well with no luck, but maybe 
I didn't go back far enough.


Thanks for any help you can provide.

Berry Mobley

Re: Wake on LAN in the enterprise

[Berry Mobley]

Thanks, everyone, for the replies - looks like I need to get my 
server team interested in knowing broadcast addresses for hosts, and 
making SMS send to those addresses.


I do have the 'ip directed-broadcast acl' in place, but the servers 
are currently sending the magic packets to the all-1's 
address.  Maybe I can get that changed.


Berry

Re: Dynamic IP log retention = 0?

[Alec Berry]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jon Lewis wrote:

 If port scans really bother you, then you should setup a system to detect 
 them, and regularly rebuild ACLs/null route lists/etc. to stop them in 
 near real time.  AFAIK, Cisco sells such a product, as do other network 
 vendors I'm sure.

It is pretty easy to do this with pf running on OpenBSD (et al). You can
even set a timeout so that additions to a banned list get removed after
x {hours,days,weeks}


table evil persist {0.0.0.0}

block in log quick from evil to any label evil

pass in quick proto {tcp,udp} from any to any port 1024:65000 \
synproxy state \
(max-src-conn-rate 5/15, overload evil flush global)

Pick a port range and/or ip address range combo that you don't have
anything running on for the rule, then as scans take place the offending
IP will be added to the evil table and blocked. OK, there are some
additional details for expiring the evil IPs, and of course your own
network details. But this has worked quite well for me, and I love
checking the evil table from time to time to see who's been naughty.

My best guess is other firewalls can do something similar.

...
alec

- --
`
/ Alec Berry \__
| Senior Partner and Director of Technology \
| PGP/GPG key 0xE8E9030F|
| http://alec.restontech.com/#PGP   |
|---|
| RestonTech, Ltd.  |
|http://www.restontech.com/ |
|  Phone: (703) 234-2914|
\___/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJt+1tREO1P+jpAw8RAhkXAKDlZK1gv00oxswqjkRu6TmG7JkoGACfcdSX
S0mIegpuf++j+yMTjoNHLOI=
=nIb7
-END PGP SIGNATURE-

Re: [Fwd:] Nvidia NICs with duplicate mac addresses

[Alec Berry]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robert E. Seastrom wrote:

 Just when you thought this couldn't happen any more...
 
 Copying from a different email list...
 
 mac address 04:4b:80:80:80:03, was showing up in multiple places  
 across the network. 

That's why I stick to ARCNET :)

...
alec

- --
`
/ Alec Berry \__
| Senior Partner and Director of Technology \
| PGP/GPG key 0xE8E9030F|
| http://alec.restontech.com/#PGP   |
|---|
| RestonTech, Ltd.  |
|http://www.restontech.com/ |
|  Phone: (703) 234-2914|
\___/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIwWLuREO1P+jpAw8RAm32AKCL5p2yYfeVcUR7BJ16HfS6Rs3XjwCePlc2
wh3Vf0a6MgCe48BICDJufu0=
=+YLd
-END PGP SIGNATURE-

Re: ingress SMTP

[Alec Berry]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robert Bonomi wrote:

 One small data-point -- on a personal vanity domain, approximately 2/3 of 
 all the spam (circa 15k junk emails/month) was 'direct to inbound MX' 
 transmissions.  The vast majority of this is coming from end-user machines 
 outside of North America. 

This confirms the limited data I have. I configure my edge firewall (pf)
to drop anything to/from the Spamhaus DROP list, as well as sendmail to
use their XBL. The DROP list seems like it blocks mostly MX lookups
(nice to see the blocking of mail start so early in the process!), so it
is hard to say how many SMTP connections never happen (remote server/bot
does not know where to connect). The XBL list, which is mostly
residential IPs around the world, seems to be the single most effective
technique in blocking incoming traffic-- on port 25. Obviously, these
connections are coming from ISPs that do *not* block egress TCP 25.

Slightly off topic-- I found it quite easy to configure the DROP list to
work with pf (or is that the other way around?). I would be happy to
share the small Perl script that updates the pf table. When I configured
the DROP list on a free public wireless system I maintain, I was amazed
at how much egress traffic it blocked-- obviously rogue/bad/evil
webservers, IRC hosts, etc.

I wonder if anyone else is using it that way?

...
alec

- --
`
/ Alec Berry \__
| Senior Partner and Director of Technology \
| PGP/GPG key 0xE8E9030F|
| http://alec.restontech.com/#PGP   |
|---|
| RestonTech, Ltd.  |
|http://www.restontech.com/ |
|  Phone: (703) 234-2914|
\___/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIv+YdREO1P+jpAw8RAnWzAKDxOmneR6j6DBVyo5/CO1wRYngorQCgo9SJ
sArBQqQStX7zIuYK3qo1El0=
=C2FM
-END PGP SIGNATURE-

Re: ingress SMTP

[Alec Berry]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark Andrews wrote:

  You do realise that there a mail clients that check MX
  records *before* submitting email (or before on sending the
  email) so that typos get detected in the client before any
  email is sent from the client.

I think you are not familiar with the difference between the DROP list
and the XBL. The DROP list is *not* an RBL!

I do not allow any traffic at all to or from the DROP list-- including
MX lookups. I can't think of any good reasons why I would.

The XBL is used only to block mail transport-- it is configured in
sendmail, not at the firewall. The scenario you lay out will still work:

- - end user on a dial up that happens to be on the XBL (common)
- - end user queries MX records, either directly or via their name server
- - end user submits mail to their SMTP server (not on the XBL)
- - SMTP server transports mail to my system

Unless one of those systems mentioned above is a hijacked name server in
Kyiv (and thus on the DROP list), everything will work.

...
alec

- --
`
/ Alec Berry \__
| Senior Partner and Director of Technology \
| PGP/GPG key 0xE8E9030F|
| http://alec.restontech.com/#PGP   |
|---|
| RestonTech, Ltd.  |
|http://www.restontech.com/ |
|  Phone: (703) 234-2914|
\___/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIv/dTREO1P+jpAw8RAqiyAKDJt7FbFvplXB1JTe+dKDOOSXUijQCdH/cZ
4m4o9vE5FS96huARs2Rq5yU=
=Paen
-END PGP SIGNATURE-

Re: ingress SMTP

[Alec Berry]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Thomas wrote:
 I think this all vastly underrates the agility of the bad guys. So
 lots of ISP's have blocked port 25. Has it made any appreciable
 difference? Not that I can tell. If you block port 25, they'll just
 use another port and a relay if necessary.

I'm pretty sure it has, although without aggregate stats from various
ISPs it is hard to tell. Since mail transport is exclusively on port 25
(as opposed to mail submission), a bot cannot just hop to another port.

 But the thing that's really pernicious about this sort of policy is
 that it's a back door policy for ISP's to clamp down on all outgoing
 ports in the name of security.

I don't think ISPs have anything to gain by randomly blocking ports.
They may block a port that is often used for malicious behavior
(135-139, 194, 445, 1433, 3306 come to mind) as a way to reduce their
support calls-- but they would have to balance that with the risk of
loosing customers. It's not as much a slippery slope as much as it is a
tightrope act (yes-- I am metaphorically challenged).

...
alec

- --
`
/ Alec Berry \__
| Senior Partner and Director of Technology \
| PGP/GPG key 0xE8E9030F|
| http://alec.restontech.com/#PGP   |
|---|
| RestonTech, Ltd.  |
|http://www.restontech.com/ |
|  Phone: (703) 234-2914|
\___/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIvsINREO1P+jpAw8RAvKNAKC83NJgwv4EakAv/jw5biO79D/xEwCgldZ+
JHkb3LboeAD2GC77vcb06Y4=
=nfVP
-END PGP SIGNATURE-

Re: ingress SMTP

[Alec Berry]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Winders, Timothy A wrote:

 We have not setup a port 587 smtp submit server.  Our smtp servers run only
 on port 25.

Sorry to be harsh, but that's just not the right way to do things
these days. At the very least, you can run stunnel to allow incoming
mail submission on port 465 (SMTP + SSL).

 So, for us, having ISPs block port 25 is a problem.

Read: for us, running a mail server is a problem

...
alec

- --
`
/ Alec Berry \__
| Senior Partner and Director of Technology \
| PGP/GPG key 0xE8E9030F|
| http://alec.restontech.com/#PGP   |
|---|
| RestonTech, Ltd.  |
|http://www.restontech.com/ |
|  Phone: (703) 234-2914|
\___/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIvs30REO1P+jpAw8RAtBUAJsFmxNfi9UGcDCfmkDs7Tni+iHuKwCgtKyg
01N7WA1sXhzuWsYD4ZG6go0=
=66IU
-END PGP SIGNATURE-