Re: Blocking MX query

[Suresh Ramasubramanian]

On Wed, Sep 5, 2012 at 9:10 AM, Masataka Ohta
 wrote:
> While ISPs in the future should use not IPv6 but NAT with fixed
> IP addresses and sets of port numbers assigned to their customers,
> keeping the end to end transparency, it does not solve the
> problem of blocked port 25.
>
> Note that IPv6 do not solve the problem of blocked port 25, either.

So - now with ipv6 you're going to see "hi, my toto highly
computerized toilet is trying to make outbound port 25 connections to
gmail"

http://www.telecoms.com/48734/vodafone-and-ibm-team-up-on-connected-home-appliances/

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

Re: Blocking MX query

[Masataka Ohta]

valdis.kletni...@vt.edu wrote:

>>> Have your desktop MTA configured to relay through your smarthost with smtp
>>> auth?  Howtos for doing this on sendmail, qmail, postfix etc are over a
>>> decade old now.
>>
>> What if, your home is also behind NAT or blocked port 25?
> 
> Weren't you the one who a few weeks ago was advocating more NAT rather than
> deploying IPv6?

NAT, here, means dumb NAT. With most, if not all, pseudo ISPs using
NAT, you can't expect port forwarding services.

While ISPs in the future should use not IPv6 but NAT with fixed
IP addresses and sets of port numbers assigned to their customers,
keeping the end to end transparency, it does not solve the
problem of blocked port 25.

Note that IPv6 do not solve the problem of blocked port 25, either.

Masataka Ohta

Re: Blocking MX query

[Mark Andrews]

In message 
, Jimmy 
Hess writes:
> On 9/4/12, Mark Andrews  wrote:
> > In message
> > , Suresh
> > Ramasubramanian writes:
> > STARTTLS from anywhere to anywhere is possible today and is not
> > vulnerable to interception except in the MX's themselves.  You can
> > secure the MX records (and their absense) and secure the CERTs used
> > by STARTTLS.
> 
> You can also use SMTPS on port 465;  or STARTTLS on port 587.  Most MX
> servers  don't support TLS or SSL, so it could be privacy neutral, and
> many MX server operators utilize dynamic host RBLs, even if STARTTLS
> connections are allowed.   It is possible for end user to tunnel SMTP
> traffic over VPN, SSL, or SSH  to a private submit server on a trusted
> network.

You missed the point.  It *is* a privacy problem if my ISP can see
the "MAIL TO: ".  It is *unreasonable* to expect
everyone to run their own submission server to avoid this privacy
problem.

Most MX's don't *currently* support STARTTLS because until recently
it was difficult to prevent various MiM interception attacks and
you had to pay for CERTs.  Both of these reasons are in the process
of going away.  You can prevent MiM on MX records by using DNSSEC.
You can generate and publish your own CERT records using DANE.

> Blocking initial outgoing TCP SYN for port 25 completely creates a
> predictable failure scenario. which is to be encouraged.

Only if you don't care for user privacy.  There is way to much data
collection already.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Blocking MX query

[Jimmy Hess]

On 9/4/12, Mark Andrews  wrote:
> In message
> , Suresh
> Ramasubramanian writes:
> STARTTLS from anywhere to anywhere is possible today and is not
> vulnerable to interception except in the MX's themselves.  You can
> secure the MX records (and their absense) and secure the CERTs used
> by STARTTLS.

You can also use SMTPS on port 465;  or STARTTLS on port 587.  Most MX
servers  don't support TLS or SSL, so it could be privacy neutral, and
many MX server operators utilize dynamic host RBLs, even if STARTTLS
connections are allowed.   It is possible for end user to tunnel SMTP
traffic over VPN, SSL, or SSH  to a private submit server on a trusted
network.

Blocking initial outgoing TCP SYN for port 25  completely creates a
predictable failure scenario. which is to be encouraged.

ISPs very commonly block outgoing initial SYNs to that port. And
ISPs also commonly block23, 135 - 139, 190, 389, 445, 1025, 1080,
1433 - 1434, 3380, 3389, 5060, 5070, 5631, 6667, 31337, 559.

Some may block connections to all outgoing ports, except a small
number.   Those are all accepted practices,  with increasing
annoyance, and increasing predictable breakage, the more ports are
messed with.

Blocking few/no ports is desirable; and port 25 is so widely blocked,
that MUAs should be set to 587 +  authenticated submit in the first
place.




Tampering with the contents of packets,  "blocking"  application level
traffic by creating fake application layer error messages, for example
fake nxdomain/servfail response, or fake "550 rejected"  SMTP
response,   is to be strongly discouraged,  because it causes
unpredictable application failures.

ISP routers aren't supposed to reject/accept packets based on
application layer data.

The exception would be you manage the end user computers, and dictate
a very precise list of applications, so you can pick ones  whose
vendors list it as a supported thing, or you have gone through
rigorous testing procedures.   (Enterprise IDS units,  that analyze
packets and seek to block attacks by reacting to application content,
are OK, for example)


>> Of course a bot can build up a rich cache of MX records from elsewhere
>> and send from a botted 3g modem connected host on his network

Yes.   It can also "probe" randomly for servers listening on port 25
based on A record lookup instead of MX,  or by  using  Reverse DNS to
find a domain, and then guess e-mail addresses.

> --
> Mark Andrews, ISC
--
-JH

Re: Blocking MX query

[Ibrahim]

All, thanks for the input and comment. In summary, I will block TCP port
25. My DNS loadbalancer (F5) can filter MX query and need license to do it.
But given the information the botnet use  address list with
pre-resolved IP addresses then blocking MX query is not the answer :-)


Thanks & Regards
Ibrahim

On Wed, Sep 5, 2012 at 9:18 AM, George Herbert wrote:

>
>
>
> On Sep 4, 2012, at 12:07 PM, William Herrin  wrote:
>
> > You are. You should be doing SMTP Auth to *your* email server on which
> > you have an authorized account and then letting it relay your messages
> > to the world.
>
>
> This is not the thread for this conversation per se.  The practicality of
> general ISP 25 blocking is established for antispam purposes.  So are power
> users running home domains.  Different user profiles.  Different
> circumstances.
>
>
> George William Herbert
> Sent from my iPhone
>

Re: Blocking MX query

[George Herbert]

On Sep 4, 2012, at 12:07 PM, William Herrin  wrote:

> You are. You should be doing SMTP Auth to *your* email server on which
> you have an authorized account and then letting it relay your messages
> to the world.


This is not the thread for this conversation per se.  The practicality of 
general ISP 25 blocking is established for antispam purposes.  So are power 
users running home domains.  Different user profiles.  Different circumstances.


George William Herbert
Sent from my iPhone

Re: Blocking MX query

[Suresh Ramasubramanian]

This is a bit of a slippery slope.  There is broad agreement that SPs
need to block port 25 outbound (and inbound) on dynamic IP space.

And he did say he's in a country where he's obliged by law to filter
out porn (and I guess anything else his country's government doesn't
like).

Where do blocking MX record lookups fit in between the porn blocking
and the port 25 filtering?  Rather closer to port 25 filtering I'd
say, but your call.

This is not a user privacy issue at all.  Static IP broadband is
entirely available if you should decide you want to run a mailserver
at your home.  And for people using outlook (or postfix) on their
desktop to relay through a smarthost, MX lookups don't matter one way
or the other.

--srs

On Wed, Sep 5, 2012 at 7:30 AM, Mark Andrews  wrote:
>
> Well he was looking for software to block the queries.  There is a
> whole mentality that homes don't need X which on closer examination
> just doesn't bear up to scrutany.  This includes blocking SMTP or
> don't you think home users are entitled to have privacy when it
> comes to whom they email?
>
> STARTTLS from anywhere to anywhere is possible today and is not
> vulnerable to interception except in the MX's themselves.  You can
> secure the MX records (and their absense) and secure the CERTs used
> by STARTTLS.



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

