Comments on ETRN draft

I have the following comments in response to your document "SMTP
Service Extension for Remote Message Queue Starting":

1)   As you noted, there is currently no guarantee that anything will
     be sent if there is no mail queued for the system named in the
     ETRN command.  I think such a guarantee is desirable.

     Ideally this wouldn't be necessary.  However, in the real world,
     things often go wrong, especially when dealing with remote
     network and routing issues.  The network and CPU overhead for an
     SMTP session consisting of HELO and QUIT is minimal.  In my
     opinion, this overhead is well worth it, even if it's only
     useful during the initial setup and debugging of an SMTP
     installation.

     Consider the actual dollar cost of customer support versus a
     number of "empty" SMTP sessions.  In many cases the incremental
     cost of an empty SMTP session is minimal, since the
     communication channel is already open, and no additional cost is
     incurred by leaving it open a few more seconds.  (This would be
     the case for a low volume customer dialing a local phone number
     to an internet provider.  The provider charges a fixed fee for a
     minimum number of hours/month that the customer usually doesn't
     exceed.  Note that this is a typical profile for the type of
     installations that are expected to make use of ETRN.)

     Here is an example.  The assumptions are:

       Communications channel cost: $3/hour
       Empty SMTP session duration: 3 seconds
       Empty SMTP session frequency: 4/day, 365 days/year

       Customer support engineer total burdened cost: $50/hour
       Customer making call total burdened cost: $50/hour

     This translates into $.0025 per empty session, or $3.7/year.
     This is the same cost as 2.2 incremental customer phone support
     minutes per year.  This also implies that avoiding 15 minutes of
     customer phone support when an installation is set up, pays for
     6.9 years of empty SMTP sessions.  This doesn't even include the
     customer cost for activities before a support call is finally
     made.  In fact, this cost likely dwarfs all other costs.

2)   As currently specified, a positive repsonse to the ETRN command
     means "queuing definately started".  This could be an undo
     burden on many implementations.  I would prefer a positive
     response to mean "queing request definately received".  This
     would relieve the burden on the SMTP server of deciding whether
     the requested queue exists, is enabled, etc.  Note that SMTP
     servers are still free to do whatever checking is quick and
     easy.

     One reasonable implementation would be for the SMTP server to
     run a de-queuing program as an asynchronous process.  This
     program would need to perform all the checking anyway.  Forcing
     the SMTP server to also perform the checking is duplicate work,
     and could lead to revision problems between the server and the
     de-queuing program.  What if it was OK to de-queue when the
     server checked, but it became not OK when the de-queuing program
     finally ran?  Note that there is no way for the de-queuing
     program to communicate a problem back to the SMTP server, since
     the server won't be waiting for the de-queuing program's process
     to terminate.  (I agree this should be done asynchronously.)

     The "queing request definately received" protocol also allows
     de-queuing to be deferred a short amount of time.  I would
     prefer it to be explicilty stated that de-queuing may be
     deferred until after the SMTP session is terminated.  This would
     allow a very fast response to the ETRN command, with all the
     real work being done after QUIT is received.

3)   Is TURN really a security loophole?  Can't the SMTP server check
     the IP address of the client, and decide not to honor TURN if
     the client's name translated to an IP address doesn't match the
     client's actual IP address?  If a client can fake an IP address
     (as returned by GetHostByName or equivalent routine), can't it
     apply the same fake to any new connection (as required by
     ETRN)?  I'm really asking, since I'm not completely sure of the
     answers.  A response from someone who actually knows would be
     appreciated.

Received on Monday, 25 September 1995 14:48:05 UTC