Re: Outgoing SMTP Servers

[Mike Jones]

On 26 October 2011 05:44, Owen DeLong  wrote:
> Mike recommends a tactic that leads to idiot hotel admins doing bad things.
> You bet I'll criticize it for that.
>
> His mechanism breaks things anyway. I'll criticize it for that too.
>

Just to clarify, I was merely pointing out a possible argument behind
someone doing it that way. For a hotel wifi type network I would
consider it a valid option that is arguably (to some) better than
straight blocking for the average user, for other types of networks
with more long term user bases I would be very surprised if there was
any justification for redirecting as opposed to simply blocking. If
someone were asking for my advice on deploying a network like that I
would have to point out that the extra effort required to
deploy/support it is unlikely to be worth it. Blocking port 25 is
unlikely to cause much of a problem compared to a single incident with
that SMTP server that your hotel now needs to maintain.

In a perfect world we would all have as many static globally routed IP
addresses as we want with nothing filtered, in the real world a
residential ISP who gives their customers globally routable IPv4
addresses for each computer (ie. a CPE that supports multiple
computers without NAT) with no filtering at all is probably going to
have to hire more support staff to deal with it, even before people
from this list start null routing their IP space for being a rogue ISP
that clearly doesn't give a damn etc :)

Perhaps our next try with IPv6 can be a perfect world where hosts are
secure enough for open end to end connectivity and infected machines
are rarely a problem? IPv6 enabled systems are more secure than a lot
of the systems we have floating around on IPv4 networks, but I still
think we're going to end up with port blocking becoming reasonably
common on IPv6 as well once that starts getting widely deployed to
residential users.

- Mike

Re: Outgoing SMTP Servers

[Robert Drake]

On 10/25/2011 10:19 PM, Blake Hudson wrote:

I didn't see anyone address this from the service provider abuse
department perspective. I think larger ISP's got sick and tired of
dealing with abuse reports or having their IP space blocked because of
their own (infected) residential users sending out spam. The solution
for them was to block the spam. The cheapest/easiest way to do this was
to block TCP 25 between subs and the internet, thus starting a trend. If
587 becomes popular, spammers will move on and the same ISPs that
blocked 25 will follow suit.
Actually, it doesn't work that way because of what submission is 
designed to do.  I just posted another email about it so I won't repeat 
it, but basically you should think of blocking port 25 as a list of 
who's authorized to send emails, not as a port we just killed for fun 
and we're waiting for the spammers next move.




A better solution would have been to prevent infection or remove
infected machines from the network(strong abuse policies, monitoring,
give out free antivirus software, etc). Unfortunately, several major
players (ATT, for example) went down the road of limiting internet
access. Now that they've had a taste, some of them feel they can block
other ports or applications like p2p (Comcast), Netflix (usage based
billing on Bell, ATT, others).


As an ISP, I liked seeing abuse complaints drop to near zero when we did 
this.  We spent about a month fixing some people who don't use webmail 
(most regular customers don't use an MUA anymore) and had our share of 
third-party MTA's that refused to turn on submission (no idea why, these 
were usually business-class comp accounts so we moved them to a business 
pool and dropped their acls) but overall we probably had less than 100 
calls from doing this and it made our lives easier.


Now I know you said you wanted us to be preventative and to treat the 
problem, but that's just impractical.  We got 5000 abuse emails a month 
for (at the time) ~20k customers.  Were 1/4 of them spamming?  No, but 
the ones that were spamming generated automated reports from everyone.


None of them were ever legitimate spammers.  They were all users who 
clicked on a funny puppy picture their mom sent, or some other thing 
that set their computer on fire and had it spitting out gobs of porno 
links to everyone it could find.  So it wasn't a set of problem users, 
it was just a random sampling of everyone's not-so-PC-savvy relatives.


So, lets say we wrote software to collate those reports and got it down 
to 30 legitimate people (if we're lucky).  Do we block their IP's and 
wait for them to call in then send them to geek squad?  Do we try to fix 
their infected PC over the phone?   At this point, no matter what we do 
they're going to get sent to a tier 2 tech which means at least 2 phone 
calls and whatever revenue we might have gotten from them is gone for 
quite a while.  We can have one guy tied up all day every day trying to 
process abuse issues or we can just shut down port 25 and the problem 
magically disappears.


Is their laptop uninfected?  No, but they can no longer infect any other 
customer in our network or anyone elses network, thus reducing global 
infections.  We've made the world a better place and saved ourselves 
some money.   Unfortunately, the first coffee shop they go to that 
doesn't block port 25 is going to be a new spam source but we can't save 
them all.


It may be possible in the future we'll have a more convenient method to 
police PC's but the network access controls that exist right now aren't 
flexible enough to allow different networks to set different policies, 
so if it's a work laptop and they have a domain administrator then 
802.1x might not be possible, and mandating they have firewall or 
anti-virus turned on (or a specific version/that it's updated, etc) 
might not be possible.


Most customers rail against controls anyway.  You don't want port 25 
blocked so how would you feel if we mandated you install our ad-ware 
mcafee client and scanned your computer every 15 minutes?  And when you 
think about it, if the big boys gave up and blocked port 25 and stopped 
offering free anti-virus and a backrub when you call in, how can we 
afford to compete with that?




Unfortunately, I don't see the trend reversing. I'm afraid that Internet
freedoms are likely to continue to decline and an "Unlimited" Internet
experience won't exist at the residential level in 5+ years.


I hope that you're exaggerating for effect, but you might be right.  
Small providers have trouble competing right now because of all the 
advantages the carriers have in the market.  Some of the ways small 
providers can distinguish themselves is through support, or offering 
things a big player won't.  So in some cases it's better to find a 
regional ISP and go with them because they may work with you, and they 
may be a little more lenient with some things.


I don't think port 25 is worth making a stand on 

Re: Outgoing SMTP Servers

[Robert Drake]

On 10/25/2011 11:17 AM, Owen DeLong wrote:

But that applies to port 25 also, so, I'm not understanding the difference.


Other people running open port 587s tends to be quite self-correcting.


At this point, so do open port 25s.


The differences is in intentions from the user.   All SMTP servers are 
supposed to accept incoming email to their domain on port 25, if they 
get a connection from a random IP they can check spf, dkim and dns 
blacklists but that's all they can do to see the reputation of the 
sender.  Blocking port 25 is an ISP based list of who is allowed to send 
SMTP.


Port 587 is supposed to only be used for MUA-MTA communications.  If 
mx.hello.com gets a 587 connection from anyone and they say "mail from: 
" the server can drop that as wrong.


Yes it's nasty and dumb, but it works better than spf, DKIM and other 
technology right now.Maybe spf could be extended into reverse zones 
and who they're permitted to send mail for (too many ISP's don't let 
even business users update reverse records), maybe spf or a protocol 
like it will become required in the future so you know who can be 
trusted when they connect, or reputation or greylisting will take off, 
except for having to store reputation about all IP's and all /64s so the 
database isn't easily maintained.  I think spf with dkim (with caveats 
worked out) would be the best solution but anything that requires a flag 
day with SMTP basically isn't gonna happen.




Owen


Robert

Re: Outgoing SMTP Servers

[Owen DeLong]

On Oct 25, 2011, at 9:33 PM, William Herrin wrote:

> On Tue, Oct 25, 2011 at 8:15 PM, Owen DeLong  wrote:
>> On Oct 25, 2011, at 3:16 PM, William Herrin wrote:
>>> If you're doing the "right" thing, sending email via encrypted,
>>> authenticated mechanisms, then you're doing it TCP ports 587 or 443.
>>> Where Mike's mechanism obstructs you not at all.
>>> 
>> Depends. Some hotel admins aren't so bright. That's the problem. Not
>> everyone hears block outbound SMTP on port 25, they hear block outbound
>> SMTP and stop listening. Boom, 25, 465, 587 all get turned off.
> 
> Sure. But that's not Mike's mechanism. It's ignorant hotel guy's
> mechanism. Don't penalize Mike because some other fool does something
> similar but wrong.
> 
Mike recommends a tactic that leads to idiot hotel admins doing bad things.
You bet I'll criticize it for that.

His mechanism breaks things anyway. I'll criticize it for that too.

> 
>>> If you're still doing the wrong thing, trying to talk to remote SMTP
>>> servers on TCP port 25, why should his mechanisms not punish you?
>> 
>> It's not wrong to talk to them on port 25. It's wrong to allow 
>> unauthenticated
>> remote users to send on your own port 25 for relay purposes.
> 
> Sure it is. Same way it's wrong to have an open relay or an unsecured
> proxy. It isn't 1995 any more.
> 

As I said, we can agree to disagree about what is wrong. I know your position.
I still don't agree with it.

Owen

Re: Outgoing SMTP Servers

[William Herrin]

On Tue, Oct 25, 2011 at 8:15 PM, Owen DeLong  wrote:
> On Oct 25, 2011, at 3:16 PM, William Herrin wrote:
>> If you're doing the "right" thing, sending email via encrypted,
>> authenticated mechanisms, then you're doing it TCP ports 587 or 443.
>> Where Mike's mechanism obstructs you not at all.
>>
> Depends. Some hotel admins aren't so bright. That's the problem. Not
> everyone hears block outbound SMTP on port 25, they hear block outbound
> SMTP and stop listening. Boom, 25, 465, 587 all get turned off.

Sure. But that's not Mike's mechanism. It's ignorant hotel guy's
mechanism. Don't penalize Mike because some other fool does something
similar but wrong.


>> If you're still doing the wrong thing, trying to talk to remote SMTP
>> servers on TCP port 25, why should his mechanisms not punish you?
>
> It's not wrong to talk to them on port 25. It's wrong to allow unauthenticated
> remote users to send on your own port 25 for relay purposes.

Sure it is. Same way it's wrong to have an open relay or an unsecured
proxy. It isn't 1995 any more.