Re: Blocking MX query

[Mark Andrews]

In message 
, Suresh 
Ramasubramanian writes:
> On Wed, Sep 5, 2012 at 6:38 AM, Mark Andrews  wrote:
> >
> > MUA's can make MX queries to validate entered addresses
> > before SMTP/SUBMISSION is even attempted.
> >
> 
> Sure but not on this guy's network as he's transparently proxying dns
> and blocking MX requests on his proxy

Well he was looking for software to block the queries.  There is a
whole mentality that homes don't need X which on closer examination
just doesn't bear up to scrutany.  This includes blocking SMTP or
don't you think home users are entitled to have privacy when it
comes to whom they email?

STARTTLS from anywhere to anywhere is possible today and is not
vulnerable to interception except in the MX's themselves.  You can
secure the MX records (and their absense) and secure the CERTs used
by STARTTLS.

> Of course a bot can build up a rich cache of MX records from elsewhere
> and send from a botted 3g modem connected host on his network
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Blocking MX query

[Suresh Ramasubramanian]

On Wed, Sep 5, 2012 at 6:38 AM, Mark Andrews  wrote:
>
> MUA's can make MX queries to validate entered addresses
> before SMTP/SUBMISSION is even attempted.
>

Sure but not on this guy's network as he's transparently proxying dns
and blocking MX requests on his proxy

Of course a bot can build up a rich cache of MX records from elsewhere
and send from a botted 3g modem connected host on his network

Re: Blocking MX query

[valdis . kletnieks]

On Wed, 05 Sep 2012 09:29:49 +0900, Masataka Ohta said:
> Suresh Ramasubramanian wrote:
>
> > Have your desktop MTA configured to relay through your smarthost with smtp
> > auth?  Howtos for doing this on sendmail, qmail, postfix etc are over a
> > decade old now.
>
> What if, your home is also behind NAT or blocked port 25?

Weren't you the one who a few weeks ago was advocating more NAT rather than
deploying IPv6?


pgpMEkzRJ5Flv.pgp
Description: PGP signature

Re: Blocking MX query

[Mark Andrews]

MUA's can make MX queries to validate entered addresses
before SMTP/SUBMISSION is even attempted.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Blocking MX query

[Jimmy Hess]

On 9/4/12, Rich Kulawiec  wrote:
> You're precisely correct.  They've been doing this for many years,
> (a) because it's efficient (b) because it evades detection by techniques
> that monitor MX query volume (c) because few MX's change often (d) because
> it scales beautifully across large botnets.

One can begin to envision a spam avoidance scheme; where a mail server
is assigned a random IP  within an IPv6 prefix based on a EUI64/UUID.
Two static MX records are published;  each MX referencing short-lived
 records with a TTL of 60 seconds or less.

One of those  records points to  the current IP address of the
mail server, and one of those  records point to the "next one".
A mail server binds to each address both "previous" and "next" and
accepts port 25 connections for mail delivery.

Every 60 seconds,  the "current address" AAA  record is  changed to
the IP listed in the "next address" AAA record;   a  new EUI64 is
generated, and the  "next address"  record is populated with the
new randomly generated IPV6 address.

A mail server for the domain binds the new IP address and starts
listening;  and starts tarpitting any new port 25 connections from the
previous address in 90 seconds.

After 600 seconds, or when the IP is no longer in the most recent 5,
an6 existing SMTP connections to the old server IP (from unacceptably
slow senders/deliveries) are terminated, and the server removes the
old IP from its interface.

--
-JH

Re: Blocking MX query

[Suresh Ramasubramanian]

Who cares about NAT when you say smtp auth rather than allowing relay for
specific IPs?  And if you mean your smarthost is a linux box in your home,
it isn't impossible to get static IP broadband .. which is neither natted
nor port 25 filtered.
 On Sep 5, 2012 6:01 AM, "Masataka Ohta" 
wrote:

> Suresh Ramasubramanian wrote:
>
> > Have your desktop MTA configured to relay through your smarthost with
> smtp
> > auth?  Howtos for doing this on sendmail, qmail, postfix etc are over a
> > decade old now.
>
> What if, your home is also behind NAT or blocked port 25?
>
> Masataka Ohta
>
>
>

Re: Blocking MX query

[Masataka Ohta]

Suresh Ramasubramanian wrote:

> Have your desktop MTA configured to relay through your smarthost with smtp
> auth?  Howtos for doing this on sendmail, qmail, postfix etc are over a
> decade old now.

What if, your home is also behind NAT or blocked port 25?

Masataka Ohta

Research Project: Identifying DNSSEC Validators

[Wessels, Duane]

Within Verisign Labs we have a project underway to quantify the number of
DNSSEC-validating resolvers in use on the Internet.  In particular, we
want to identify recursive name servers which have configured the root
zone trust anchor.  We find this data a useful metric for DNSSEC adoption
and especially helpful for informing discussions about key rollovers for
the root zone.

In order for our our measurements to be meaningful, we need to receive
queries from a wide variety of recursive name servers.  To achieve this
goal we ask members of the DNS and networking communities to assist by
adding the following single line of HTML code to your web pages:

http://prefetch.validatorsearch.verisignlabs.com";>

This HTML snippet should have no visible impact on a rendered page.  Since
nearly all web browsers now implement DNS prefetching, the code above
results in a DNS query for the name shown and allows us to characterize
the recursive name server that the query goes through.

Please note that we are not interested in identifying individual users who
have loaded the web page.  The name above points to the localhost IP address
(127.0.0.1) so even if someone does manage to "click" on it, that request
does not reach us.

For some preliminary results, please visit the project web page at
http://validatorsearch.verisignlabs.com/

We look forward to presenting the full results at a future NANOG meeting.

Duane W.

Re: The End-To-End Internet (was Re: Blocking MX query)

[Michael Thomas]

On 09/04/2012 09:34 AM, Daniel Taylor wrote:

If you are sending direct SMTP on behalf of your domain from essentially random 
locations, how are we supposed to pick you out from spammers that do the same?



Use DKIM.

Mike

Re: The End-To-End Internet (was Re: Blocking MX query)

[Daniel Taylor]

If you are sending direct SMTP on behalf of your domain from essentially 
random locations, how are we supposed to pick you out from spammers that 
do the same?


Use your MX or SPF senders as your outbound mail agent, especially if 
they are properly configured with full DNS records so we can tell they 
are the correct machines to be sending on your behalf, or expect that 
you will get more mail bounced and lost  than the average user because 
you are being unpredictable and unverifiable.


On 09/04/2012 11:05 AM, Jay Ashworth wrote:

- Original Message -

From: "John Peach" 
On Tue, 4 Sep 2012 11:57:38 -0400 (EDT)
Jay Ashworth  wrote:

SMTP Auth to *arbitrary remote domains' MX servers*? Am I missing
something,
or are you?

I run an MTA on my server and auth to that from laptops and other
clients. Relaying allowed for authorised users.

So, in other words, it's ok to rant and stomp our feet about the end-to-end
architecture and how critical it is to support in order to diss NAT, but
we're required to ignore it when discussing SMTP?

I'm not sure I'm following, there.

Cheers,
-- jra


--
Daniel Taylor VP Operations   Vocal Laboratories, Inc
dtay...@vocalabs.com 952-941-6580x203

RE: 91.201.64.0/22 hijacked?

[Schiller, Heather A]

It does not sound as though the original holders of the space know/care - if 
they are out of business, they probably don't care.  If they are actively 
involved in it, then it's not a hijack.  If they haven't updated their company 
name/website, then it's not a hijack, just poor record keeping.   

