Re: Revising RFC 2487

[Michael Salmon <Michael.Salmon@xxxxxxxxxxxxxxx>]

+----- On Sun, 11 Apr 1999 14:55:00 PDT, Paul Hoffman / IMC writes:
| Greetings again. It is clear that RFC 2487 needs some change in order to 
| make clearer when a server should and should not advertise STARTTLS. (There 
| was also a problem with the example in section 6 where I didn't show the 
| client EHLO after the TLS negotiation.)
| 
| But, I don't hear consensus on this list about what the change should be. 
| Here are two proposals; I'm open to others.
| 
| (1) Advertise only if ready
| 
| Change the text in section 4 to read:
| 
| The STARTTLS keyword is used to tell the SMTP client that the SMTP
| server is currently able to negotiate the use of TLS. It takes no
| parameters.
| 
| (2) Advertise if TLS is at all possible
| 
| Change the 454 code to:
| 
| 454 TLS not available due to temporary TLS processing error
| 
| and add the 455 code:
| 
| 455 TLS not currently configured or currently misconfigured
| 
| Personally, I prefer (1), but I'm not an implementor and am open to 
| suggestions.

I prefer (2) but I think that there should be a limit on the length of
time that a 454 or 455 may be returned. If after a period not exceeding
five days TLS is still not available then STARTTLS should no longer be
advertised. Furthermore I think that it should be mandatory that not
advertising STARTTLS be the default until it has been correctly
configured.

My reasoning is that mail should not be returned to the user
unnecessarily, as may be the case if STARTTLS was only advertised when
it was correctly configured but that we should not delay the returning
of mail longer than necessary (five days means that long weekends like
easter are covered).

/Michael