Re: working group last call on ISP draft

[Randall Gellens <Randy@qualcomm.com>]

At 5:11 PM -0500 3/3/98, hansen@pegasus4.bl-els.att.com wrote:

>Correct me if I'm wrong, but as long as it refers to draft RFC's, won't it
>get rejected until those drafts become published?

A standards-track RFC can't progress ahead of documents to which it
makes any normative references.  I don't know what the rules are for
BCPs, but it makes sense to try and resolve these.


>One of the sections which refers to drafts is Section 8.4 Message
>Submission, which refers to draft-gellens-submit-05.txt and
>draft-myers-smtp-auth-09.txt. This section recommends using the SUBMIT
>protocol extended by the addition of the AUTH SMTP extension. Wouldn't it be
>better to get Gellens to modify his draft so that it incorporates the AUTH
>SMTP extension, and then make our recommendation based on the new version?

It is better to keep SMTP AUTH and SUBMIT as separate documents, since
each deals with different (but related) areas.  One can refer to the
other, but that could delay it.

SUBMIT, first and foremost, separates SMTP submission from relay.  This
alone is very useful, since it then allows sites to apply different
rules, security mechanisms, and policies based on submission versus
relay, instead of relying on IP address.

SMTP AUTH provides a way to do authentication within the SASL framework
for SMTP sessions.  It is useful with and without SUBMIT, and for
different purposes.  (End user authenticated submissions and
server-to-server authenticated sessions.)


>Based on the current text, I disagree with the statement "In this way the
>SMTP port (25) can be restricted to local delivery only." The way Gellen's
>draft is written, port 25 can still be used for traffic originating from a
>local user, as well as relay traffic. The purpose of Myers' draft is to add
>authentication to locally-originated mail so that you know who sent it,
>without affecting any other sort of port 25 traffic. In other words, Myers'
>draft is what adds a facility to enforce a security policy to either port 25
>or port 587.

Without the submission port, all SMTP traffic goes through port 25.
That can make it difficult to deploy authentication, since you would
need cooperation (and authentication entries) for each server, or you
would need software which only required authentication if the message
appeared to be a submission.


>In fact, isn't it really the authentication that we're looking for, whether
>it's implemented in either SUBMIT or SMTP? So either mechanism can be
>recommended, as long as authentication is used as well.

I think what is wanted is both separation of submission from relay, and
authentication.