From: Robert Elz <kre@munnari.oz.au>
To: Russ Allbery <rra@stanford.edu>
Cc: DRUMS@cs.utk.edu
Subject: Re: VRFY discussion - SUMMARY 
In-Reply-To: Your message of "20 Aug 1998 15:00:00 MST."
             <m3af4zz53z.fsf@windlord.Stanford.EDU> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 21 Aug 1998 18:48:57 +1000
Message-Id: <7035.903689337@munnari.OZ.AU>
Sender: kre@munnari.oz.au

    Date:        20 Aug 1998 15:00:00 -0700
    From:        Russ Allbery <rra@stanford.edu>
    Message-ID:  <m3af4zz53z.fsf@windlord.Stanford.EDU>

    There are times when implementing VRFY on the SMTP server represents an
    unacceptable security risk due to the necessity of fundamentally
    restructuring the way the single most security-critical part of the mail
    system runs.  Is this fact honestly in dispute?

Yes.

I suspect you're viewing the implementation techniques with blinkers on.
All VRFY needs is a list of valid addresses (or invalid ones, or both,
depending upon what is available and easier).  That's just a file for your
SMTP server to read.   I can't imagine a case where reading a file (whose
location and contents you can decide) is a bigger security problem than
putting an incoming message into stable queue storage, which is about the
minimum that you can do to process an incoming message.  Of course the
file can be a flat text file, or some kind of structured database, that
doesn't matter.

Beyond that all that is needed is a way to update the file - that can be
done in some much more secured environment - perhaps the same basic
environment that allows the mail to be processed from the queue that the
SMTP receiver has placed it in.

The same kind of technique can be used (perhaps with slightly greater
delays) to handle VRFY when handling addresses for disconnected hosts
(the typical MX for a uucp connected host).   Further, should it be
desired this can allow your SMTP server to actually reject invalid addresses
at RCPT TO time (and do it quickly if you want) for disconnected hosts,
avoiding transferring mail to bad addresses backwards and forwards over
a link.   While that probably doesn't matter a lot for your odd typo in
an address, it can help a lot when an address that has been valid, and which
receives a lot of mail becomes invalid - much better to avoid transferring
all that mail over uucp or similar.

Now of course any of this is going to impose (or might impose) some extra
administrative load on the site, so some sites might choose not to bother.
That's OK, if it is the actual site that decides this, no-one will object.
What is a problem is if a site wants to implement VRFY but finds it can't
because the implementor of their mail system didn't bother.   That gave the
implementor an advantage - less code to write, etc, and if it is a commercial
product, should have made it cheaper.   The theory is that the site can
simply get a different mailer, but in practice, that's much more difficult
than it sounds.   It can take a large site months to do a full evaluation of
a new e-mail system before installing it for production use.  That isn't
something that will be lightly undertaken, even assuming that it is possible
(which it won't be if to compete all mail system vendors have ignored VRFY
and kept their costs lower).

kre