If you suspect the address space is abandoned, or hijacked, report it to RIPE.  
It may not get deallocated and reassinged until a few months after the bill 
stops getting paid.  

 --Heather

-Original Message-
From: Jeroen van Aart [mailto:jer...@mompl.net] 
Sent: Friday, August 31, 2012 2:39 PM
To: NANOG list
Subject: 91.201.64.0/22 hijacked?

The below email exchange may be of interest to some of you. The practical 
upshot is that it appears "the 91.201.64.0/22 range was hijacked and should be 
included into the DROP list".

As an interesting aside, quoting a friend:

"the original company (that performed dangerous waste utilization) may have 
been a shady thing in and of itself (..) what most companies calling themselves 
"ecoservice" (with variations) do is take money for "safe utilisation" of 
hazardous waste, and then dump it in some old quarry out in the remote (or not 
so remote) corner of a forest or other natural area (..) they always have 
criminal links and protection from corrupts officials (often co-owners) and 
security/law enforcement services"


> From: Jeroen van Aart

> there is
> nothing but crap coming from 91.201.64.0/24. Amongst other things 
> attempts to spam (through) wordpress sites.

> inetnum: 91.201.64.0 - 91.201.67.255
> netname: Donekoserv
> descr:   DonEkoService Ltd

Don - name of the nearby large river.
"EkoService" means ecological service.

> country: RU
> org: ORG-DS41-RIPE
> 
> person: Haralevich Piotr
> address:novocherkassk, ul stremyannaya d.6
> mnt-by: MNT-DONECO
> phone:  +7495100

nic-hdl: HP2220-RIPE
changed: ad...@donecoserv.ru 20101117

The company performed dangerous waste utilization:
http://donekoservis.alloy.ru/contacts/
http://www.idbo.ru/view/72321/
But domains donecoserv.ru and donekoservis.ru don't exist anymore.

traceroute 91.201.64.14
...
11 router02.spbbm18.ru.edpnet.net (212.71.11.26) 65.979 ms 65.971 ms
66.182 ms
12 77.109.110.62.static.edpnet.net (77.109.110.62) 88.868 ms 47.809 ms 47.715ms
13 195.2.240.234 (195.2.240.234)  48.235 ms  48.546 ms  48.664 ms
14 ajursrv.parohod.biz (95.215.0.206)  47.957 ms  47.752 ms  47.606 ms
15 mail.rx-helps.com (91.201.64.14)  48.206 ms  48.302 ms  48.237 ms

SPb (Sankt-Peterburg) is 1500 km from Novocherkassk.
parohod.biz also is in Sankt-Peterburg, they offer SEO (which I consider fraud, 
spamming websites and search engines).

Also, see
http://support.clean-mx.de/clean-mx/viruses.php?email=ad...@donecoserv.ru&response=
http://www.spambotsecurity.com/forum/viewtopic.php?f=7&t=795

http://unapprovedpharmacy.wordpress.com/2011/01/03/whois-www-canadianmedsshop-com/
| January 3, 2011
...
| inetnum: 91.201.64.0  91.201.67.255
| netname: Donekoserv
| descr: DonEkoService Ltd
| country: RU
| org: ORG-DS41-RIPE
...
| organisation: ORG-DS41-RIPE
| org-name: DonEko Service
| org-type: OTHER
| address: novocherkassk, ul stremyannaya d.6
| e-mail: ad...@bulletproof-web.com

Note "bulletproof".

Therefore, the 91.201.64.0/22 range was hijacked and should be included into 
the DROP list.

Re: The End-To-End Internet (was Re: Blocking MX query)

[Michael Thomas]

On 09/04/2012 01:07 PM, David Miller wrote:



There is no requirement that all endpoints be *permitted* to connect to
and use any service of any other endpoint.  The end-to-end design
principle does not require a complete lack of authentication or
authorization.

I can refuse connections to port 25 on my endpoint (mail server) from
hosts that do not conform to my requirements (e.g. those that do not
have forward-confirmed reverse DNS) without violating the end-to-end
design principle in any way.




The thing that has never set well with me with ISP blanket port 25
blocking is that the fate sharing is not correct. If I have a mail server
and I refuse to take incoming connects from dynamic "home" IP
blocks, the fate sharing is correct: I'm only hurting myself if there's
collateral damage. When ISP's have blanket port 25, the two parties
of the intended conversation never get a say: things just break
mysteriously as far as both parties are concerned, but the ISP isn't
hurt at all. So they have no incentive to drop their false positive
rate. That's not good.

Mike

Re: The End-To-End Internet (was Re: Blocking MX query)

[Jay Ashworth]

- Original Message -
> From: "William Herrin" 

> That's what firewalls *are for* Jay. They intentionally break
> end-to-end for communications classified by the network owner as
> undesirable. Whether a particular firewall employs NAT or not is
> largely beside the point here. Either way, the firewall is *supposed*
> to break some of the end to end communication paths.

Correct, Bill.

Hopefully, everyone else here who thinks DNAT is the anti-Christ heard the
"largely beside the point" part of your assertion, with which I agree.

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   #natog  +1 727 647 1274

Re: The End-To-End Internet (was Re: Blocking MX query)

[David Miller]

