begin quotation by Eric Allman on 2003/7/24 14:13 -0700:
I don't understand some of these.
2. Make SMTP AUTH (RFC 2554) a MUST.
Why? I'm currently doing this using STARTTLS, which also authenticates. I
agree that some authentication might be reasonable as a MUST, but I don't see
any reason to tie it explicitly to AUTH.
STARTTLS only authenticates if you use client certificates, and then it's still
a good idea to use SASL EXTERNAL to assert the identity you want the SMTP
server to use, since certificates can include just an X.500 style user
identifier which has no value as an SMTP identity. In addition, SMTP AUTH is
not hard to implement.
3. Make STARTTLS + SASL PLAIN (RFC 3207, RFC 2595) the mandatory
to implement authentication mechanism.
See above.
Mandatory-to-implement means you have to implement the feature, but you don't
have to use it. The goal is to make sure any compliant client can interoperate
with any compliant server given appropriate configuration. The best way to do
that is to pick one mechanism which everyone has to implement, even if not
everyone uses it.
We really need to put a nail in the coffin of unauthenticated mail submission.
4. Make 8BITMIME a MUST.
I'm not sure about this one. I can see wanting to make clients simpler by
giving them a guarantee that they never have to do 8->7 bit encoding. But
they probably have to anyway to deal with legacy systems -- submit hasn't
taken the world by storm, alas.
Also, in environments where the next hop MTA doesn't support 8BITMIME, you've
put yourself in a situation where either (a) the MDA has to implement
encoding, or (b) you might find yourself dealing with a lot of bounces, which
will require that the client encode, bringing us right back to the previous
paragraph.
I don't see a problem with requiring the MDA to implement 8bit mime downgrade
encoding. My understanding is that 8BITMIME is very widely deployed, so even
MDAs which didn't implement encoding would rarely cause problems. I can be
talked out of this idea, but I do think a widely deployed full-standard
extension might be worth upgrading from a SHOULD to a MUST.
begin quotation by Vaudreuil, Greg M (Greg) on 2003/7/25 12:58 -0500:
If the intent is to uplevel a new protocol to "modern" standards, may I
suggest that submission servers be required to support Binary SMTP?
We can't require an extension for submit which has yet to prove itself as
either valuable or widely deployed.
I believe several of these changes may make this protocol recycle at proposed
standard... do we have multiple interoperable implementations of startTLS and
SASL PLAIN in Submission servers and clients?
Changing the timeouts would cause a recycle at proposed and we have to do that.
Making an end-user wait 30 minutes to submit their email is just not reasonable.
It would be no problem to demonstrate multiple independent interoperable
implementations of STARTTLS and SASL PLAIN in submission servers and clients
with appropriate configuration. I know Mozilla, Apple Mail and Mulberry
support it on the client side, and I know Sun and commercial Sendmail support
it on the server side. And that includes at least two independent SSL
implementations (NSS, OpenSSL), and at least 4 independent SASL PLAIN
implementations.
- Chris