Subject: Re: How do I prevent mail from being delivered to an ftp site; and any examples of the use of private?

From: "Gregory A Lundberg" <[email-masked]>
Date: Fri, 1 Nov 1996 20:23:02 -0500

> From: Peter C. Norton <[email-masked]>
> To: Matthew N. Reichman <[email-masked]>
> Cc: [email-masked]
> Subject: Re: How do I prevent mail from being delivered to an ftp site;
and any examples of the use of private?
> Date: Friday, November 01, 1996 4:39 PM
> 
> On Fri, 1 Nov 1996, Matthew N. Reichman wrote:
> > I have to admit I don't know how to prevent mail from being  
> > delivered to an ftp site, unless I just redirect it with  
> > procmail. I'm referring to the security warning for mail  
> > delivered to ftp sites;
> 
> Using procmail (or any other mail forwarding mechanism) is an unnecessary
> waste of resources.  You should be able to prevent mail from heading
towards
> a given host by putting in an MX record for that host.  Talk to your DNS
> admin, and he or she will know what to do.

How about a better answer?  Not having an MX record works _only_ if the
machine
in question is not accepting mail at all (in which case playing with MX
records
seems moot, at least with regard to ftp security).  Remember, support for
the
MX record is _not_ universal; many systems ignore them completely and
connect
straight to the recipient's machine anyway.  As ugly as we may feel that
is,
it's a fact of life we have to live with.

>From my reading of the FAQ and referenced documents (CERT, etc) the best
advice
currently appears to be to create an empty .forward file to disable mail
(as
well as an empty .rhosts for rlogin/rsh/rexec).

---

From: "Chadwick A. Dubuque" <[email-masked]>
Date: Fri, 1 Nov 1996 19:55:35 -0600 (CST)

Gregory A Lundberg wrote:

> machine in question is not accepting mail at all (in which case playing
> with MX records seems moot, at least with regard to ftp security).
> Remember, support for the MX record is _not_ universal; many systems ignore
> them completely and connect straight to the recipient's machine anyway.  As
> ugly as we may feel that is, it's a fact of life we have to live with.

The cool thing about UNIX boxes is that you can turn everything and anything
off individually. Just don't start sendmail, or whatever you have listening
at that port. Trust me, no mail will be delivered to the machine. ;-)

It'll make your server faster, too.

-- 
Chadwick A. Dubuque              [email-masked]
http://cadaver.acm.ndsu.NoDak.edu/~cdubuque/      finger for PGP key
"If a tree falls in the forest . . . and we've already sold the
tree . . . does it have quality?" -The Pointy Haired Boss, "Dilbert"

---

From: "Peter C. Norton" <[email-masked]>
Date: Sat, 2 Nov 1996 01:46:30 -0500 (EST)

On Fri, 1 Nov 1996, Gregory A Lundberg wrote:
> > waste of resources.  You should be able to prevent mail from heading towards

Not having an MX record doesn't _ever_ work to _prevent_ mail from arriving.
Lacking an explicit MX record for a host, BIND behaves as though there was a
weight 0 MX record pointing at the host in question.

Actually, what I was talking about was having an MX record inserted for the
ftp server that pointed to your mail server (for instance).  This means that
you have a reliable way of getting those informative messages like "Your
server is down", without it having to go through your domain's admin and/or
tech contact, through your site's postmaster, and then (maybe) to you.  This
is only if your user base is smart enough to look up your domain's info at
the NIC.  Otherwise they get to think you're out of business.  Shucks.

[snip]
> seems moot, at least with regard to ftp security).  Remember, support for the
> MX record is _not_ universal; many systems ignore them completely and connect

These systems are broken, and should not be accomodated.  There is no excuse
for a MTA to ignore an MX record. None.  Period.  In fact, I've yet to see
this behavior, and I'm not going to start anticipating it now.

> straight to the recipient's machine anyway.  As ugly as we may feel that is,

I don't have to live with it.  For instance, if some site can't properly
establish an ftp connection to my system, because their software is broken,
then they should fix their broken software.  I'm not going to butcher
anything on my end for that.

--
Faster isn't better.  Better is better.

[email-masked] 
System Administrator at large.
No one else has anything to do with what I say.
I disclaim thee! I disclaim thee! I disclaim thee!