On 9/4/2012 2:22 PM, Jay Ashworth wrote:
> - Original Message -
>> From: "Owen DeLong" 
> 
>> I am confused... I don't understand your comment.
> 
> It is regularly alleged, on this mailing list, that NAT is bad *because it 
> violates the end-to-end principle of the Internet*, where each host is a
> full-fledged host, able to connect to any other host to perform transactions.
> 
> We see it now alleged that the opposite is true: that a laptop, say, like
> mine, which runs Linux and postfix, and does not require a smarthost to
> deliver mail to a remote server *is a bad actor* *precisely because it does
> that* (in attempting to send mail directly to a domain's MX server) *from 
> behind a NAT router*, and possibly different ones at different times.
> 
> I find these conflicting reports very conflicting.  Either the end-to-end
> principle *is* the Prime Directive... or it is *not*.
> 

The end-to-end design principle pushes application functions to
endpoints instead of placing these functions in the network itself.
This principle requires that endpoints be *capable* of creating
connections to each other.  Network system design must support these
connections being initiated by either side - which is where NAT
implementations usually fail.

There is no requirement that all endpoints be *permitted* to connect to
and use any service of any other endpoint.  The end-to-end design
principle does not require a complete lack of authentication or
authorization.

I can refuse connections to port 25 on my endpoint (mail server) from
hosts that do not conform to my requirements (e.g. those that do not
have forward-confirmed reverse DNS) without violating the end-to-end
design principle in any way.

Thus it is a false chain of conclusions to say that:
- end-to-end is violated by restricting connections to/from certain hosts
[therefore]
- the end-to-end design principle is not important
[therefore]
- NAT is good

...which I believe is the argument that was being made? ...

Ref - http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf


> Cheers,
> -- jra
> 

Re: The End-To-End Internet (was Re: Blocking MX query)

[William Herrin]

On Tue, Sep 4, 2012 at 2:22 PM, Jay Ashworth  wrote:
> It is regularly alleged, on this mailing list, that NAT is bad *because it
> violates the end-to-end principle of the Internet*, where each host is a
> full-fledged host, able to connect to any other host to perform transactions.

That's what firewalls *are for* Jay. They intentionally break
end-to-end for communications classified by the network owner as
undesirable. Whether a particular firewall employs NAT or not is
largely beside the point here. Either way, the firewall is *supposed*
to break some of the end to end communication paths.

Regards,
Bill Herrin


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

Re: Blocking MX query

[Jay Ashworth]

- Original Message -
> From: "William Herrin" 

> > SMTP Auth to *arbitrary remote domains' MX servers*? Am I missing
> > something, or are you?
> 
> You are. You should be doing SMTP Auth to *your* email server on which
> you have an authorized account and then letting it relay your messages
> to the world.

Ah; so then the End-To-End Principle is *not* The Prime Directive.

Good; thanks.  Can we stop flogging people with it who like DNAT, then?

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   #natog  +1 727 647 1274

Re: The End-To-End Internet (was Re: Blocking MX query)

[Sean Harlow]

On Sep 4, 2012, at 14:22, Jay Ashworth wrote:

> I find these conflicting reports very conflicting.  Either the end-to-end
> principle *is* the Prime Directive... or it is *not*.

Just because something is of extremely high importance does not mean it still 
can't be overridden when there's good enough reason.

In this case, in the majority of "random computer on the internet" IP blocks 
the ratio of spambots to legitimate mail senders is so far off balance that a 
whitelisting approach to allowing outbound port 25 traffic is not unreasonable. 
 Unlike the bad kinds of NAT, this doesn't also indiscriminately block 
thousands of other uses, it exclusively affects email traffic in a way which is 
trivial for the legitimate user to work around while stopping the random 
infected hosts in their tracks.

Many providers also block traffic on ports like 137 (NetBIOS) on "consumer" 
space for similar reasons, the malicious or unwanted uses vastly outweigh the 
legitimate ones.

The reason bad NATs get dumped on is because there are better solutions both 
known and available on the market.  If you have an idea for a way to allow your 
laptop to send messages directly while still stopping or minimizing the ability 
of the thousands of zombies sharing an ISP with you from doing the same the 
world would love to hear it.
---
Sean Harlow
s...@seanharlow.info

Re: Blocking MX query

[Michael Thomas]

On 09/04/2012 11:55 AM, William Herrin wrote:

On Tue, Sep 4, 2012 at 12:59 PM, Michael Thomas  wrote:

On 09/04/2012 05:05 AM, William Herrin wrote:

There are no "good" subscribers trying to send email direct to a
remote port 25 from behind a NAT. The "good" subscribers are either
using your local smart host or they're using TCP port 587 on their
remote mail server. You may safely block outbound TCP with a
destination of port 25 from behind your NAT without harming reasonable
use of your network.

Would that were true going forward. Consider a world where your
home is chock full of purpose built devices, most likely with an
embedded web browser for configuration where you have a
username/password for each. In the web world this works because
there is a hidden assumption that you can use email for user/password
reset/recovery and that it works well.

Hi Mike,

A. What device do you offer as an example of this? I haven't stumbled
across one yet. Web sites yes. Physical home devices, no.

What I *have* seen is devices that call out to a web server, you make
an account on the remote web server to configure them and then all the
normal rules about accounts on remote web servers apply.


I want to buy hardware from people, not their ill-conceived "cloud"
service that dies when there's no more business case for it and is probably
evil anyway.



B. Bad hidden assumption. Expect it to fail as more than a few cable
and DSL providers are blocking random port 25 outbound. Besides, some
folks change email accounts like they change underwear. Relying on
that email address still working a year from now is not smart.



I'm well aware of port 25 blocking. I'm saying your assumption
that there is *never* any reason for a home originating port 25
traffic is a bad one. It's never been a good one, but the collateral
damage was pretty low when NAT's are in the way. v6 will change
that, and the collateral damage will rise. Unless you can come up
with another ubiquitous out of band method for account recovery,
expect the tension -- and help desk calls -- to increase.

Mike

Re: Blocking MX query

[William Herrin]

On Tue, Sep 4, 2012 at 11:57 AM, Jay Ashworth  wrote:
>> What sort of an mta do you run on your laptop that doesnt support smtp
>> auth?
>
> SMTP Auth to *arbitrary remote domains' MX servers*?  Am I missing something,
> or are you?

You are. You should be doing SMTP Auth to *your* email server on which
you have an authorized account and then letting it relay your messages
to the world.


>> Okay, fair enough. There are no good users *expecting* to send email
>> direct to a remote port 25 from behind a NAT. There are some good
>> users who occasionally run slightly sloppy configurations which might
>> attempt spurious port 25 connections.
>
> I do, in fact, expect that.  You're alleging that's a bad practice.

Yes, I am. Here's a few others.


http://security.comcast.net/get-help/spam.aspx

"Port 25 Blocking

Port 25 is conduit on a computer that spammers can take control of
and use to send their spam - often without the user ever knowing
his/her computer has been "hijacked". Comcast works with our customers
to block access to Port 25 and protect their PC.
Comcast recommends that our customers establish a more secure
email configuration on their PC - Port 587 - We have made it easy by
creating a one-click fix that automatically configures your computers
to this safer PC configuration."


http://qwest.centurylink.com/internethelp/email-troubleshooting-port25.html

"CenturyLink filters port 25 to reduce the spread of email viruses and
spam (unsolicited email). Filtering port 25 has become the industry
standard to reduce the spread of email viruses and spam. These email
viruses allow malicious software to control infected computers. These
viruses direct the infected machines to send email viruses and spam
through port 25. "


http://cbl.abuseat.org/nat.html

"The simplest and most effective way to stop this is to configure your
NAT to prohibit connections to the Internet on port 25 except from
real mail servers. Not only does this stop all of these viruses and
spams dead in their tracks, the NAT logs will immediately tell you the
LAN address of the infected machine. "


http://tools.ietf.org/html/rfc5068

"A proactive technique used by some providers is to block all use of
   port 25 SMTP for mail that is being sent outbound, or to
   automatically redirect this traffic through a local SMTP proxy,
   except for hosts that are explicitly authorized."


http://www.microsoft.com/security/sir/strategy/default.aspx#!section_2_4

"Block access to port 25 from all hosts on your network other than
those you explicitly authorize to perform SMTP relay functions."



Regards,
Bill Herrin

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

Re: Blocking MX query

[William Herrin]

On Tue, Sep 4, 2012 at 12:59 PM, Michael Thomas  wrote:
> On 09/04/2012 05:05 AM, William Herrin wrote:
>> There are no "good" subscribers trying to send email direct to a
>> remote port 25 from behind a NAT. The "good" subscribers are either
>> using your local smart host or they're using TCP port 587 on their
>> remote mail server. You may safely block outbound TCP with a
>> destination of port 25 from behind your NAT without harming reasonable
>> use of your network.
>
> Would that were true going forward. Consider a world where your
> home is chock full of purpose built devices, most likely with an
> embedded web browser for configuration where you have a
> username/password for each. In the web world this works because
> there is a hidden assumption that you can use email for user/password
> reset/recovery and that it works well.

Hi Mike,

A. What device do you offer as an example of this? I haven't stumbled
across one yet. Web sites yes. Physical home devices, no.

What I *have* seen is devices that call out to a web server, you make
an account on the remote web server to configure them and then all the
normal rules about accounts on remote web servers apply.

B. Bad hidden assumption. Expect it to fail as more than a few cable
and DSL providers are blocking random port 25 outbound. Besides, some
folks change email accounts like they change underwear. Relying on
that email address still working a year from now is not smart.

Regards,
Bill Herrin



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

Re: The End-To-End Internet (was Re: Blocking MX query)

[Jay Ashworth]

- Original Message -
> From: "Owen DeLong" 

> I am confused... I don't understand your comment.

It is regularly alleged, on this mailing list, that NAT is bad *because it 
violates the end-to-end principle of the Internet*, where each host is a
full-fledged host, able to connect to any other host to perform transactions.

We see it now alleged that the opposite is true: that a laptop, say, like
mine, which runs Linux and postfix, and does not require a smarthost to
deliver mail to a remote server *is a bad actor* *precisely because it does
that* (in attempting to send mail directly to a domain's MX server) *from 
behind a NAT router*, and possibly different ones at different times.

I find these conflicting reports very conflicting.  Either the end-to-end
principle *is* the Prime Directive... or it is *not*.

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   #natog  +1 727 647 1274

Re: Blocking MX query

[Jay Ashworth]

- Original Message -
> From: "William Herrin" 

> > I'm a bad subscriber, Bill?
> 
> Okay, fair enough. There are no good users *expecting* to send email
> direct to a remote port 25 from behind a NAT. There are some good
> users who occasionally run slightly sloppy configurations which might
> attempt spurious port 25 connections.

I do, in fact, expect that.  You're alleging that's a bad practice.

> Good to block port 25. Not good to knee-jerk ban users whose machines
> happen to poke the port once or twice.

I wasn't even talking about banning or blocking me.  I was, as you'll see
in my other response, exercising the end-to-end architecture of the 
Internet, as members of this list regularly exhort that I should be able
to.

"This is why we can't have nice things" is not, actually, a sufficiently
useful excuse for me to not agree with that principle.

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   #natog  +1 727 647 1274

Re: Blocking MX query

[William Herrin]

On Tue, Sep 4, 2012 at 10:44 AM, Jay Ashworth  wrote:
>> There are no "good" subscribers trying to send email direct to a
>> remote port 25 from behind a NAT.
>
> Users, like myself, running Linux on home computers and laptops; our local
> sendmail-equivalents will in fact attempt direct delivery to remote SMTP MX
> servers, and we generally move around enough that setting a smarthost is
> semi-impractical, at least on laptops.
>
> I'm a bad subscriber, Bill?

Okay, fair enough. There are no good users *expecting* to send email
direct to a remote port 25 from behind a NAT. There are some good
users who occasionally run slightly sloppy configurations which might
attempt spurious port 25 connections.

Good to block port 25. Not good to knee-jerk ban users whose machines
happen to poke the port once or twice.

Regards,
Bill Herrin


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

Re: Blocking MX query

[Michael Thomas]

On 09/04/2012 05:05 AM, William Herrin wrote:

There are no "good" subscribers trying to send email direct to a
remote port 25 from behind a NAT. The "good" subscribers are either
using your local smart host or they're using TCP port 587 on their
remote mail server. You may safely block outbound TCP with a
destination of port 25 from behind your NAT without harming reasonable
use of your network.



Would that were true going forward. Consider a world where your
home is chock full of purpose built devices, most likely with an
embedded web browser for configuration where you have a
username/password for each. In the web world this works because
there is a hidden assumption that you can use email for user/password
reset/recovery and that it works well. When your boxen can't do that
because email is blocked, what are you going to do? Reset to factory
defaults? Every time I forget? And please lets not get another useless
lecture on why the unwashed masses should be using password vaults.
They won't.

This hidden assumption of a reliable out of band mechanism for account
recovery is going to come to the fore as v6 rolls out and ip is as gratuitously
added to cheap devices as digital controls are now. Email is the glue that
keeps the web world functioning. Until there's something else, it will
continue to be needed and its role will expand in the home too.

Mike

Re: The End-To-End Internet (was Re: Blocking MX query)

[Seth Mattinen]

On 9/4/12 9:05 AM, Jay Ashworth wrote:
> - Original Message -
>> From: "John Peach" 
> 
>> On Tue, 4 Sep 2012 11:57:38 -0400 (EDT)
>> Jay Ashworth  wrote:
>>> SMTP Auth to *arbitrary remote domains' MX servers*? Am I missing
>>> something,
>>> or are you?
>>
>> I run an MTA on my server and auth to that from laptops and other
>> clients. Relaying allowed for authorised users.
> 
> So, in other words, it's ok to rant and stomp our feet about the end-to-end
> architecture and how critical it is to support in order to diss NAT, but 
> we're required to ignore it when discussing SMTP?
> 
> I'm not sure I'm following, there.
> 


Feelings on spam = "this is why we can't have nice things"

~Seth

Re: Blocking MX query

[Suresh Ramasubramanian]

Have your desktop MTA configured to relay through your smarthost with smtp
auth?  Howtos for doing this on sendmail, qmail, postfix etc are over a
decade old now.
 On Sep 4, 2012 9:28 PM, "Jay Ashworth"  wrote:

> - Original Message -
> > From: "Suresh Ramasubramanian" 
>
> > What sort of an mta do you run on your laptop that doesnt support smtp
> > auth?
>
> SMTP Auth to *arbitrary remote domains' MX servers*?  Am I missing
> something,
> or are you?
>
> 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   #natog  +1 727 647
> 1274
>
>

The End-To-End Internet (was Re: Blocking MX query)

[Jay Ashworth]

- Original Message -
> From: "John Peach" 

> On Tue, 4 Sep 2012 11:57:38 -0400 (EDT)
> Jay Ashworth  wrote:
> > SMTP Auth to *arbitrary remote domains' MX servers*? Am I missing
> > something,
> > or are you?
> 
> I run an MTA on my server and auth to that from laptops and other
> clients. Relaying allowed for authorised users.

So, in other words, it's ok to rant and stomp our feet about the end-to-end
architecture and how critical it is to support in order to diss NAT, but 
we're required to ignore it when discussing SMTP?

I'm not sure I'm following, there.

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   #natog  +1 727 647 1274

Re: Blocking MX query

[Jay Ashworth]

- Original Message -
> From: "Suresh Ramasubramanian" 

> What sort of an mta do you run on your laptop that doesnt support smtp
> auth?

SMTP Auth to *arbitrary remote domains' MX servers*?  Am I missing something,
or are you?

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   #natog  +1 727 647 1274

Re: Blocking MX query

[Suresh Ramasubramanian]

What sort of an mta do you run on your laptop that doesnt support smtp auth?

On Tuesday, September 4, 2012, Jay Ashworth wrote:

> - Original Message -
> > From: "William Herrin" >
>
> > There are no "good" subscribers trying to send email direct to a
> > remote port 25 from behind a NAT.
>
> Users, like myself, running Linux on home computers and laptops; our local
> sendmail-equivalents will in fact attempt direct delivery to remote SMTP MX
> servers, and we generally move around enough that setting a smarthost is
> semi-impractical, at least on laptops.
>
> I'm a bad subscriber, Bill?
>
> 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   #natog  +1 727 647
> 1274
>
>

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

Re: Blocking MX query

[Ray Wong]

On Tue, Sep 4, 2012 at 7:44 AM, Jay Ashworth  wrote:
> - Original Message -
>> From: "William Herrin" 
>
>> There are no "good" subscribers trying to send email direct to a
>> remote port 25 from behind a NAT.
>
> Users, like myself, running Linux on home computers and laptops; our local
> sendmail-equivalents will in fact attempt direct delivery to remote SMTP MX
> servers, and we generally move around enough that setting a smarthost is
> semi-impractical, at least on laptops.

OpenVPN, et al...

nice for being able to not only relay via the home server, but also
access SMB or even NFS shares and the like, which you'd also not want
reachable from the outside.

Re: Strange Reachability Issue

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 09/04/2012 07:20 AM, Bryn Sadler wrote:
> Many thanks to Jared for jumping on this so quickly off-list, it's
> much appreciated and hopefully we're getting towards a solution
> now.
> 
> Bryn
- --
yup you are in good hands, sounds more like filtering related among
peers. Use can use communities to test this theory.


regards,
/virendra
> 
> 
> 
> 
> On 04/09/2012 15:12, "Jared Mauch"  wrote:
> 
>> I know a few folks from NTT have looked into this.  If someone 
>> from KPN would get in touch with Bryn I'm sure the issue could
>> be quickly resolved.
>> 
>> - Jared
>> 
>> On Sep 4, 2012, at 9:18 AM, Brandt, Ralph wrote:
>> 
>>> I will bet that will bet that within 48 hours of you checking
>>> and posting this the problem will mysteriously go away.
>>> 
>>> 
>>> 
>>> Ralph Brandt Mechanicsburg PA 17055
>>> 
>>> -Original Message- From: Bryn Sadler
>>> [mailto:bryn.sad...@essensys.co.uk] Sent: Tuesday, September
>>> 04, 2012 9:02 AM To: nanog@nanog.org Subject: Strange
>>> Reachability Issue
>>> 
>>> Hello all,
>>> 
>>> I was wondering if anyone might be able to share their thoughts
>>> on a strange issue we're experiencing with NTT at the moment.
>>> We're AS48273 and are advertising a prefix 94.198.184.0/21
>>> through AS 8190 (single upstream provider at the moment). We've
>>> been doing this for some years now, and all has been fine. The
>>> last few days we seem to have disappeared from NTT's worldwide
>>> routing tables, with the exception of Europe. If we use their
>>> looking glass to query any NTT european router we can see the
>>> prefix, being learned via AS 286 then AS 8190, as expected. If
>>> we look at any other router outside of europe, there is simply
>>> no entry for that prefix. Elsewhere in the world we seem to be 
>>> fine, we're in every other network I've looked at and general 
>>> reachability is fine.
>>> 
>>> First step was to contact the NTT NOC, and they've confirmed
>>> that there's no Internal routing/config issue on their network,
>>> but that they cannot discuss their peering arrangements due to
>>> NDAs. We've also picked it up with KPN (AS 286), who have
>>> verified that the prefix is visible throughout their network
>>> (true), and that they are advertising it to NTT. One thing of
>>> note is that Global Crossing are learning our prefix from KPN
>>> as well, and the prefix is showing fine in their global
>>> tables.
>>> 
>>> We seem to be caught in the classic finger pointing scenario,
>>> but I can't get my head around why the prefix is visible in NTT
>>> Europe, but not anywhere else, unless they have a config error
>>> somewhere on their network. We've checked a few of the routes
>>> from AS 8190 and they are in the NTT global tables just fine,
>>> and at least in Europe they seem to have the same community
>>> values etc. We're still following on with NTT, but can anyone
>>> offer some wisdom for new avenues to pursue?
>>> 
>>> Thanks for your help,
>>> 
>>> Bryn Sadler
>>> 
>>> 
>>> This message has been scanned for viruses by essensys
>>> mailcontrol
>>> 
>> 
> 
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iF4EAREIAAYFAlBGGlMACgkQ3HuimOHfh+GpNgD+PMX5zFgMcCc7pzLr9e/yskNs
RESv+rEeZKC2t1UfpCYA/0vPN8JlgiRLoRi+S/kkJwOEXMlzYMnHS7eGkOn0YU4j
=PJwR
-END PGP SIGNATURE-

Re: Blocking MX query

[Jay Ashworth]

- Original Message -
> From: "William Herrin" 

> There are no "good" subscribers trying to send email direct to a
> remote port 25 from behind a NAT. 

Users, like myself, running Linux on home computers and laptops; our local
sendmail-equivalents will in fact attempt direct delivery to remote SMTP MX
servers, and we generally move around enough that setting a smarthost is
semi-impractical, at least on laptops.

I'm a bad subscriber, Bill?

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   #natog  +1 727 647 1274

Re: Strange Reachability Issue

[Bryn Sadler]

Many thanks to Jared for jumping on this so quickly off-list, it's much
appreciated and hopefully we're getting towards a solution now.
 
Bryn




On 04/09/2012 15:12, "Jared Mauch"  wrote:

>I know a few folks from NTT have looked into this.  If someone
>from KPN would get in touch with Bryn I'm sure the issue could be
>quickly resolved.
>
>- Jared
>
>On Sep 4, 2012, at 9:18 AM, Brandt, Ralph wrote:
>
>> I will bet that will bet that within 48 hours of you checking and
>> posting this the problem will mysteriously go away.
>> 
>> 
>> 
>> Ralph Brandt
>> Mechanicsburg PA 17055
>> 
>> -Original Message-
>> From: Bryn Sadler [mailto:bryn.sad...@essensys.co.uk]
>> Sent: Tuesday, September 04, 2012 9:02 AM
>> To: nanog@nanog.org
>> Subject: Strange Reachability Issue
>> 
>> Hello all,
>> 
>> I was wondering if anyone might be able to share their thoughts on a
>> strange issue we're experiencing with NTT at the moment. We're AS48273
>> and are advertising a prefix 94.198.184.0/21 through AS 8190 (single
>> upstream provider at the moment). We've been doing this for some years
>> now, and all has been fine. The last few days we seem to have
>> disappeared from NTT's worldwide routing tables, with the exception of
>> Europe. If we use their looking glass to query any NTT european router
>> we can see the prefix, being learned via AS 286 then AS 8190, as
>> expected. If we look at any other router outside of europe, there is
>> simply no entry for that prefix. Elsewhere in the world we seem to be
>> fine, we're in every other network I've looked at and general
>> reachability is fine.
>> 
>> First step was to contact the NTT NOC, and they've confirmed that
>> there's no Internal routing/config issue on their network, but that they
>> cannot discuss their peering arrangements due to NDAs. We've also picked
>> it up with KPN (AS 286), who have verified that the prefix is visible
>> throughout their network (true), and that they are advertising it to
>> NTT. One thing of note is that Global Crossing are learning our prefix
>> from KPN as well, and the prefix is showing fine in their global tables.
>> 
>> We seem to be caught in the classic finger pointing scenario, but I
>> can't get my head around why the prefix is visible in NTT Europe, but
>> not anywhere else, unless they have a config error somewhere on their
>> network. We've checked a few of the routes from AS 8190 and they are in
>> the NTT global tables just fine, and at least in Europe they seem to
>> have the same community values etc. We're still following on with NTT,
>> but can anyone offer some wisdom for new avenues to pursue?
>> 
>> Thanks for your help,
>> 
>> Bryn Sadler
>> 
>> 
>> This message has been scanned for viruses by essensys mailcontrol
>> 
>

Re: Strange Reachability Issue

[Jared Mauch]

I know a few folks from NTT have looked into this.  If someone
from KPN would get in touch with Bryn I'm sure the issue could be
quickly resolved.

- Jared

On Sep 4, 2012, at 9:18 AM, Brandt, Ralph wrote:

> I will bet that will bet that within 48 hours of you checking and
> posting this the problem will mysteriously go away. 
> 
> 
> 
> Ralph Brandt
> Mechanicsburg PA 17055
> 
> -Original Message-
> From: Bryn Sadler [mailto:bryn.sad...@essensys.co.uk] 
> Sent: Tuesday, September 04, 2012 9:02 AM
> To: nanog@nanog.org
> Subject: Strange Reachability Issue
> 
> Hello all,
> 
> I was wondering if anyone might be able to share their thoughts on a
> strange issue we're experiencing with NTT at the moment. We're AS48273
> and are advertising a prefix 94.198.184.0/21 through AS 8190 (single
> upstream provider at the moment). We've been doing this for some years
> now, and all has been fine. The last few days we seem to have
> disappeared from NTT's worldwide routing tables, with the exception of
> Europe. If we use their looking glass to query any NTT european router
> we can see the prefix, being learned via AS 286 then AS 8190, as
> expected. If we look at any other router outside of europe, there is
> simply no entry for that prefix. Elsewhere in the world we seem to be
> fine, we're in every other network I've looked at and general
> reachability is fine.
> 
> First step was to contact the NTT NOC, and they've confirmed that
> there's no Internal routing/config issue on their network, but that they
> cannot discuss their peering arrangements due to NDAs. We've also picked
> it up with KPN (AS 286), who have verified that the prefix is visible
> throughout their network (true), and that they are advertising it to
> NTT. One thing of note is that Global Crossing are learning our prefix
> from KPN as well, and the prefix is showing fine in their global tables.
> 
> We seem to be caught in the classic finger pointing scenario, but I
> can't get my head around why the prefix is visible in NTT Europe, but
> not anywhere else, unless they have a config error somewhere on their
> network. We've checked a few of the routes from AS 8190 and they are in
> the NTT global tables just fine, and at least in Europe they seem to
> have the same community values etc. We're still following on with NTT,
> but can anyone offer some wisdom for new avenues to pursue?
> 
> Thanks for your help,
> 
> Bryn Sadler
> 
> 
> This message has been scanned for viruses by essensys mailcontrol
> 

RE: Strange Reachability Issue

[Brandt, Ralph]

I will bet that will bet that within 48 hours of you checking and
posting this the problem will mysteriously go away. 



Ralph Brandt
Mechanicsburg PA 17055

-Original Message-
From: Bryn Sadler [mailto:bryn.sad...@essensys.co.uk] 
Sent: Tuesday, September 04, 2012 9:02 AM
To: nanog@nanog.org
Subject: Strange Reachability Issue

Hello all,

I was wondering if anyone might be able to share their thoughts on a
strange issue we're experiencing with NTT at the moment. We're AS48273
and are advertising a prefix 94.198.184.0/21 through AS 8190 (single
upstream provider at the moment). We've been doing this for some years
now, and all has been fine. The last few days we seem to have
disappeared from NTT's worldwide routing tables, with the exception of
Europe. If we use their looking glass to query any NTT european router
we can see the prefix, being learned via AS 286 then AS 8190, as
expected. If we look at any other router outside of europe, there is
simply no entry for that prefix. Elsewhere in the world we seem to be
fine, we're in every other network I've looked at and general
reachability is fine.

First step was to contact the NTT NOC, and they've confirmed that
there's no Internal routing/config issue on their network, but that they
cannot discuss their peering arrangements due to NDAs. We've also picked
it up with KPN (AS 286), who have verified that the prefix is visible
throughout their network (true), and that they are advertising it to
NTT. One thing of note is that Global Crossing are learning our prefix
from KPN as well, and the prefix is showing fine in their global tables.

We seem to be caught in the classic finger pointing scenario, but I
can't get my head around why the prefix is visible in NTT Europe, but
not anywhere else, unless they have a config error somewhere on their
network. We've checked a few of the routes from AS 8190 and they are in
the NTT global tables just fine, and at least in Europe they seem to
have the same community values etc. We're still following on with NTT,
but can anyone offer some wisdom for new avenues to pursue?

Thanks for your help,

Bryn Sadler


This message has been scanned for viruses by essensys mailcontrol

Re: Blocking MX query

[Rich Kulawiec]

On Tue, Sep 04, 2012 at 08:05:06AM -0400, William Herrin wrote:
> I also doubt the efficacy of the method. Were this to become common
> practice, a spammer could trivially evade it by using his own DNS
> software or simply pumping out the address list along with
> pre-resolved IP addresses to deliver the mail to. For all I know, they
> already do.

You're precisely correct.  They've been doing this for many years,
(a) because it's efficient (b) because it evades detection by techniques
that monitor MX query volume (c) because few MX's change often (d) because
it scales beautifully across large botnets.

---rsk

Strange Reachability Issue

[Bryn Sadler]

Hello all,

I was wondering if anyone might be able to share their thoughts on a strange 
issue we're experiencing with NTT at the moment. We're AS48273 and are 
advertising a prefix 94.198.184.0/21 through AS 8190 (single upstream provider 
at the moment). We've been doing this for some years now, and all has been 
fine. The last few days we seem to have disappeared from NTT's worldwide 
routing tables, with the exception of Europe. If we use their looking glass to 
query any NTT european router we can see the prefix, being learned via AS 286 
then AS 8190, as expected. If we look at any other router outside of europe, 
there is simply no entry for that prefix. Elsewhere in the world we seem to be 
fine, we're in every other network I've looked at and general reachability is 
fine.

First step was to contact the NTT NOC, and they've confirmed that there's no 
Internal routing/config issue on their network, but that they cannot discuss 
their peering arrangements due to NDAs. We've also picked it up with KPN (AS 
286), who have verified that the prefix is visible throughout their network 
(true), and that they are advertising it to NTT. One thing of note is that 
Global Crossing are learning our prefix from KPN as well, and the prefix is 
showing fine in their global tables.

We seem to be caught in the classic finger pointing scenario, but I can't get 
my head around why the prefix is visible in NTT Europe, but not anywhere else, 
unless they have a config error somewhere on their network. We've checked a few 
of the routes from AS 8190 and they are in the NTT global tables just fine, and 
at least in Europe they seem to have the same community values etc. We're still 
following on with NTT, but can anyone offer some wisdom for new avenues to 
pursue?

Thanks for your help,

Bryn Sadler


This message has been scanned for viruses by essensys mailcontrol

Re: Regarding smaller prefix for hijack protection

[Richard Barnes]

This seems like an opportune time to remind people about RPKI-based
origin validation as a hijack mitigation:



I haven't run the numbers, but it seems like doing RPKI-based origin
validation is probably a lot cheaper than upgrading routers to store a
fully deaggregated route table :)