Regards,
Bill Herrin



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Outgoing SMTP Servers

[Graham Beneke]

On 26/10/2011 04:35, Blake Hudson wrote:
> An infected machine can just as easily send out mail on port 587 as it
> can using port 25. It's not hard for bot net hearders to come up with a
> list of valid credentials stolen from email clients, via key loggers, or
> simply guessed through probability. I see it every day.

The difference is that it is the relay that accepts the spam on 587 that
ends up on the blacklists. A mail server with a sysadmin that might care
and probably sees business impact in not fixing the problem. As apposed
to an end user that doesn't give a hoot.

Compromised mail authentication details are quick and easy to take down.
A server mis-configured as an open relay on 587 is a one time fix.

End users infected with nasties are a support desk blackhole. Hours of
time explaining to moms and pops how to download anti-virus and install
it and configure it and run it...

-- 
Graham Beneke

Re: Outgoing SMTP Servers

[Graham Beneke]

On 25/10/2011 23:03, Mike Jones wrote:
> On 25 October 2011 20:52, Alex Harrowell  wrote:
>> Ricky Beam  wrote:
>>
>>> Works perfectly even in networks where a VPN doesn't and the idiot
>>> hotel
>>> intercepts port 25 (not blocks, redirects to *their* server.)
>>>
>>> --Ricky
>>
>> Why do they do that?
>>
> 
> If the hotel simply blocks port 25 then my email is broken, if they
> allow it then my email is broken (as my ISP doesn't let the hotel
> relay through their mail servers), however if the hotel redirects 25
> to their own open relays then in theory my email should work fine.

This only works if the MUA is configured to send to an un-AUTH'd relay
normally. It normally fails spectacularly when the MUA tries to present
AUTH that the relay doesn't understand or accept.

I know of at least one large consumer ISP that does this across their
network. Their argument was that it caused less of a support overhead
when they implemented since no one had to change any settings (in theory).

The reality is that the support overhead just transfers to the
hosting/mail provider. "I send mail via your server and you are
rejecting it." And then the hosting provider gets to explain how the IAP
is in fact mangling their customers mail.

Spam from mis-configured and compromised hosts is a big issue and on an
access network. Even worse with dynamically allocated IPs. Users dial up
and inherit blacklistings from previous customers and often entire
prefixes will be listed by the RBL if the snoeshow effect is big enough.

I dislike the idea of blocking port 25 (though it has been effective in
dealing with major outbreaks.) We ended up building an new product that
works as an appliance. All port 25 is piped through and the packets are
passed on un-touched. Spamminess is scored and with some clever
integration with RADIUS, the score is applied to a username. If the
threshold is exceeded then the user is dynamically blocked or directed
to a honeypot (depending on the requirements). And if the user redials
then the block follows them.

After deploying that our abuse desk went quiet ;-)

-- 
Graham Beneke

Re: Outgoing SMTP Servers

[Blake Hudson]

J wrote the following on 10/25/2011 9:25 PM:

Blake Hudson wrote:

If
587 becomes popular, spammers will move on and the same ISPs that
blocked 25 will follow suit.

I don't see this happening as easily.  Authenticated means an easier
shutdown of an account, rather than some form of port block/etc.
An infected machine can just as easily send out mail on port 587 as it 
can using port 25. It's not hard for bot net hearders to come up with a 
list of valid credentials stolen from email clients, via key loggers, or 
simply guessed through probability. I see it every day.


I will shutdown a compromised account on my end, but that doesn't stop 
ATT's infected subscriber from spamming 100 other servers using 100 
other stolen credentials. I may also send an abuse report to ATT if they 
have an infected machine trying to perform a dictionary attack or brute 
force logins against my port 587 SMTP server. ATT's going to deal with 
the abuse reports as cheaply as possible. If they receive enough, I have 
no doubt they'll repeat past mistakes.

Re: Outgoing SMTP Servers

[J]

Blake Hudson wrote:
> If
> 587 becomes popular, spammers will move on and the same ISPs that
> blocked 25 will follow suit.

I don't see this happening as easily.  Authenticated means an easier
shutdown of an account, rather than some form of port block/etc.

> A better solution would have been to prevent infection or remove
> infected machines from the network(strong abuse policies, monitoring,
> give out free antivirus software, etc).

We have 2/3 of that.  Antivirus helps some, but has some side-effects on the
helpdesk, if they're also the first response tier.

I find it strange mentioning 'monitoring' alongside 'freedoms', though.

> Unfortunately, I don't see the trend reversing. I'm afraid that Internet
> freedoms are likely to continue to decline and an "Unlimited" Internet
> experience won't exist at the residential level in 5+ years.

I'll agree with that.

Re: Outgoing SMTP Servers

[Blake Hudson]

I didn't see anyone address this from the service provider abuse 
department perspective. I think larger ISP's got sick and tired of 
dealing with abuse reports or having their IP space blocked because of 
their own (infected) residential users sending out spam. The solution 
for them was to block the spam. The cheapest/easiest way to do this was 
to block TCP 25 between subs and the internet, thus starting a trend. If 
587 becomes popular, spammers will move on and the same ISPs that 
blocked 25 will follow suit.


A better solution would have been to prevent infection or remove 
infected machines from the network(strong abuse policies, monitoring, 
give out free antivirus software, etc). Unfortunately, several major 
players (ATT, for example) went down the road of limiting internet 
access. Now that they've had a taste, some of them feel they can block 
other ports or applications like p2p (Comcast), Netflix (usage based 
billing on Bell, ATT, others).


Unfortunately, I don't see the trend reversing. I'm afraid that Internet 
freedoms are likely to continue to decline and an "Unlimited" Internet 
experience won't exist at the residential level in 5+ years.


--Blake

Re: Senate Bill S.968

[Joly MacFie]

effective FUD site

http://demandprogress.org/



On Tue, Oct 25, 2011 at 8:53 PM, Christopher Morrow  wrote:

> On Tue, Oct 25, 2011 at 12:58 PM, Jason LeBlanc 
> wrote:
> > Anyone read this?
> >
> > http://en.wikipedia.org/wiki/Protect_IP_Act
> >
> > More attempts to regulate Internet usage.
> >
> > Not in favor.
>
> folk ought to reach out to the largest opponent on this:
>  Senator Wyden  
>
> and see if he's got names of staffers in your local senators' offices
> to call/chat/etc...
>
> i also ended up giving a short preso on this topic at the last nanog,
> slides:
>  
> (focused on what you may have to do/think-about if/when something like
> this becomes a law)
>
> and there was a decent write up on it in the LATimes some time ago:
>  
>
> -chris
>
>


-- 
---
Joly MacFie  218 565 9365 Skype:punkcast
WWWhatsup NYC - http://wwwhatsup.com
 http://pinstand.com - http://punkcast.com
 VP (Admin) - ISOC-NY - http://isoc-ny.org
--
-

Re: the route is not in our bgprouter

[Christopher Morrow]

deric, you really ought to hire a consultant for this sort of thing...
just sayin!

On Tue, Oct 25, 2011 at 9:49 PM, Deric Kwok  wrote:
> Hi
>
> Our upstream provider said that destination network is blocking our ip.
>
> Now my question is how we can know it

you can't really, if they do things right. (Aside from just not getting there)

> If this network is blocking us, the traceroute should reach out our
> bgp router to go further nodes before that network, right

presumably, unless the destination is a direct peer.

> 2nd question is how they block us to not allow the route to advertise
> from our upstream to our bgp router.

probably they just don't accept your route... why do you think your
route isn't propogated beyond your border(s)?

> ls it possible?
>
> Thank you so much
>
>
>
> On Tue, Oct 25, 2011 at 9:35 AM, Patrick Sumby
>  wrote:
>> If your provider has a looking glass then that is a good start to see if
>> they have the route in their routing tables. http://www.traceroute.org/ is a
>> good start for searching for a looking glass on their website.
>>
>> Have you checked to see if you're actually recieving the route? You may be
>> getting the route but not installing it into your routing table for some
>> reason (eg invalid next hop or a router from another provider is being
>> prefered). Do you have prefix lists inbound from your provider that could be
>> blocking a route?
>>
>> show ip route X.X.X.X
>> and
>> show ip bgp route X.X.X.X
>>
>> will give different information.
>>
>> If you've covered the above and not found the answer then try talking to
>> your provider.
>>
>> Regards
>> Patrick
>>
>>
>> On 25/10/2011 13:26, Deric Kwok wrote:
>>>
>>> Hi
>>>
>>> When we try to reach to outside ip, this route doesn't have in our bgp
>>> router
>>>
>>> How can we check whether it doesn't advertise from our upstream to us?
>>>
>>> Any web site and tools can help?
>>>
>>> Thank you
>>>
>>
>>
>>
>
>

Re: the route is not in our bgprouter

[Deric Kwok]

Hi

Our upstream provider said that destination network is blocking our ip.

Now my question is how we can know it

If this network is blocking us, the traceroute should reach out our
bgp router to go further nodes before that network, right

2nd question is how they block us to not allow the route to advertise
from our upstream to our bgp router.
ls it possible?

Thank you so much



On Tue, Oct 25, 2011 at 9:35 AM, Patrick Sumby
 wrote:
> If your provider has a looking glass then that is a good start to see if
> they have the route in their routing tables. http://www.traceroute.org/ is a
> good start for searching for a looking glass on their website.
>
> Have you checked to see if you're actually recieving the route? You may be
> getting the route but not installing it into your routing table for some
> reason (eg invalid next hop or a router from another provider is being
> prefered). Do you have prefix lists inbound from your provider that could be
> blocking a route?
>
> show ip route X.X.X.X
> and
> show ip bgp route X.X.X.X
>
> will give different information.
>
> If you've covered the above and not found the answer then try talking to
> your provider.
>
> Regards
> Patrick
>
>
> On 25/10/2011 13:26, Deric Kwok wrote:
>>
>> Hi
>>
>> When we try to reach to outside ip, this route doesn't have in our bgp
>> router
>>
>> How can we check whether it doesn't advertise from our upstream to us?
>>
>> Any web site and tools can help?
>>
>> Thank you
>>
>
>
>

