Subject: unusual config problem

From: Craig Dewick <[email-masked]>
Date: Fri, 9 Jul 1999 11:20:14 +1000 (EST)

Hi,

I'm still running the vr17 release (I'll upgrade later today), however
I've been having a small apparent problem with the config.

In the ftpaccess file I have the following lines:

passwd-check rfc822 enforce
deny-email IEuser@
deny-email IE20User@
deny-email IE30User@
deny-email IE40User@
deny-email IE50User@
deny-email mozilla@
anonymous-root /export/ftp

amongst others.

The deny-email lines work fine, but I've noticed entries in the logfile
for connection with 'netcache@' as the password which have been allowed,
and I would have assumed that a string like that wasn't rfc-822 complient.
Is it?

If it's not rfc-822 complient, why isn't the 'passwd-check rfc822 enforce'
line doing it's job? I have seen entries in the logfile for passwords
which are refused because they're not rfc-822 complient, but any that are
structured 'string@' seem to get through.

Also, can I use wildcards in the email spec for the deny-email lines? If
yes, then could I use something like

deny-email IE?0User@

instead of one line for each variation of the IE version number?

Regards,

Craig.

---

From: Michael Smith <[email-masked]>
Date: Thu, 8 Jul 1999 23:44:05 -0300 (ADT)

> line doing it's job?

I think it still allows you to enter your username@, and wu-ftpd fills out
the fqdn with the reverse IP mapping of the client's host.

---

From: Gregory A Lundberg <[email-masked]>
Date: Fri, 9 Jul 1999 06:45:44 -0400

> I've been having a small apparent problem with the config.

:P

> and I would have assumed that a string like that wasn't rfc-822
> complient.  Is it?
> 
> If it's not rfc-822 complient, why isn't the 'passwd-check rfc822
> enforce' line doing it's job? I have seen entries in the logfile for
> passwords which are refused because they're not rfc-822 complient, but
> any that are structured 'string@' seem to get through.

Legacy has it that entering username@ is good enough if you mean your email
address is username@<clienthost> .. and, once upon a time, it may have
been.  Nowadays, <clienthost> is rarely your mailhost or even has a proper
MX.  But we're stuck with the assumption.

The RFC 822 check does not (in fact, cannot) guarentee the email address
entered is valid or correct.  All it does is make a (rather lame) attempt
to be sure the email address looks even remotely like it could possibly be
a usable email address.  *blink*

> instead of one line for each variation of the IE version number?

You can use a full regular expression:

deny-email (IE([2-5]0)?user)|(mozilla)@

-- 

Gregory A Lundberg              WU-FTPD Development Group
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195

---

From: Craig Dewick <[email-masked]>
Date: Fri, 16 Jul 1999 14:30:29 +1000 (EST)

Hi Greg,

> > I've been having a small apparent problem with the config.

I've got the source for 2.5.0 here now. 8-) Just don't currently have the
time to build and install it. Hopefully something this weekend...

> MX.  But we're stuck with the assumption.

Agreed.

> a usable email address.  *blink*

However the mere fact that I've enabled rfc-822 enforcement has reduced
the load on this machine (and my PPP link) considerably, so it shows that
there are still plenty of people trying to access using equally-lame
non-complient strings for the anonymous password.

I guess what could be done is enforce domain resolvability *plus* rfc-822
complience, whereby a domain name must be in the DNS, and must correctly
match the IP address from which the packets have actually originated. Of
course this is open to fraudulence too, but at least this would act as a
double-discouragement to amateur hacking attempts, etc.

> deny-email (IE([2-5]0)?user)|(mozilla)@

I didn't realise that I could do this. Thanks for pointing it out.

Regards,

Craig.

---

From: Gregory A Lundberg <[email-masked]>
Date: Fri, 16 Jul 1999 09:59:51 -0400

> non-complient strings for the anonymous password.

To be honest, I find it hard to believe that rfc-822 had anything to do
with it.

Most likely, you made other changes as well.  Or you were under attack and
the script kiddies finally decided to move on to greener pastures (I see
that happen a lot here).

> double-discouragement to amateur hacking attempts, etc.

You might check ftp.win.ne.jp.  Ayamura has a patch which does what you
want and he's probably got it on his server.  Browse arround in the area
near the wu-ftpd mirror.

Personally, I think it's a waste of time (yours, and the daemon's) to worry
about it.  There's no good way to verify the address entered is a real
email address short of sending an email off and waiting a week or so to see
if a bounce comes back (if it's a batched UUCP address, you might want to
wait a month or two just to be sure).

--

---

From: "Thomas R. Kimpton" <[email-masked]>
Date: Fri, 16 Jul 1999 11:40:06 -0400

>wait a month or two just to be sure).

If you wanted to check my address, for example <[email-masked]>
you could get the MX record for the domain, then connect to the mail
port (numbered lines are responses from the mail daemon, un-numbered
are from the verifying side):

220 www.maned.com ESMTP Sendmail 8.8.5/8.8.5; Fri, 16 Jul 1999 11:29:06 -0400 (EDT)
helo goober.maned.com
250 www.maned.com Hello goober.maned.com [199.224.118.245], pleased to meet you
mail from:<[email-masked]>
250 <[email-masked]>... Sender ok
rcpt to:<[email-masked]>
250 <[email-masked]>... Recipient ok
rset
250 Reset state
quit

220 www.maned.com ESMTP Sendmail 8.8.5/8.8.5; Fri, 16 Jul 1999 11:29:06 -0400 (EDT)
helo goober.maned.com
250 www.maned.com Hello goober.maned.com [199.224.118.245], pleased to meet you
mail from:<[email-masked]>
250 <[email-masked]>... Sender ok
rcpt to:<[email-masked]>
550 <[email-masked]>... User unknown
rset
250 Reset state
quit

I *think* that would be a quick and dirty verification.

Tom.
Oz:  So, do you guys steal weapons from the Army a lot?
Willow:  Well, we don't have cable, so we have to make
our own fun.
-- Innocence - Buffy the Vampire Slayer

---

From: Gregory A Lundberg <[email-masked]>
Date: Fri, 16 Jul 1999 12:06:37 -0400

> are from the verifying side):

An MX is not strictly required for mail delivery.  And if you find one, it
does not tell you the server will know anything at all about the address
you're interested in .. it may just be a relay.

Well-managed mail hosts do not allow VRFY in the SMTP conversation.  So
you'd have to do a 'fake message' .. send a MAIL and RCPT.  I don't know
about most mail admins, but if I started seeing a large number of
NULL-QUEUE messages, I'd investigate.  And I'd probably just firewall your
FTP server away from my mail server rather than waste the time ...

My opinion is this: anonymous is anonymous.  Courtesy says you will give me
your email address when using my FTP server anonymously, but courtesy
cannot be enforced.  I don't care what you say, just so you send a PASS
(because it's required after USER and I *will*not* run an FTP server which
does not require USER).

Most of the people giving bad 'passwords' for anonymous access fall into
two classes:

 - Windows users (including the odd Mac or X-Windows person)

 - Poor typists (isn't that a requirment to be a sysadmin?)

There are far better ways to fend of the undesirables than pissing off your
legitemate users.

--

---

From: Ted Keller <[email-masked]>
Date: Fri, 16 Jul 1999 12:47:32 -0400 (EDT)

I agree with Gregory here....  My firewall answers ok to everyone - and
simply relays the message to the real internal server.

Additionally, I've noted that apache proxy servers (others may do the
same) use anonymous@ as the e-mail address.  It's not even real.  The
domain name is not even included.  But - it does satisfy the ftp daemons
desire for some kind of an address.

ted keller