On Tue, Sep 4, 2012 at 12:29 PM, Aftab Siddiqui
 wrote:
> The thing to acknowledge is that you've realized it otherwise if you follow
> the CIDR report than you will find bunch of arrogant folks/SPs not willing
> to understand the dilemma they are causing through de-aggregation.
>
> Regards,
>
> Aftab A. Siddiqui
>
>
> On Tue, Sep 4, 2012 at 10:19 AM, Anurag Bhatia  wrote:
>
>> I didn't realized the routing table size problem with /24's. Stupid me.
>>
>>
>>
>> Thanks everyone for updates. Appreciate good answers.
>>
>>

Re: Blocking MX query

[William Herrin]

On Tue, Sep 4, 2012 at 6:07 AM, Ibrahim  wrote:
> I've read old archive about blocking SMTP port (TCP port 25). In my current
> situation we are mobile operator and use NAT for our subscribers and we
> have few spammers, a bit difficult to track it because mostly our
> subscribers are prepaid services. If we block TCP port 25, there might be
> "good" subscribers will not be able to send email.

Hi,

There are no "good" subscribers trying to send email direct to a
remote port 25 from behind a NAT. The "good" subscribers are either
using your local smart host or they're using TCP port 587 on their
remote mail server. You may safely block outbound TCP with a
destination of port 25 from behind your NAT without harming reasonable
use of your network.