Re: Colocation providers and ACL requests

[Jay Ashworth]

- Original Message -
> From: "Keegan Holley" 

> I'm assuming colo means hosting, and the OP misspoke. Most colo providers
> don't provide active network for colo (as in power and rack only) customers.

Most?

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

Re: Colocation providers and ACL requests

[Keegan Holley]

I'm assuming colo means hosting, and the OP misspoke.  Most colo providers
don't provide active network for colo (as in power and rack only) customers.

2011/10/25 Paul Graydon 

> On 10/25/2011 08:43 AM, Christopher Pilkington wrote:
>
>> Is it common in the industry for a colocation provider, when requested to
>> put an egress ACL facing us such as:
>>
>>   deny udp any a.b.c.d/24 eq 80
>>
>> …to refuse and tell us we must subscribe to their managed DDOS product?
>>
>> -cjp
>>
>>
>>  For colo?  No, filtering is the customers concern, unless failure to do
> so is causing a problem for the colo network.  Such services are almost
> always paid for add-ons to a colo package.  The colocation business is
> usually fairly low on the profit margin with most companies trying to get
> away with the bare minimum possible over and above the basics.
>
>
>

Re: Senate Bill S.968

[Christopher Morrow]

On Tue, Oct 25, 2011 at 12:58 PM, Jason LeBlanc  wrote:
> Anyone read this?
>
> http://en.wikipedia.org/wiki/Protect_IP_Act
>
> More attempts to regulate Internet usage.
>
> Not in favor.

folk ought to reach out to the largest opponent on this:
  Senator Wyden  

and see if he's got names of staffers in your local senators' offices
to call/chat/etc...

i also ended up giving a short preso on this topic at the last nanog, slides:
  
(focused on what you may have to do/think-about if/when something like
this becomes a law)

and there was a decent write up on it in the LATimes some time ago:
  

-chris

Re: Outgoing SMTP Servers

[Jeroen van Aart]

Owen DeLong wrote:

It's both unacceptable in my opinion and common. There are even those
misguided souls that will tell you it is best practice, though general 
agreement,
even among them seems to be that only 25/tcp should be blocked and that
465 and 587 should not be blocked.


From my consumer POV.

If you get a static IP with your provider, whether it is home internet 
or co-location, there should not be anything blocked. You're paying 
extra for the static IP in the case of home internet and the least you 
can expect is no blocking. Otherwise what's the point?


You can always block/cancel later in case of abuse obviously.

Of course this (and the below) does not apply in case of dynamically 
assigned IPs to a pool of home internet users.



Best practice is to do what works and block as much SPAM as possible without
destroying the internet in the process. There are those who argue that blocking
25/tcp does not destroy the internet. By and large, they are the same ones who
believe NAT was good for us.


There shouldn't be any spam filtering or blocking on a static IP at the 
ISP level. The ISP should limit itself to filtering at their own mail 
servers.


Greetings,
Jeroen

--
Earthquake Magnitude: 3.6
Date: Tuesday, October 25, 2011 18:20:24 UTC
Location: Arizona
Latitude: 34.8137; Longitude: -112.5391
Depth: 5.00 km

Re: Outgoing SMTP Servers

[Owen DeLong]

On Oct 25, 2011, at 3:16 PM, William Herrin wrote:

> On Tue, Oct 25, 2011 at 5:56 PM, Owen DeLong  wrote:
>> Put another way, your mechanism rewards those
>> doing the wrong thing while punishing those of us
>> sending our email via encrypted and authenticated
>> mechanisms.
> 
> Owen,
> 
> If you're doing the "right" thing, sending email via encrypted,
> authenticated mechanisms, then you're doing it TCP ports 587 or 443.
> Where Mike's mechanism obstructs you not at all.
> 
Depends. Some hotel admins aren't so bright. That's the problem. Not
everyone hears block outbound SMTP on port 25, they hear block outbound
SMTP and stop listening. Boom, 25, 465, 587 all get turned off.

Worse, if they redirect 25, then, it can still cause problems with many clients
because they will try 25 first assuming that if it is broken it will fail. 
There''s
nothing wrong with that approach IMHO. There's no reason one can't
send email over 25 just as well as 587 as long as they're authenticating
and doing it over an encrypted channel. My client generally tries in this
order: 25, 587, 465, 443, 80. If people merely break things by blocking
SMTP on one or more ports, then it works. If they do stupid pet tricks
like redirecting all connections to other addresses to their own server,
then it breaks horribly.

> If you're still doing the wrong thing, trying to talk to remote SMTP
> servers on TCP port 25, why should his mechanisms not punish you?
> 

It's not wrong to talk to them on port 25. It's wrong to allow unauthenticated
remote users to send on your own port 25 for relay purposes.

This is the problem... I don't buy your idea of what constitutes doing
the wrong thing and neither do the developers of many email clients.

Owen

Re: Colocation providers and ACL requests

[Paul Graydon]

On 10/25/2011 08:43 AM, Christopher Pilkington wrote:

Is it common in the industry for a colocation provider, when requested to put 
an egress ACL facing us such as:

   deny udp any a.b.c.d/24 eq 80

…to refuse and tell us we must subscribe to their managed DDOS product?

-cjp


For colo?  No, filtering is the customers concern, unless failure to do 
so is causing a problem for the colo network.  Such services are almost 
always paid for add-ons to a colo package.  The colocation business is 
usually fairly low on the profit margin with most companies trying to 
get away with the bare minimum possible over and above the basics.

Re: Colocation providers and ACL requests

[William Herrin]

On Tue, Oct 25, 2011 at 2:43 PM, Christopher Pilkington  wrote:
> Is it common in the industry for a colocation provider, when
> requested to put an egress ACL facing us such as:
>
>  deny udp any a.b.c.d/24 eq 80
>
> …to refuse and tell us we must subscribe to their
> managed DDOS product?

Christopher,

That seems reasonable to me. You're buying colo and transit, not
firewall service. If you want firewall service, that's extra.

If you do decide to move, I suggest a carrier neutral facility so that
you can change transit providers without moving your equipment. The
easier it is for you to walk away, the more accommodating vendors tend
to be.

Seeing much port 80 UDP traffic? My curiosity is piqued.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Outgoing SMTP Servers

[Douglas Otis]

On 10/25/11 12:31 PM, Ricky Beam wrote:

 On Tue, 25 Oct 2011 12:55:58 -0400, Owen DeLong 
 wrote:
> Wouldn't the right place for that form of rejection to occur be at
> the mail server in question?



 In a perfect world, yes. When you find a perfect world, send us an
 invite.



> I reject lots of residential connections...

 The real issue here is *KNOWING* who is residential or not. Only
 the ISP knows for sure; and they rarely tell others. The various
 blocklists are merely guessing. Using a rDNS name is an even worse
 guess.


Agreed.   Don't expect a comprehensive list based upon rDNS containing 
specific host names with IPv6.  That would represent a never ending 
process to collect.



