Re: Comments on draft-gellens-on-demand-03.txt

[Randall Gellens <randy@xxxxxxxxxxxx>]

At 10:02 AM -0800 3/23/98, Jeff Stephenson wrote:

> As to
>architectural issues, I don't think that the fact that there are some SMTP
>implementations for which this might not be as easy to implement within SMTP
>as it would be to implement as a separate service justifies another
>port/protocol.  Given that ETRN is seen as an extension to SMTP, ATRN should
>be also.

I disagree.  Even though it only affect some implementations, I think
the architectural issue is enough to make a separate port worthwhile.
There's strong precedent for this.  I don't like standards that impose
implementation difficulties which aren't neccessary.

An extra port is not hard to do, and offers other potential security
benefits as well.


>>>2) I don't think there should be domain arguments on the ATRN command....
>>
>>The domain argument is now optional...
>
>From my reading, the domain is optional for the client (customer) but not
>the server (provider) side of the protocol; the server still needs to be
>able to validate any domains that appear in a command.  I'm not sure what
>this added complexity buys anyone.  It seems to me that the situations in
>which a customer would want to dequeue mail for a subset of their domains
>are pretty limited, and the rare case could be handled by different
>authorization IDs.

I was thinking of a case where a customer has multiple geographic
locations, each with its own domain, and wants to only download mail
for that domain.  I agree it could be handled with unique authorization
IDs, but is that really needed?  Is support for domains in ATRN hard to
implement?


>>>3) I don't see the lack of queued mail as an "error" condition worthy of a
>>>450 response....
>>
>>I don't see it as terribly important either way.  An error response
>>makes it perhaps a bit easier to know there won't be a new connection
>>coming back, so you can drop the line.
>
>I don't think there's much (if any) efficiency to be gained here.  Using C
>(customer) and P (provider), the two options seem to be
>
>   C: ATRN
>   P: (... let's see if there's mail queued for this guy ...)
>   P: 450 Nothing for you
>   C: QUIT
>
>or
>
>  C: ATRN
>  P: 250 Connection turned
>  P: (... let's see if there's mail queued for this guy ...)
>  P: QUIT
>
>I prefer the latter, because it clearly separates the case of no mail
>(meaning "try again at your scheduled time") from a temporary error like the
>authorization ID -> domain mapping database being unavailable (meaning "I'm
>having problems - try a little later").  Especially in the case of a
>customer scheduled to dial up only once a day, there may be significant
>differences in the time the host should wait before retrying.

I didn't realize you were advocating returning 250, opening the second
connection, and then issuing a QUIT in the case of no mail.  That seems
like more overhead than is needed.

The draft says to issue 450 in the case of no mail, or an attempt to
gain access to unauthorized domains.  The same code is used in order to
avoid revealing information about unauthorized domains.

I agree there should be a specific response code to indicate temporary
server failure.  I can update the draft to specify 451 for temporary
failures such as the database being down.