ietf-mxcomp
[Top] [All Lists]

Re: CSV and alternative authentication techniques

2004-07-02 10:05:25

On Fri, 2004-07-02 at 03:32, Tony Finch wrote:
On Thu, 1 Jul 2004, Douglas Otis wrote:

There are never two valid HELO domains of which to choose. The
specification [RFC 3207] clearly states to discard previous results.

OK.

The TLS session HELO/EHLO domain would be unimportant if
the client was validated by a Certificate Authority and thereby
recognized.  If not, then the TLS session HELO domain should match.

This isn't covered by RFC 3207 so needs to be explained by HNA.

However there should probably be some comment in the CSA specification
about what the server does when the client says EHLO more than once.

I feel this is not needed as it is covered in RFC3207.  I would also
like to limit the topic of TLS to a single document... Dave's of course.
: )

Note that a client can say EHLO more than once in a non-TLS SMTP session.
Should the server only use the most recent one for CSV, or the first one?
(Using the first one is probably contrary to RFC 2821.) Do they have to be
all the same?

You ask good questions.  There could be the fall-back of EHLO to HELO
and the use of EHLO to act as RSET.  As the intent of this domain in
each case (separate from the TSL issue) is to identify the client's host
name, I would not expect this to change.  However, there could be a
valid reason it may change.  To credit a portion of the mail stream to
"client-xxx.big-provider.com."  This may allow the receiver to accredit
different entities for the mail stream without requiring a new
connection.  Using EHLO would be expensive and is why RSET is used to
avoid this overhead.  Perhaps there should be a mention that if the
HELO/EHLO domain changes during a session, it should be re-evaluated.

-Doug