> However, senders who authenticate legitimately or legitimate
> sources of email (and yes, some spam sources too) connect just
> fine.



 Authenticated sources can be traced and shutoff. If a random
 cablemodem user has some bot spewing spam, the only way to cut off
 the spam is to either (gee) block outbound port 25, or turn their
 connection off entirely. As a responsible admin, I'll take the
 least disruptive path. (I'll even preemptively do so.)


Blocking ports is not free, but don't expect all DSL providers to 
unblock port 25 unless it is for a business account.  Price 
differentials help pay for port blocking.


In a perfect world, all SMTP transactions would cryptographically 
authenticate managing domains for the MTA.  With less effort and 
resources (than that needed to check block lists) IPv6 could continue to 
work through LSNs aimed at helping those refusing to offer IPv6 
connectivity.  Blocking at the prefix requires block list resources 65k 
times greater than what is currently needed for IPv4.  IPv6 
announcements seem likely to expand another 6 fold fairly soon as well.


In comparison, cryptographic authentication would be more practical, but 
a hybrid Kerberos scheme supported by various third-party service 
providers could reduce the overhead.  Is it time for AuthenticatedMTP?


-Doug

Re: Outgoing SMTP Servers

[William Herrin]

On Tue, Oct 25, 2011 at 5:56 PM, Owen DeLong  wrote:
> Put another way, your mechanism rewards those
>doing the wrong thing while punishing those of us
>sending our email via encrypted and authenticated
>mechanisms.

Owen,

If you're doing the "right" thing, sending email via encrypted,
authenticated mechanisms, then you're doing it TCP ports 587 or 443.
Where Mike's mechanism obstructs you not at all.

If you're still doing the wrong thing, trying to talk to remote SMTP
servers on TCP port 25, why should his mechanisms not punish you?

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Outgoing SMTP Servers

[Owen DeLong]

No no no no no. 

The problem with your theory below is that:

1. It is by far best for users to authenticate to send mail. 

2. Your "solution" works only for unencrypted unauthenticated users that ignore 
the certificate presented by the mail server. 

Put another way, your mechanism rewards those doing the wrong thing while 
punishing those of us sending our email via encrypted and authenticated 
mechanisms. 

That's a very bad thing. 

Owen


Sent from my iPhone

On Oct 25, 2011, at 15:03, Mike Jones  wrote:

> On 25 October 2011 20:52, Alex Harrowell  wrote:
>> Ricky Beam  wrote:
>> 
>>> Works perfectly even in networks where a VPN doesn't and the idiot
>>> hotel
>>> intercepts port 25 (not blocks, redirects to *their* server.)
>>> 
>>> --Ricky
>> 
>> Why do they do that?
>> 
> 
> My home ISP run an open relay on port 25 with IP-based authentication,
> so I might configure my laptops email client to send email via
> smtp.myisp.com port 25 (many/most? residential ISPs have
> unauthenticated relays, even ISPs that tell you to use authentication
> often have another server next to it that doesn't need authentication
> for customer IP space)
> 
> If the hotel simply blocks port 25 then my email is broken, if they
> allow it then my email is broken (as my ISP doesn't let the hotel
> relay through their mail servers), however if the hotel redirects 25
> to their own open relays then in theory my email should work fine.
> 
> They could always tell people "there is a relay at 10.0.0.25 so you
> can change your settings to use that", however by redirecting all port
> 25 traffic there they are effectively forcibly auto-configuring anyone
> who was already configured to send via an unauthenticated server on
> port 25. They are probably acting under the assumption that the only
> people using 25 are using it for unauthenticated access, I believe
> most servers that do use authentication tell users to use alternate
> ports so this is probably a reasonable assumption.
> 
> Compared to straight blocking of port 25 it's probably better as long
> as the relay it is redirecting you to works properly so you don't have
> to try and diagnose issues - However considering the quality of the
> average hotel network I suspect most of them that are trying to do
> this probably have it set to redirect to a dead server anyway.
> 
> - Mike

Re: Outgoing SMTP Servers

[Mike Jones]

On 25 October 2011 20:52, Alex Harrowell  wrote:
> Ricky Beam  wrote:
>
>>Works perfectly even in networks where a VPN doesn't and the idiot
>>hotel
>>intercepts port 25 (not blocks, redirects to *their* server.)
>>
>>--Ricky
>
> Why do they do that?
>

My home ISP run an open relay on port 25 with IP-based authentication,
so I might configure my laptops email client to send email via
smtp.myisp.com port 25 (many/most? residential ISPs have
unauthenticated relays, even ISPs that tell you to use authentication
often have another server next to it that doesn't need authentication
for customer IP space)

If the hotel simply blocks port 25 then my email is broken, if they
allow it then my email is broken (as my ISP doesn't let the hotel
relay through their mail servers), however if the hotel redirects 25
to their own open relays then in theory my email should work fine.

They could always tell people "there is a relay at 10.0.0.25 so you
can change your settings to use that", however by redirecting all port
25 traffic there they are effectively forcibly auto-configuring anyone
who was already configured to send via an unauthenticated server on
port 25. They are probably acting under the assumption that the only
people using 25 are using it for unauthenticated access, I believe
most servers that do use authentication tell users to use alternate
ports so this is probably a reasonable assumption.

Compared to straight blocking of port 25 it's probably better as long
as the relay it is redirecting you to works properly so you don't have
to try and diagnose issues - However considering the quality of the
average hotel network I suspect most of them that are trying to do
this probably have it set to redirect to a dead server anyway.

- Mike

Re: Outgoing SMTP Servers

[Robert Bonomi]

> From nanog-bounces+bonomi=mail.r-bonomi@nanog.org  Tue Oct 25 14:53:32 
> 2011
> Subject: Re: Outgoing SMTP Servers
> From: Alex Harrowell 
> Date: Tue, 25 Oct 2011 20:52:46 +0100
> To: Ricky Beam , Jeroen Massar 
> Cc: nanog@nanog.org
>
> Ricky Beam  wrote:
>
> >Works perfectly even in networks where a VPN doesn't and the idiot
> >hotel  
> >intercepts port 25 (not blocks, redirects to *their* server.)
> >
> >--Ricky
>
> Why do they do that?

Because some "quarter-asswit"[1] sold them that it was a good idea -- maybe
on the basis tht it was: "easy" to to rate-limit -- supposedly an anti-spam 
measure; "easy" to 'forward' all the patron traffic to a relay server of the
hotel's choice, so that, -if- it is spam, the outside world sees it coming 
from an already segregated address-space; "easy" to implement a holding 
queue, so that if they _do_ detect spam, they can drop _all_ the spam 
messages, even those sent before the spam threshold was detected.; etc., 
etc., ad nauseum.




[1] "half-assed half-wit", reduced to a single term. 

Re: Outgoing SMTP Servers

[Alex Harrowell]

Ricky Beam  wrote:

>Works perfectly even in networks where a VPN doesn't and the idiot
>hotel  
>intercepts port 25 (not blocks, redirects to *their* server.)
>
>--Ricky

Why do they do that?

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: Outgoing SMTP Servers

[Ricky Beam]

On Tue, 25 Oct 2011 07:15:00 -0400, Jeroen Massar  wrote:

On that iToy of yours it is just a flick of a switch, presto.


Where "flick of a switch" is actually several steps...
  Settings -> Network -> VPN... there's your switch.
  Wait for it to connect
  Go back to mail, refresh...

And one's VPN profile has to be setup in advance.

Plus, it doesn't always work.  I gather you've never been in a network  
where an IPSec VPN wouldn't connect.  I've seen it too many times. (I've  
even seen ISPs where it didn't work.  Apparently GRE isn't IP to them.)   
An SSL VPN will often get around that, but it's additional  
hardware/software/setup/licenses/etc. (For a Cisco ASA, it's an additional  
word in your vpn setup, and a license... base "demo" is only 2  
connections.)


It's *MUCH* easier to setup the mail server on ports 465 and 587, require  
auth and tls.  Done right, it's 100% transparent to the traveling user.   
Works perfectly even in networks where a VPN doesn't and the idiot hotel  
intercepts port 25 (not blocks, redirects to *their* server.)


--Ricky

Re: Outgoing SMTP Servers

[Ricky Beam]

On Tue, 25 Oct 2011 12:55:58 -0400, Owen DeLong  wrote:

Wouldn't the right place for that form of rejection to occur be at the
mail server in question?


In a perfect world, yes.  When you find a perfect world, send us an invite.


I reject lots of residential connections...


The real issue here is *KNOWING* who is residential or not.  Only the ISP  
knows for sure; and they rarely tell others.  The various blocklists are  
merely guessing.  Using a rDNS name is an even worse guess.



However, senders who authenticate legitimately or legitimate sources
of email (and yes, some spam sources too) connect just fine.


Authenticated sources can be traced and shutoff.  If a random cablemodem  
user has some bot spewing spam, the only way to cut off the spam is to  
either (gee) block outbound port 25, or turn their connection off  
entirely.  As a responsible admin, I'll take the least disruptive path.  
(I'll even preemptively do so.)


--Ricky

Re: Colocation providers and ACL requests

[Keegan Holley]

2011/10/25 Brandon Galbraith 

> On Tue, Oct 25, 2011 at 1:46 PM, Keegan Holley 
> wrote:
>
>> Depends on the provider.  Many just do not want to manage hundreds of
>> customer ACL's on access routers.  Especially when it would compete with a
>> managed service (firewall, IDP, DDOS) of some sort.  Some still are under
>> the impression that ACL's are software based and their giant $100k+ edge
>> box
>> would crash if they configured them for any reason.
>>
>>
> Conversely, some don't want to be paid for bare colocation (at bare
> colocation prices) and have to then support 1000+ rules (yes, 1000+) with
> 10-20 change requests per day. YMMV/slippery slope/service scope/etc.
>

They are no worse than route filters or bandwidth increases, or IP address
requests/changes.  The provider should be able to do a temporary filter if
the customer needs it though rather than forcing them to wait weeks or
months to install a managed service/device.  I agree permanent custom ACL's
with indefinite growth/management could be considered a managed service and
should either be an additional charge or not allowed at all.

Re: Colocation providers and ACL requests

[PC]

Why not put the ACL on your ingress side at your switch or router?

I would typically not expect a colo provider to provide this service unless
I'm paying extra for it.

The smaller they are, the more likely they are to do so to keep you happy,
but I certainly wouldn't be asking this request unless it was some 11th hour
DOS-prevention request.

Even then, they may not want to install this ACL as ultimately they should
be billing you for this UDP traffic (which this ACL, may prevent their
billing system from metering).



On Tue, Oct 25, 2011 at 12:53 PM, Christopher Pilkington wrote:

> On Oct 25, 2011, at 2:50 PM, Brandon Galbraith wrote:
>
> > On Tue, Oct 25, 2011 at 1:46 PM, Keegan Holley <
> keegan.hol...@sungard.com>wrote:
> >
> >> Depends on the provider.  Many just do not want to manage hundreds of
> >>
> > Conversely, some don't want to be paid for bare colocation (at bare
> > colocation prices) and have to then support 1000+ rules (yes, 1000+) with
>
> This is a large colo provider on the Upper West Side of Manhattan, so I
> (naively) expected more of them.  It looks like this will be their final
> nail though.
>
> -cjp
>
>
>

Re: Colocation providers and ACL requests

[Christopher Pilkington]

On Oct 25, 2011, at 2:50 PM, Brandon Galbraith wrote:

> On Tue, Oct 25, 2011 at 1:46 PM, Keegan Holley 
> wrote:
> 
>> Depends on the provider.  Many just do not want to manage hundreds of
>> 
> Conversely, some don't want to be paid for bare colocation (at bare
> colocation prices) and have to then support 1000+ rules (yes, 1000+) with

This is a large colo provider on the Upper West Side of Manhattan, so I 
(naively) expected more of them.  It looks like this will be their final nail 
though.

-cjp

Re: HE.Net 6TO4 relay

[Meftah Tayeb]

Dear Mike
i would say thank you a lot for your valuable reply :)
Alex brock allready replied to my query
issue is only in Chicago, New york is perfectly up and runing :)
Thank you !

- Original Message - 
From: "Mike Leber" 

To: 
Sent: Tuesday, October 25, 2011 9:42 PM
Subject: Re: HE.Net 6TO4 relay




On 10/24/11 9:18 AM, Meftah Tayeb wrote:

hello HE.NET
did you drop the 6to4 delegated prefix 192.88.99.0/24 ?
if yes please would you drop it from your BGP routing table anounced ?
thank you
 Meftah Tayeb
IT Consulting


