Re: RCAP mini-spec (was: Re: Keywords for "SMTP Service Extension for Content Negotiation" )

> > 4. the RCAP command is acceptable at any time that MAIL or RCPT
> > would be acceptable.  clients MAY issue RCAP before or after
> > MAIL, and they MAY issue RCAP and RCPT commands in any order.
> > (though generally it makes more sense to issue RCAP for a
> > recipient before sending RCPT for that recipient)
> > The RCAP response MUST be the same regardless of whether the
> > command is issued before or after MAIL, or before or after RCPT.
> 
> Keith, I don't assume this would be heavily used, but, as with
> SIZE, I can imagine some sites being willing to accept more
> complex formats from some senders than from others.  Of course,
> such mechanisms are easily thwarted in the absence of SMTP
> authentication or trusted transport (and would not be available
> with some of the other proposals). But, unless you have a
> substantive reason for permitting RCAP before MAIL, it would seem
> desirable to force it to come after MAIL, thereby preserving this
> implementation option at substantially no cost.

my assumption was that the return address is essentially useless for 
determining the kind of content that would be acceptable to the 
recipient - partially since they are easily forged, and partially
since there are various reasons to use a different return address than
one's normal email address.  SMTP authentication credentials might 
be useful for determining the conneg string returned, but those 
would presuambly be presented before MAIL.

my reason for allowing RCAP before MAIL was to allow query-only
sessions without having to specify a return address that won't
get used anyway and just serve to slow the query down.

still I don't claim to have nailed down every detail - this is just
a "strawman" proposal so that people have something to compare
with the proposal that uses RCPT.

Keith