Outgoing SMTP Servers

Mike Jones mike at mikejones.in
Wed Oct 26 06:56:25 UTC 2011


On 26 October 2011 05:44, Owen DeLong <owen at delong.com> 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




More information about the NANOG mailing list