Hi!

For issues like this please email i...@he.net or n...@he.net with IPv4 and 
IPv6 traceroutes to the addresses involved.


We are running and announcing 6to4 relays globally.

We did recently turn on IPv6 RPF facing our 6to4 relays.  This was done 
for basic network security reasons.


There has been no change in traffic levels through our 6to4 relays, 
however it does appear to have affected a very limited number of people (I 
know of 1 other we already helped, you would be the second if this is your 
issue) that were using our 6to4 boxes to de-encapsulate packets with IPv6 
source addresses not in the IPv6 6to4 range.


If this was you, the fix is to either:

1) interconnect natively with us and announce your IPv6 address space to 
us via BGP (and don't use 6to4)
2) use your own already existing native IPv6 connectivity with your 
address space (and don't use 6to4)
3) make packets that you send to our 6to4 relays source from your 6to4 
interface with your IPv6 6to4 address
or 4) request a IPv6 BGP tunnel and run BGP so that you can announce your 
address space to us (and don't use 6to4).


If you email us we can work with you to diagnose your specific situation.

Mike.



__ Information from ESET NOD32 Antivirus, version of virus 
signature database 6573 (20111025) __


The message was checked by ESET NOD32 Antivirus.

http://www.eset.com






__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6573 (20111025) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Re: Colocation providers and ACL requests

[Brandon Galbraith]

On Tue, Oct 25, 2011 at 1:46 PM, Keegan Holley wrote:

> Depends on the provider.  Many just do not want to manage hundreds of
> customer ACL's on access routers.  Especially when it would compete with a
> managed service (firewall, IDP, DDOS) of some sort.  Some still are under
> the impression that ACL's are software based and their giant $100k+ edge
> box
> would crash if they configured them for any reason.
>
>
Conversely, some don't want to be paid for bare colocation (at bare
colocation prices) and have to then support 1000+ rules (yes, 1000+) with
10-20 change requests per day. YMMV/slippery slope/service scope/etc.

Re: Colocation providers and ACL requests

[Keegan Holley]

Depends on the provider.  Many just do not want to manage hundreds of
customer ACL's on access routers.  Especially when it would compete with a
managed service (firewall, IDP, DDOS) of some sort.  Some still are under
the impression that ACL's are software based and their giant $100k+ edge box
would crash if they configured them for any reason.

2011/10/25 Christopher Pilkington 

> Is it common in the industry for a colocation provider, when requested to
> put an egress ACL facing us such as:
>
>  deny udp any a.b.c.d/24 eq 80
>
> …to refuse and tell us we must subscribe to their managed DDOS product?
>
> -cjp
>
>
>
>

Re: HE.Net 6TO4 relay

[Mike Leber]

On 10/24/11 9:18 AM, Meftah Tayeb wrote:

hello HE.NET
did you drop the 6to4 delegated prefix 192.88.99.0/24 ?
if yes please would you drop it from your BGP routing table anounced ?
thank you
 Meftah Tayeb
IT Consulting


Hi!

For issues like this please email i...@he.net or n...@he.net with IPv4 
and IPv6 traceroutes to the addresses involved.


We are running and announcing 6to4 relays globally.

We did recently turn on IPv6 RPF facing our 6to4 relays.  This was done 
for basic network security reasons.


There has been no change in traffic levels through our 6to4 relays, 
however it does appear to have affected a very limited number of people 
(I know of 1 other we already helped, you would be the second if this is 
your issue) that were using our 6to4 boxes to de-encapsulate packets 
with IPv6 source addresses not in the IPv6 6to4 range.


If this was you, the fix is to either:

1) interconnect natively with us and announce your IPv6 address space to 
us via BGP (and don't use 6to4)
2) use your own already existing native IPv6 connectivity with your 
address space (and don't use 6to4)
3) make packets that you send to our 6to4 relays source from your 6to4 
interface with your IPv6 6to4 address
or 4) request a IPv6 BGP tunnel and run BGP so that you can announce 
your address space to us (and don't use 6to4).


If you email us we can work with you to diagnose your specific situation.

Mike.

Colocation providers and ACL requests

[Christopher Pilkington]

Is it common in the industry for a colocation provider, when requested to put 
an egress ACL facing us such as:

  deny udp any a.b.c.d/24 eq 80

…to refuse and tell us we must subscribe to their managed DDOS product?

-cjp

Re: Vancouver, BC providers

[Ryan Wilkins]

Sounds like a possible candidate for some of the last mile wireless equipment 
available.  The problem is the wireless equipment may cost more than the punch 
to the face and gut.  How much bandwidth are you talking?  You're looking at 
somewhere around $16k for a 300 Mbps Motorola PTP 800 solution at 18 or 23 GHz. 
 BridgeWave has some 1 Gbps stuff out there for about $30k at 80 GHz, but falls 
out during very heavy rains at 2 miles link distance.  BridgeWave just recently 
announced some 1 Gbps radio links at 18 and 23 but that's all I know about them.

Ryan

On Oct 25, 2011, at 1:27 PM, Ravi Pina  wrote:

> I suppose I could have been a little more clear on what I've
> already found.  Sorry.
> 
> The last mile for the Level3 is coming on Telus (after a punch to
> the face and gut for build out fee) so I'd like someone else.
> Shaw does not offer service without what I suspect is another
> punch to the face for a build out.  Bell didn't return any of my
> inquiries via email of voice message.
> 
> -r
> 
> On Tue, Oct 25, 2011 at 03:21:13PM -0300, jim deleskie wrote:
>> I'd expect you could find, Rogers, Telus, Shaw and Bell all there.
>> 
>> 
>> -jim
>> 
>> On Tue, Oct 25, 2011 at 3:18 PM, Ravi Pina  wrote:
>>> Hi,
>>> 
>>> I was looking for some metro-e options in Vancouver, BC CA
>>> specifically in the Downtown/Gastown area.  I'm finding the area
>>> isn't the most built up so options are very thin.
>>> 
>>> We already have service through Level3, but would like a
>>> secondary one.  It doesn't have to be tier1 or even terrestrial
>>> service so much as reliable and vouched for.
>>> 
>>> Any tips would be appreciated.
>>> 
>>> Thanks,
>>> 
>>> -r
>>> 
>>> 
>>> 
> 

Re: Vancouver, BC providers

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> The last mile for the Level3 is coming on Telus (after a punch to
> the face and gut for build out fee) so I'd like someone else.
> Shaw does not offer service without what I suspect is another
> punch to the face for a build out.  Bell didn't return any of my
> inquiries via email of voice message.

You will pay for buildout no matter who you talk to.

Somebody already mentioned Terago.  I can't vouch for how good
their service or coverage is downtown, but they're definately
worth a call if you can't afford the cost of the fibre pull.

--lyndon

RE: Vancouver, BC providers

[Erik Soosalu]

May not suit your needs, but I've used Terago with some success for secondary 
links.


Thanks,
Erik Soosalu

-Original Message-
From: Ravi Pina [mailto:r...@cow.org] 
Sent: Tuesday, October 25, 2011 2:28 PM
To: jim deleskie
Cc: nanog@nanog.org
Subject: Re: Vancouver, BC providers

I suppose I could have been a little more clear on what I've
already found.  Sorry.

The last mile for the Level3 is coming on Telus (after a punch to
the face and gut for build out fee) so I'd like someone else.
Shaw does not offer service without what I suspect is another
punch to the face for a build out.  Bell didn't return any of my
inquiries via email of voice message.

-r

On Tue, Oct 25, 2011 at 03:21:13PM -0300, jim deleskie wrote:
> I'd expect you could find, Rogers, Telus, Shaw and Bell all there.
> 
> 
> -jim
> 
> On Tue, Oct 25, 2011 at 3:18 PM, Ravi Pina  wrote:
> > Hi,
> >
> > I was looking for some metro-e options in Vancouver, BC CA
> > specifically in the Downtown/Gastown area.  I'm finding the area
> > isn't the most built up so options are very thin.
> >
> > We already have service through Level3, but would like a
> > secondary one.  It doesn't have to be tier1 or even terrestrial
> > service so much as reliable and vouched for.
> >
> > Any tips would be appreciated.
> >
> > Thanks,
> >
> > -r
> >
> >
> >

Re: Vancouver, BC providers

[Ravi Pina]

I suppose I could have been a little more clear on what I've
already found.  Sorry.

The last mile for the Level3 is coming on Telus (after a punch to
the face and gut for build out fee) so I'd like someone else.
Shaw does not offer service without what I suspect is another
punch to the face for a build out.  Bell didn't return any of my
inquiries via email of voice message.

-r

On Tue, Oct 25, 2011 at 03:21:13PM -0300, jim deleskie wrote:
> I'd expect you could find, Rogers, Telus, Shaw and Bell all there.
> 
> 
> -jim
> 
> On Tue, Oct 25, 2011 at 3:18 PM, Ravi Pina  wrote:
> > Hi,
> >
> > I was looking for some metro-e options in Vancouver, BC CA
> > specifically in the Downtown/Gastown area.  I'm finding the area
> > isn't the most built up so options are very thin.
> >
> > We already have service through Level3, but would like a
> > secondary one.  It doesn't have to be tier1 or even terrestrial
> > service so much as reliable and vouched for.
> >
> > Any tips would be appreciated.
> >
> > Thanks,
> >
> > -r
> >
> >
> >

Re: Vancouver, BC providers

[jim deleskie]

I'd expect you could find, Rogers, Telus, Shaw and Bell all there.


-jim

On Tue, Oct 25, 2011 at 3:18 PM, Ravi Pina  wrote:
> Hi,
>
> I was looking for some metro-e options in Vancouver, BC CA
> specifically in the Downtown/Gastown area.  I'm finding the area
> isn't the most built up so options are very thin.
>
> We already have service through Level3, but would like a
> secondary one.  It doesn't have to be tier1 or even terrestrial
> service so much as reliable and vouched for.
>
> Any tips would be appreciated.
>
> Thanks,
>
> -r
>
>
>

Vancouver, BC providers

[Ravi Pina]

Hi,

I was looking for some metro-e options in Vancouver, BC CA
specifically in the Downtown/Gastown area.  I'm finding the area
isn't the most built up so options are very thin.

We already have service through Level3, but would like a
secondary one.  It doesn't have to be tier1 or even terrestrial
service so much as reliable and vouched for.

Any tips would be appreciated.

Thanks,

-r

Re: Outgoing SMTP Servers

[Brian Dickson]

Owen wrote:

>On Oct 25, 2011, at 3:29 AM,  wrote:
>
>> On Tue, 25 Oct 2011 02:35:31 PDT, Owen DeLong said:
>>
>>> If they are using someone else's mail server for outbound, how, exactly do 
>>> you control
>>> whether or not they use AUTH in the process?
>>
>> 1) You don't even really *care* if they do or not, because...
>>
>> 2) if some other site is running with an un-AUTHed open port 587, the 
>> miscreants will
>> find it and abuse it just like any other open mail relay. The community will
>> deal with it quick enough so you don't have to. And at that point, it's the
>> open mail relay's IP that ends up on the block lists, not your mail relay's 
>> IP.
>>
>But that applies to port 25 also, so, I'm not understanding the difference.
>
>> Other people running open port 587s tends to be quite self-correcting.
>>
>
>At this point, so do open port 25s.
>
>Owen

