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: Sat, 2 Nov 1996 12:40:31 -0500

> From: Peter C. Norton <[email-masked]>
> To: [email-masked]
> Cc: Matthew N. Reichman <[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: Saturday, November 02, 1996 1:46 AM
>
> 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.

Quite true, expect it may not be BIND which makes the decision.  It
could be
the local resolver (RESOLVE) or the mail router (SENDMAIL, SMAIL,
etc.).  The
relavant RFC's are phrased in terms of the mail router, btw.

> > 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.

RTFRFC.  Officially, support for MX is RECOMENDED, not REQUIRED.  If
a mail-
sending site chooses to bypass the MX mechanism, so be it.  I can
point to a
Fortune-100 company which has gone over to a large, well-known
software
vendor's server which (for whatever brain-dead reason) has choosen
not to
honor MX records.  By living with it, I mean (at least for the mail
I'm
getting from such sites) ignoring the non-problem and telling users
to
complain to the site's admin or the brain-dead software vendor (for
all the
good that'd do) when they don't get all their email from the company
in
question.

> 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.

Yes you do.  The subject is ftp security resulting from e-mail
attacks.  The
original question was how to set up your ftp site securely with
respect to email.
We've not been talking about attacks from outside the protocols, but
those
_properly_ using the existing protocols to take advantage of security
holes in the
setup of the various server software packages on the target machine.

I summarize the advice I've read as follows:

  1) Don't run any mail services.  This is best when you have the
resources to
     accept mail on a physically separate machine.  Be sure to
examine any
     connections (dial-up, telnet, nfs, etc) between the machines. 
If you don't
     happen to have a spare machine to dedicate to your ftp site and
want to
     accept both ftp and smtp, this obviously won't work.

  2) Run a properly secured mail server, but that's not a subject for
a mailing
     list discussing ftp.

  3) Use an empty .forward for non-real users (anonymous,
guestgroup).  I was
     watching for replies to the original posting because I question
the
     effectiveness of this approach.  Are there any other steps an
ftp admin
     can take (presuming the admin has no authority for other
services)?

It seems obvious that ftp site security is not just an ftp server
question.  If
the machine is vulnerable through some other service, that
vulnerability may be
exploited to gain unauthorized access or use of the ftp area.  If
you're an ftp
admin be sure to work closely with the admins for all other services
on the
machine.  Especially, take a close look for services for which nobody
is yet
responsible.

In closing I point to the relavant CERT advisories.  CERT takes the
time to
specifically address the problem of those who think they've secured
their system
when, in fact, they have not.  Playing with MX records, as was
originally
suggested, has no effect other than to give the ftp admin a false
belief the site
is secure.

---

From: Lou Katz <[email-masked]>
Date: Sat, 2 Nov 1996 12:54:29 -0800 (PST)

If you just want to block mail from being addressed to user ftp,
why not put the following entry into /etc/aliases?

ftp:	NoSuchUser

Since you will not have an entry for "NoSuchUser" in your password
file, your system will blandly bounce any incoming mail as being directed
to a non-existent user.

-=[Lou Katz]=-

---

From: Mitch Wright <[email-masked]>
Date: Sat, 2 Nov 1996 17:05:16 -0800

/* Lou Katz [[email-masked]] writes: */

>why not put the following entry into /etc/aliases?
I usually just do something like:

ftp:	ftp.

Note the trailing ".".  That way, your bounce looks like a genuine bounce
except that those perceptive people will notice that there are four dots
after the name instead of three.

-- 
do svidaniya,

  ~mitch

---

From: Jim Davis <[email-masked]>
Date: Sat, 2 Nov 1996 21:47:18 -0700 (MST)

On Sat, 2 Nov 1996, Gregory A Lundberg wrote:

>  Officially, support for MX is RECOMENDED, not REQUIRED.

Section 5.3.5 of RFC 1123, (one of the "Hosts Requirements" RFC, now 7
years old) explicitly says MX support is required.  Though no doubt there
still are some maladministered sites that don't.