> We are thinking to block MX queries on our DNS server, so only spammer that
> use their own SMTP server will got affected. All DNS queries from our
> subscribers already redirected to our DNS cache servers. But seem Bind
> don't have feature to block MX query. Any best practice to block MX query?

Best practice is: don't mess with the DNS.

I don't know if any resolver software supports what you want to do
here. If it does, I don't know what the repercussions are likely to
be. I do know that historically, altering DNS results has proven
problematic. For example, returning an A record for your search server
in place of no-host responses wreaks all manner of havoc.

I also doubt the efficacy of the method. Were this to become common
practice, a spammer could trivially evade it by using his own DNS
software or simply pumping out the address list along with
pre-resolved IP addresses to deliver the mail to. For all I know, they
already do.

Regards,
Bill Herrin


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

Re: Blocking MX query

[Tony Finch]

Ibrahim  wrote:
>
> We are thinking to block MX queries on our DNS server, so only spammer that
> use their own SMTP server will got affected. [...] Any best practice to
> block MX query?

Don't do this. It won't hinder spammers and it'll cause problems for legit
users.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

Re: Blocking MX query

[Suresh Ramasubramanian]

Sure you will get it - but there's also spam through various webmail
services, spam through the outbounds of different ISPs etc that you
won't prevent with your approach.