I'll try to explain with text stick-diagrams...

The players are:
G - good user
B - botnet host
I - ISP
O - open relay
S - mail-submission relay
V - victim SMTP/mailbox host

It's all about how port-25 traffic containing SPAM gets to machine
"V". (Or not, which is the preferred situation.)

Possible routes include:
B.25 -> (I allows 25) -> O -> V (classic open relay) [SPAM]
B.25 -> (I allows 25) -> V (new mode, and what William Herrin is
talking about) [SPAM]
B.587 -> (I !allow 25) -> V (but that makes no sense - how does B
authenticate to the victim? She doesn't!!) [BLOCKED]
B.587 -> (I !allow 25) -> S (ditto - not an open unauthenticated
relay, only allows authenticated relaying!!!) [BLOCKED]

Meanwhile, we have:
G.587 -> (I !allow 25) -> S.g.587/.25 (mail submission gateway for G)
-> V.25 [NOT-SPAM && NOT-BLOCKED]

S.g is either G's enterprise mail server, or G's home mail server, or
G's ISP themselves, or some other S to which G can authenticate.
S.g receives on 587, and sends on 25, and is a generally reputable
port-25 host (whatever that means).

So, basically, not blocking 587 and blocking 25 removes all the
avenues for direct botnet spam.
Authenticating botnet sources become trackable on auth-hosts, and easy
to shut down.

Is there some path not listed above that could allow a spammer (botnet
host) behind the ISP to send email, without having a relay host to
which it can authenticate, that I'm not seeing?

Brian

HE.Net 6TO4 relay

[Meftah Tayeb]

hello HE.NET
did you drop the 6to4 delegated prefix 192.88.99.0/24 ?
if yes please would you drop it from your BGP routing table anounced ?
thank you
Meftah Tayeb
IT Consulting
http://www.tmvoip.com/ 
phone: +21321656139
Mobile: +213660347746


__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6573 (20111025) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

RE: Outgoing SMTP Servers

[Matt McBride]

We use Mailchannels to route all outbound mail through it, which does a decent 
job of keeping garbage off the Internet and SBLs/RBLs clean. It is dependent on 
PBR so there is overhead to manage it but the product runs on our own hardware.

-Matt

-Original Message-
From: Owen DeLong [mailto:o...@delong.com] 
Sent: Tuesday, October 25, 2011 10:56 AM
To: William Herrin
Cc: nanog@nanog.org
Subject: Re: Outgoing SMTP Servers


On Oct 25, 2011, at 8:46 AM, William Herrin wrote:

> On Tue, Oct 25, 2011 at 5:49 AM, Owen DeLong  wrote:
>> On Oct 24, 2011, at 11:13 PM, William Herrin wrote:
>>> Blocking outbound TCP SYN packets on port 25 from non-servers is
>>> considered a BEST PRACTICE to avoid being the source of snowshoe and
>>> botnet spam. Blocking it from legitimate mail servers... does not make
>>> sense.
>>> 
>>> The SMTP submission port (TCP 587) is authenticated and should
>>> generally not be blocked.
>> 
>> Interesting... Most people I know run the same policy on 25 and 587 these
>> days...
> 
> Owen,
> 
> Perhaps you misunderstand the issue. The issue is not relaying mail
> through someone else's mail server, it's delivering mail to a mailbox
> served by that mail server. 99.99 etc. percent of the time when that's
> done directly from a IP address that's supposed to be user PC it's
> some form of spam. Hence the best practice within the email community
> is to ask the networking community to block those packets outright.
> And its why residential ISPs who fail to tend to find their way into
> Spamcop, Spamhaus and others. Facilitating that sort of network
> filtering is precisely why authenticated SMTP relaying was assigned
> port 587 instead of leaving it on port 25.
> 

Wouldn't the right place for that form of rejection to occur be at the
mail server in question?

Precluding users doing legitimate things just because there are users
who do illegitimate things is damaging to the internet and I will continue
to route around it.

I reject lots of residential connections to my port 25 services every day.
However, senders who authenticate legitimately or legitimate sources
of email (and yes, some spam sources too) connect just fine.

> 
> On Tue, Oct 25, 2011 at 11:28 AM, Carlos Martinez-Cagnazzo
>  wrote:
>> I'm curious how a traveller is supposed to get SMTP relay service
>> when, well, travelling. I am not really sure if I want a VPN for
>> sending a simple email.
> 
> That's what the SMTP submission port (TCP 587) is intended for and
> it's why outbound 587 should not be blocked. In fact, blocking 587 can
> cause problems with folks who use the Sender Policy Framework to
> restrict the servers allowed to pass mail from a particular domain
> outward.
> 

So the spammers move to 587 and problem solved.

Owen

Re: Outgoing SMTP Servers

[Owen DeLong]

On Oct 25, 2011, at 8:46 AM, William Herrin wrote:

> On Tue, Oct 25, 2011 at 5:49 AM, Owen DeLong  wrote:
>> On Oct 24, 2011, at 11:13 PM, William Herrin wrote:
>>> Blocking outbound TCP SYN packets on port 25 from non-servers is
>>> considered a BEST PRACTICE to avoid being the source of snowshoe and
>>> botnet spam. Blocking it from legitimate mail servers... does not make
>>> sense.
>>> 
>>> The SMTP submission port (TCP 587) is authenticated and should
>>> generally not be blocked.
>> 
>> Interesting... Most people I know run the same policy on 25 and 587 these
>> days...
> 
> Owen,
> 
> Perhaps you misunderstand the issue. The issue is not relaying mail
> through someone else's mail server, it's delivering mail to a mailbox
> served by that mail server. 99.99 etc. percent of the time when that's
> done directly from a IP address that's supposed to be user PC it's
> some form of spam. Hence the best practice within the email community
> is to ask the networking community to block those packets outright.
> And its why residential ISPs who fail to tend to find their way into
> Spamcop, Spamhaus and others. Facilitating that sort of network
> filtering is precisely why authenticated SMTP relaying was assigned
> port 587 instead of leaving it on port 25.
> 

Wouldn't the right place for that form of rejection to occur be at the
mail server in question?

Precluding users doing legitimate things just because there are users
who do illegitimate things is damaging to the internet and I will continue
to route around it.

I reject lots of residential connections to my port 25 services every day.
However, senders who authenticate legitimately or legitimate sources
of email (and yes, some spam sources too) connect just fine.

> 
> On Tue, Oct 25, 2011 at 11:28 AM, Carlos Martinez-Cagnazzo
>  wrote:
>> I'm curious how a traveller is supposed to get SMTP relay service
>> when, well, travelling. I am not really sure if I want a VPN for
>> sending a simple email.
> 
> That's what the SMTP submission port (TCP 587) is intended for and
> it's why outbound 587 should not be blocked. In fact, blocking 587 can
> cause problems with folks who use the Sender Policy Framework to
> restrict the servers allowed to pass mail from a particular domain
> outward.
> 

So the spammers move to 587 and problem solved.

Owen

Senate Bill S.968

[Jason LeBlanc]

Anyone read this?

http://en.wikipedia.org/wiki/Protect_IP_Act

More attempts to regulate Internet usage.

Not in favor.

Jason

Re: Outgoing SMTP Servers

[Randy Bush]

> I'm curious how a traveller is supposed to get SMTP relay service
> when, well, travelling. I am not really sure if I want a VPN for
> sending a simple email.

vpn

i use openvpn

when roaming, i am often on poorly protected wireless.  i openvpn to
home

randy

Re: Outgoing SMTP Servers

[David E. Smith]

On Tue, Oct 25, 2011 at 10:57, Dennis Burgess wrote:

>
> [dmb] This is the exact question, why, do you NEED a SMTP Relay on ANY
> network.  Your domain has a mail server out on the net that if you
> authenticate to, I am sure will relay your mail, and the reverse DNS and SPF
> records would match then as well.  Why does the local internet provide NEED
> to relay though their server, regardless of the port.
>
>
Not every domain actually has a mail server that allows remote
authentication/relay. People hosting small vanity domains with cheap hosting
providers might not. Maybe people using small ISPs with less-than-top-notch
staff. Heck, maybe there's just a short-term issue with the mail server, and
you still want/need to send something out right now, so you use your ISP's
mail system.

David Smith
MVN.net

RE: Outgoing SMTP Servers

[Dennis Burgess]

> 
> I'm curious how a traveller is supposed to get SMTP relay service when, well,
> travelling. I am not really sure if I want a VPN for sending a simple email.
> 
> And I can understand (although I am not convinced that doing so is such a
> great idea) blocking 25/tcp outgoing, as most botnets will try that method of
> delivery. However, I do believe that outgoing 465 SHOULD always be
> allowed.
> 
> regards
> 
> Carlos
> 

[dmb] This is the exact question, why, do you NEED a SMTP Relay on ANY network. 
 Your domain has a mail server out on the net that if you authenticate to, I am 
sure will relay your mail, and the reverse DNS and SPF records would match then 
as well.  Why does the local internet provide NEED to relay though their 
server, regardless of the port.  

> On Tue, Oct 25, 2011 at 10:43 AM, Bjørn Mork  wrote:
> > Owen DeLong  writes:
> >
> >> It's both unacceptable in my opinion and common. There are even those
> >> misguided souls that will tell you it is best practice, though
> >> general agreement, even among them seems to be that only 25/tcp
> >> should be blocked and that
> >> 465 and 587 should not be blocked.
> >
> > It is definitely considered best practice in some areas.  See e.g.
> > http://translate.google.com/translate?hl=en&u=http://ikt-norge.no/wp-c
> > ontent/uploads/2010/10/bransjenorm-SPAM.pdf
> > (couldn't find an english original, but the google translation looks
> > OK)
> >
> > The document is signed by all major ISPs in Norway as well as the
> > Norwegian research and education network operator, so it must be
> > considered a local "best practice" whether you like it or not.
> >
> > Note that only port 25/tcp is blocked and that some of the ISPs offer
> > a per-subscriber optout.
> >
> > Eh, this was the Northern Aurope NOG, wasn't it?
> >
> >
> >
> >
> > Bjørn
> >
> >
> 
> 
> 
> --
> --
> =
> Carlos M. Martinez-Cagnazzo
> http://www.labs.lacnic.net
> =

Re: ARIN and Legacy IPv4 Assignement from CA*Net (Canarie)

[John Curran]

On Oct 25, 2011, at 12:57 PM, Alain Hebert wrote:
> 
>Hi,
> 
>From what we've been seeing there is a lot of those legacy assignement 
> about to be freed. ( Yeah! )
> 
>We're having some issue with a few Legacy that where miss-assigned when 
> transfered from CA*Net to ARIN back in the day.
>( We kept the control on them since we had access to the POC's and OrgID, 
> which is not the case anymore for some reason )
> 
>If anyone has a hint (off-list please) about how to go about fixing those 
> broken assignement, we had no luck finding the process on ARIN.

Alain - 
 
   Please send email to  with specifics.

   You'll need an officer to attest to the error made in the 
   registrations, but it's clear that Pubnix has been the one
   using the address blocks in question.

Thanks,
/John

John Curran
President and CEO
ARIN

Re: Outgoing SMTP Servers

[William Herrin]

On Tue, Oct 25, 2011 at 5:49 AM, Owen DeLong  wrote:
> On Oct 24, 2011, at 11:13 PM, William Herrin wrote:
>> Blocking outbound TCP SYN packets on port 25 from non-servers is
>> considered a BEST PRACTICE to avoid being the source of snowshoe and
>> botnet spam. Blocking it from legitimate mail servers... does not make
>> sense.
>>
>> The SMTP submission port (TCP 587) is authenticated and should
>> generally not be blocked.
>
> Interesting... Most people I know run the same policy on 25 and 587 these
> days...

Owen,

Perhaps you misunderstand the issue. The issue is not relaying mail
through someone else's mail server, it's delivering mail to a mailbox
served by that mail server. 99.99 etc. percent of the time when that's
done directly from a IP address that's supposed to be user PC it's
some form of spam. Hence the best practice within the email community
is to ask the networking community to block those packets outright.
And its why residential ISPs who fail to tend to find their way into
Spamcop, Spamhaus and others. Facilitating that sort of network
filtering is precisely why authenticated SMTP relaying was assigned
port 587 instead of leaving it on port 25.


On Tue, Oct 25, 2011 at 11:28 AM, Carlos Martinez-Cagnazzo
 wrote:
> I'm curious how a traveller is supposed to get SMTP relay service
> when, well, travelling. I am not really sure if I want a VPN for
> sending a simple email.

That's what the SMTP submission port (TCP 587) is intended for and
it's why outbound 587 should not be blocked. In fact, blocking 587 can
cause problems with folks who use the Sender Policy Framework to
restrict the servers allowed to pass mail from a particular domain
outward.

Regards,
Bill Herrin




-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Outgoing SMTP Servers

[Owen DeLong]

On Oct 25, 2011, at 4:15 AM, Jeroen Massar wrote:

> On 2011-10-25 12:20 , Owen DeLong wrote:
>> 
>> On Oct 25, 2011, at 3:04 AM, Jeroen Massar wrote:
>> 
>>> On 2011-10-25 11:49 , Owen DeLong wrote:
>>> [..]
 With this combination, I have not encountered a hotel, airport lounge, or
 other poorly run environment from which I cannot send mail through my
 home server from my laptop/ipad/iphone/etc.
>>> 
>>> Ever heard of this magical thing called a VPN? :)
>> 
>> Sure, but, why deal with the overhead? Who wants to have to login to a
>> VPN every time just to quickly retrieve or send some email?
> 
> On that iToy of yours it is just a flick of a switch, presto.
> 
On anything, a VPN is a diversion of your traffic through a tunnel with 
additional
overhead for encryption and encapsulation headers.

