Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 Nov 2000 22:51:19 +0100
From:      Jesper Skriver <jesper@skriver.dk>
To:        Mike Silbersack <silby@silby.com>
Cc:        Alfred Perlstein <bright@wintelcom.net>, hackers@FreeBSD.ORG
Subject:   Re: React to ICMP administratively prohibited ?
Message-ID:  <20001118225119.B73853@skriver.dk>
In-Reply-To: <Pine.BSF.4.21.0011181510400.53208-100000@achilles.silby.com>; from silby@silby.com on Sat, Nov 18, 2000 at 03:18:36PM -0600
References:  <20001118183632.A99512@skriver.dk> <Pine.BSF.4.21.0011181510400.53208-100000@achilles.silby.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Nov 18, 2000 at 03:18:36PM -0600, Mike Silbersack wrote:
> 
> On Sat, 18 Nov 2000, Jesper Skriver wrote:
> 
> > > or just stop filtering totally.
> > 
> > Which is not a option in this case, and in the real world it's that
> > uncommon.
> > 
> > I'll see if I can get code together which will do this.
> > 
> > If we leave this off by default, would people object to putting in
> > this functionality ?
> > 
> > /Jesper
> 
> What's the point?  If people complain about a badly setup MX behind a
> firewall, are you going to respond and tell them to flip a sysctl?

My motivation is primarily to get the code working, and perhaps in the
future get it enabled by default. But until then tell people that a
sysctl can get this behaviour.

> This isn't a case of interoperability with a common TCP stack which needs
> to be lived with.  It's a case of something that is broken even with the
> suggested "fix".

I wouldn't call it broken, why should the routers bother to send a ICMP
access prohibited (or any of the other unreachables) if nobody cares anyway.

My approach is a bit more pragmatic, and as I can see it, the chance
that a attacker can abuse this seems very slim.

> The correct thing to do in this situation is to configure sendmail
> properly so that the MX silliness isn't needed.

Using a static mail routing from a public known MX to the real
mailserver is certainly a better solution if the same people control
both, but in this case it's not like that. 

Let me explain in a bit more detail.

We have lots of ADSL users (potentially hundreds of thousands), lots of
these have open relays(*) that relay via our mailservers, making our
mailservers open for spammers to use.

The best solution we have been able to find, was the filters that block
access to tcp/25 except from the backup-mx host, this eliminated the
open relays once and for all, with very little work.

We have no knowledge of which domains the users have (and this also
changes all the time), and the price structure doesn't leave room
for the hazzle of maintaining (and supporting) such static mail
routing table, it's also significantly easier for the users to 
understand why they should configure

xyz.dk. IN MX 10 xyz.dk.
xyz.dk. IN MX 20 backup-mx.post.tele.dk.

than

xyz.dk. IN MX 10 backup-mx.post.tele.dk.

And then do what ever to get the static mail routing configured.

*) Often a simple "gateway" like WinGate or similar with by default
   seems to give this "functionality" :-(

/Jesper

-- 
Jesper Skriver, jesper(at)skriver(dot)dk  -  CCIE #5456
Work:    Network manager @ AS3292 (Tele Danmark DataNetworks)
Private: Geek            @ AS2109 (A much smaller network ;-)

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001118225119.B73853>