On Tue, Sep 4, 2012 at 3:54 PM, Ibrahim  wrote:
>
> We create special NAT that all destination use TCP port 25 will be NATed to
> one public IP address only. And this public IP address is registered on most
> of RBLs. But we are still receiving complaint about spammer from this public
> IP address :-)



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

Re: Blocking MX query

[Ibrahim]

Hi Suresh,

We create special NAT that all destination use TCP port 25 will be NATed to
one public IP address only. And this public IP address is registered on
most of RBLs. But we are still receiving complaint about spammer from this
public IP address :-)


Regards
Ibrahim

On Tue, Sep 4, 2012 at 5:12 PM, Suresh Ramasubramanian
wrote:

> Feel free to block port 25.  Most if not all mail providers offer
> email access on webmail and on an alternate smtp port (587)
>
> If you have NAT - the problem is that if you have spammers abusing
> your service (or abusing other services on port 25) providers will end
> up blocking your NAT gateway IP and then you have a problem.
>
> You will want to look at walled gardens or similar to block spamming /
> infected users.
>
> Please see the maawg best practice for walled gardens and port 25
> management.
>
> On Tue, Sep 4, 2012 at 3:37 PM, Ibrahim  wrote:
> > Hi All,
> >
> > I've read old archive about blocking SMTP port (TCP port 25). In my
> current
> > situation we are mobile operator and use NAT for our subscribers and we
> > have few spammers, a bit difficult to track it because mostly our
> > subscribers are prepaid services. If we block TCP port 25, there might be
> > "good" subscribers will not be able to send email.
> > We are thinking to block MX queries on our DNS server, so only spammer
> that
> > use their own SMTP server will got affected. All DNS queries from our
> > subscribers already redirected to our DNS cache servers. But seem Bind
> > don't have feature to block MX query. Any best practice to block MX
> query?
> >
> >
> > Regards
> > Ibrahim
>
>
>
> --
> Suresh Ramasubramanian (ops.li...@gmail.com)
>