>>> Indeed, that bypasses all those crappy local networks; and yes don't
>>> worry your iToy also has more than ample VPN abilities.
>>> 
>> 
>> Some do, some don't, and not all networks are any friendlier to VPNs
>> than they are to port 25.
> 
> And the final solution then tends to be setting up a VPN on port 443...
> Which only wastes one IP address, not several for different services.
> 
Meh, there are plenty of IP addresses. The shortage is limited to this legacy
v4 stuff. When the hotel networks and such catch up to the modern internet,
I can stop running these extra addresses on IPv4 and it won't matter.

>>> Set up once and never have to bother about special configurations or
>>> getting around stupid filters.
>>> 
>> 
>> Except where you have to or where there are so many layers of NAT that
>> even VPNs don't work, or...
> 
> Unless this 'NAT' is actually a firewall doing DPI on the packets, I
> can't see any reason why a VPN which just uses TCP over port 443 can't
> work in that situation.
> 

You would think, but, I have seen them break. OTOH, most of my VPNs
are IPSEC, not SSL, so that's another issue. There would be significant
additional overhead in setting up an SSL VPN. Admittedly, it's one-time
overhead, but, again, I don't see a reason to bother.

Owen

Re: Outgoing SMTP Servers

[Carlos Martinez-Cagnazzo]

I'm curious how a traveller is supposed to get SMTP relay service
when, well, travelling. I am not really sure if I want a VPN for
sending a simple email.

And I can understand (although I am not convinced that doing so is
such a great idea) blocking 25/tcp outgoing, as most botnets will try
that method of delivery. However, I do believe that outgoing 465
SHOULD always be allowed.

regards

Carlos

On Tue, Oct 25, 2011 at 10:43 AM, Bjørn Mork  wrote:
> Owen DeLong  writes:
>
>> It's both unacceptable in my opinion and common. There are even those
>> misguided souls that will tell you it is best practice, though general 
>> agreement,
>> even among them seems to be that only 25/tcp should be blocked and that
>> 465 and 587 should not be blocked.
>
> It is definitely considered best practice in some areas.  See e.g.
> http://translate.google.com/translate?hl=en&u=http://ikt-norge.no/wp-content/uploads/2010/10/bransjenorm-SPAM.pdf
> (couldn't find an english original, but the google translation looks OK)
>
> The document is signed by all major ISPs in Norway as well as the
> Norwegian research and education network operator, so it must be
> considered a local "best practice" whether you like it or not.
>
> Note that only port 25/tcp is blocked and that some of the ISPs offer a
> per-subscriber optout.
>
> Eh, this was the Northern Aurope NOG, wasn't it?
>
>
>
>
> Bjørn
>
>



-- 
--
=
Carlos M. Martinez-Cagnazzo
http://www.labs.lacnic.net
=

Re: Outgoing SMTP Servers

[Owen DeLong]

On Oct 25, 2011, at 3:29 AM,  wrote:

> On Tue, 25 Oct 2011 02:35:31 PDT, Owen DeLong said:
> 
>> If they are using someone else's mail server for outbound, how, exactly do 
>> you control
>> whether or not they use AUTH in the process?
> 
> 1) You don't even really *care* if they do or not, because...
> 
> 2) if some other site is running with an un-AUTHed open port 587, the 
> miscreants will
> find it and abuse it just like any other open mail relay. The community will
> deal with it quick enough so you don't have to. And at that point, it's the
> open mail relay's IP that ends up on the block lists, not your mail relay's 
> IP.
> 
But that applies to port 25 also, so, I'm not understanding the difference.

> Other people running open port 587s tends to be quite self-correcting.
> 

At this point, so do open port 25s.

Owen

Re: the route is not in our bgprouter

[Patrick Sumby]

If your provider has a looking glass then that is a good start to see if 
they have the route in their routing tables. http://www.traceroute.org/ 
is a good start for searching for a looking glass on their website.


Have you checked to see if you're actually recieving the route? You may 
be getting the route but not installing it into your routing table for 
some reason (eg invalid next hop or a router from another provider is 
being prefered). Do you have prefix lists inbound from your provider 
that could be blocking a route?


show ip route X.X.X.X
and
show ip bgp route X.X.X.X

will give different information.

If you've covered the above and not found the answer then try talking to 
your provider.


Regards
Patrick


On 25/10/2011 13:26, Deric Kwok wrote:

Hi

When we try to reach to outside ip, this route doesn't have in our bgp router

How can we check whether it doesn't advertise from our upstream to us?

Any web site and tools can help?

Thank you

ARIN and Legacy IPv4 Assignement from CA*Net (Canarie)

[Alain Hebert]

Hi,

From what we've been seeing there is a lot of those legacy 
assignement about to be freed. ( Yeah! )


We're having some issue with a few Legacy that where miss-assigned 
when transfered from CA*Net to ARIN back in the day.
( We kept the control on them since we had access to the POC's and 
OrgID, which is not the case anymore for some reason )


If anyone has a hint (off-list please) about how to go about fixing 
those broken assignement, we had no luck finding the process on ARIN.


I can only gather that there is no records left from the CA*Net 
merge :(


Thanks.

PS: Check your ARIN records if you have subnets in the 198., 199. 
and 205. just in case.



-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

Re: Outgoing SMTP Servers

[Bjørn Mork]

Owen DeLong  writes:

> It's both unacceptable in my opinion and common. There are even those
> misguided souls that will tell you it is best practice, though general 
> agreement,
> even among them seems to be that only 25/tcp should be blocked and that
> 465 and 587 should not be blocked.

It is definitely considered best practice in some areas.  See e.g.
http://translate.google.com/translate?hl=en&u=http://ikt-norge.no/wp-content/uploads/2010/10/bransjenorm-SPAM.pdf
(couldn't find an english original, but the google translation looks OK)

The document is signed by all major ISPs in Norway as well as the
Norwegian research and education network operator, so it must be
considered a local "best practice" whether you like it or not.

Note that only port 25/tcp is blocked and that some of the ISPs offer a
per-subscriber optout.

Eh, this was the Northern Aurope NOG, wasn't it?




Bjørn

the route is not in our bgprouter

[Deric Kwok]

Hi

When we try to reach to outside ip, this route doesn't have in our bgp router

How can we check whether it doesn't advertise from our upstream to us?

Any web site and tools can help?

Thank you

Re: Outgoing SMTP Servers

[Jeroen Massar]

On 2011-10-25 12:20 , Owen DeLong wrote:
> 
> On Oct 25, 2011, at 3:04 AM, Jeroen Massar wrote:
> 
>> On 2011-10-25 11:49 , Owen DeLong wrote:
>> [..]
>>> With this combination, I have not encountered a hotel, airport lounge, or
>>> other poorly run environment from which I cannot send mail through my
>>> home server from my laptop/ipad/iphone/etc.
>>
>> Ever heard of this magical thing called a VPN? :)
> 
> Sure, but, why deal with the overhead? Who wants to have to login to a
> VPN every time just to quickly retrieve or send some email?

On that iToy of yours it is just a flick of a switch, presto.

>> Indeed, that bypasses all those crappy local networks; and yes don't
>> worry your iToy also has more than ample VPN abilities.
>>
> 
> Some do, some don't, and not all networks are any friendlier to VPNs
> than they are to port 25.

And the final solution then tends to be setting up a VPN on port 443...
Which only wastes one IP address, not several for different services.

>> Set up once and never have to bother about special configurations or
>> getting around stupid filters.
>>
> 
> Except where you have to or where there are so many layers of NAT that
> even VPNs don't work, or...

Unless this 'NAT' is actually a firewall doing DPI on the packets, I
can't see any reason why a VPN which just uses TCP over port 443 can't
work in that situation.

Greets,
 Jeroen

Re: Outgoing SMTP Servers

[Valdis . Kletnieks]

On Tue, 25 Oct 2011 02:35:31 PDT, Owen DeLong said:

> If they are using someone else's mail server for outbound, how, exactly do 
> you control
> whether or not they use AUTH in the process?

1) You don't even really *care* if they do or not, because...

2) if some other site is running with an un-AUTHed open port 587, the 
miscreants will
find it and abuse it just like any other open mail relay. The community will
deal with it quick enough so you don't have to. And at that point, it's the
open mail relay's IP that ends up on the block lists, not your mail relay's IP.

Other people running open port 587s tends to be quite self-correcting.



pgpyXFMmAdPlt.pgp
Description: PGP signature

Re: Outgoing SMTP Servers

[Owen DeLong]

On Oct 25, 2011, at 3:04 AM, Jeroen Massar wrote:

> On 2011-10-25 11:49 , Owen DeLong wrote:
> [..]
>> With this combination, I have not encountered a hotel, airport lounge, or
>> other poorly run environment from which I cannot send mail through my
>> home server from my laptop/ipad/iphone/etc.
> 
> Ever heard of this magical thing called a VPN? :)

Sure, but, why deal with the overhead? Who wants to have to login to a
VPN every time just to quickly retrieve or send some email?

> 
> Indeed, that bypasses all those crappy local networks; and yes don't
> worry your iToy also has more than ample VPN abilities.
> 

Some do, some don't, and not all networks are any friendlier to VPNs
than they are to port 25.

> Set up once and never have to bother about special configurations or
> getting around stupid filters.
> 

Except where you have to or where there are so many layers of NAT that
even VPNs don't work, or...

I set up the 5 ports once and don't need any special configurations to
get around stupid filters, stuff just works now.

Owen

Re: Outgoing SMTP Servers

[Jeroen Massar]

On 2011-10-25 11:49 , Owen DeLong wrote:
[..]
> With this combination, I have not encountered a hotel, airport lounge, or
> other poorly run environment from which I cannot send mail through my
> home server from my laptop/ipad/iphone/etc.

Ever heard of this magical thing called a VPN? :)

Indeed, that bypasses all those crappy local networks; and yes don't
worry your iToy also has more than ample VPN abilities.

Set up once and never have to bother about special configurations or
getting around stupid filters.

Greets,
 Jeroen

Re: Outgoing SMTP Servers

[Owen DeLong]

On Oct 24, 2011, at 11:13 PM, William Herrin wrote:

> On Tue, Oct 25, 2011 at 12:29 AM, Dennis Burgess
>  wrote:
>> I am curious about what network operators are doing with outbound SMTP
>> traffic.  In the past few weeks we have ran into over 10 providers,
>> mostly local providers, which block outbound SMTP and require the users
>> to go THOUGH their mail servers even though those servers are not
>> responsible for the domains in question!  I know other mail servers are
>> blocking non-reversible mail, however, is this common?  And more
>> importantly, is this an acceptable practice?
> 
> Hi Dennis,
> 
> Blocking outbound TCP SYN packets on port 25 from non-servers is
> considered a BEST PRACTICE to avoid being the source of snowshoe and
> botnet spam. Blocking it from legitimate mail servers... does not make
> sense.
> 
> The SMTP submission port (TCP 587) is authenticated and should
> generally not be blocked.
> 

Interesting... Most people I know run the same policy on 25 and 587 these
days...

to-local-domain, no auth needed.
relay, auth needed.

auth required == TLS required.

Anything else on either port seems not best practice to me.

Due to the absurd things I've seen done in the world, I actually
run that policy on 5 ports:

25, 587 as you would expect.
465 SSL rather than STARTTLS, but, otherwise identical
80 because it works when nothing else does.
443 because sometimes Deep Packet Inspection is a PITA.

Of course, using 80 and 443 requires the use of additional IP address
resources for those servers rather than being able to also run a web
server on the same address, but, this is the consequence of replacing
an internet with 64K ports with filters that force the entire internet to
operate all services on TCP/80.

With this combination, I have not encountered a hotel, airport lounge, or
other poorly run environment from which I cannot send mail through my
home server from my laptop/ipad/iphone/etc.

Owen

Re: Outgoing SMTP Servers

[Aftab Siddiqui]

Blocking port/25 is a common practice (!= best practice) for home
users/consumers because it makes life a bit simpler in educating the end
user.

ripe-409 gives some what glimpse of best-practice, not sure how many
implements it that way.

Regards,

Aftab A. Siddiqui


On Tue, Oct 25, 2011 at 2:35 PM, Owen DeLong  wrote:

>
> On Oct 24, 2011, at 10:27 PM, Mikael Abrahamsson wrote:
>
> > On Mon, 24 Oct 2011, Dennis Burgess wrote:
> >
> >> I am curious about what network operators are doing with outbound SMTP
> >> traffic.
> >
> > Block all TCP/25 and require users to use submit with authentication on
> TCP/587.
> >
>
> If they are using someone else's mail server for outbound, how, exactly do
> you control
> whether or not they use AUTH in the process?
>
> Further, if you make them use AUTH somehow, but, you don't force TLS, then,
> you are
> doing more harm than good IMHO.
>
> Owen
>
>
>

Re: Outgoing SMTP Servers

[Owen DeLong]

On Oct 24, 2011, at 10:27 PM, Mikael Abrahamsson wrote:

> On Mon, 24 Oct 2011, Dennis Burgess wrote:
> 
>> I am curious about what network operators are doing with outbound SMTP
>> traffic.
> 
> Block all TCP/25 and require users to use submit with authentication on 
> TCP/587.
> 

If they are using someone else's mail server for outbound, how, exactly do you 
control
whether or not they use AUTH in the process?

Further, if you make them use AUTH somehow, but, you don't force TLS, then, you 
are
doing more harm than good IMHO.

Owen

Re: Outgoing SMTP Servers

[Dave CROCKER]

On 10/25/2011 8:13 AM, William Herrin wrote:

Blocking outbound TCP SYN packets on port 25 from non-servers is
considered a BEST PRACTICE

...

The SMTP submission port (TCP 587) is authenticated and should
generally not be blocked.



   Email Submission Operations: Access and Accountability Requirements

     IETF BCP

It does not explicitly support blocking outbound port 25, since that's 
controversial, but it /does/ require permitting outbound port 587.


d/



Regards,
Bill Herrin




--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

RE: Outgoing SMTP Servers

[Tim]

This sadly is very common. It is getting more common by the day it seems but
this practice has started almost a decade ago.

An easy work around is to use a custom port as they seem to just block port
25 as a bad port but leave just about everything else open including 2525
which seems to be a common secondary smtp port for hosting companies.