Re: Blocking MX query

[Suresh Ramasubramanian]

On Tue, Sep 4, 2012 at 3:48 PM, Ibrahim  wrote:
> Not block, but we use DNS transparent proxy mechanism. We need to do this
> as our government request all ISP to block porn sites  :-)

Plenty of ways to work around that actually.  This stops random people
from accessing porn sites but you are not likely to see spammers or
bots get deterred too much by this mechanism.  Still it does come in
useful as part of a larger walled garden strategy.

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

Re: Blocking MX query

[Ibrahim]

Not block, but we use DNS transparent proxy mechanism. We need to do this
as our government request all ISP to block porn sites  :-)


Regards
Ibrahim

On Tue, Sep 4, 2012 at 5:13 PM, Bacon Zombie  wrote:

> Are you saying that you only allow your subscribers to use your DNS Servers
> and block access to all other DNS Server?
>
> On 4 September 2012 11:07, Ibrahim  wrote:
>
> > Hi All,
> >
> > I've read old archive about blocking SMTP port (TCP port 25). In my
> current
> > situation we are mobile operator and use NAT for our subscribers and we
> > have few spammers, a bit difficult to track it because mostly our
> > subscribers are prepaid services. If we block TCP port 25, there might be
> > "good" subscribers will not be able to send email.
> > We are thinking to block MX queries on our DNS server, so only spammer
> that
> > use their own SMTP server will got affected. All DNS queries from our
> > subscribers already redirected to our DNS cache servers. But seem Bind
> > don't have feature to block MX query. Any best practice to block MX
> query?
> >
> >
> > Regards
> > Ibrahim
> >
>
>
>
> --
> 
>
> 
>
> ???
>
>
> BaconZombie
>
> LOAD "*",8,1
>

Re: Blocking MX query

[Bacon Zombie]

Are you saying that you only allow your subscribers to use your DNS Servers
and block access to all other DNS Server?

On 4 September 2012 11:07, Ibrahim  wrote:

> Hi All,
>
> I've read old archive about blocking SMTP port (TCP port 25). In my current
> situation we are mobile operator and use NAT for our subscribers and we
> have few spammers, a bit difficult to track it because mostly our
> subscribers are prepaid services. If we block TCP port 25, there might be
> "good" subscribers will not be able to send email.
> We are thinking to block MX queries on our DNS server, so only spammer that
> use their own SMTP server will got affected. All DNS queries from our
> subscribers already redirected to our DNS cache servers. But seem Bind
> don't have feature to block MX query. Any best practice to block MX query?
>
>
> Regards
> Ibrahim
>



-- 


???


BaconZombie

LOAD "*",8,1

Re: Blocking MX query

[Suresh Ramasubramanian]

Feel free to block port 25.  Most if not all mail providers offer
email access on webmail and on an alternate smtp port (587)

If you have NAT - the problem is that if you have spammers abusing
your service (or abusing other services on port 25) providers will end
up blocking your NAT gateway IP and then you have a problem.

You will want to look at walled gardens or similar to block spamming /
infected users.

Please see the maawg best practice for walled gardens and port 25 management.

On Tue, Sep 4, 2012 at 3:37 PM, Ibrahim  wrote:
> Hi All,
>
> I've read old archive about blocking SMTP port (TCP port 25). In my current
> situation we are mobile operator and use NAT for our subscribers and we
> have few spammers, a bit difficult to track it because mostly our
> subscribers are prepaid services. If we block TCP port 25, there might be
> "good" subscribers will not be able to send email.
> We are thinking to block MX queries on our DNS server, so only spammer that
> use their own SMTP server will got affected. All DNS queries from our
> subscribers already redirected to our DNS cache servers. But seem Bind
> don't have feature to block MX query. Any best practice to block MX query?
>
>
> Regards
> Ibrahim



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

Blocking MX query

[Ibrahim]

Hi All,

I've read old archive about blocking SMTP port (TCP port 25). In my current
situation we are mobile operator and use NAT for our subscribers and we
have few spammers, a bit difficult to track it because mostly our
subscribers are prepaid services. If we block TCP port 25, there might be
"good" subscribers will not be able to send email.
We are thinking to block MX queries on our DNS server, so only spammer that
use their own SMTP server will got affected. All DNS queries from our
subscribers already redirected to our DNS cache servers. But seem Bind
don't have feature to block MX query. Any best practice to block MX query?


Regards
Ibrahim

Re: Color vision for network techs

[Kyle Creyts]

Tei:
such applications exist, see

http://dankaminsky.com/2010/12/15/dankam/

http://www.wpcentral.com/augmented-reality-app-windows-phone-ids-colors-real-world-video

http://daily-steampunk.com/steampunk-blog/2012/05/27/augmented-reality-steampunk-and-learing-color-vacuum/
On Sep 3, 2012 5:07 AM, "Tei"  wrote:

> Standards can have "bugs", and a standard that is not compatible with
> maybe 5% of the population is buggy.
>
> Almost any standard that start "this is red and this is green" is
> flawed this way.  This mean any future standard created as to look
> into this type of stuff (and i18n and localization and others) to not
> create flawed buggy standards.
>
> Old standards can be updated ... (maybe include lines of the same
> color but different contrast), but we all know how hard is to update
> standards.
>
> If I where one of these dudes, I would download/create a app for my
> iphone that recolorice video to change colours to others I could tell
> the difference.
>
>
>
> --
> --
> ℱin del ℳensaje.
>
>