Re: SMTP Working Group Proposal at smtpng.org

[[e-mail]]

On Tue, 20 Aug 2002 14:04:27 PDT, [e-mail]  said:

> I believe its time we start working within IETF on new version of SMTP 
> that would have more features and be more secure. I'v tried to point this 
> out several times before on nanog and ietf hoping that someone would take 
> the initiave but as this did not happen, I'm willing to do it now. At this 
> point I'm proposing creation of IETF working group that would look into 
> ways to extend SMTP. I'v created website and mailing list to discuss 
> charter of the proposed working group at http://www.smtpng.org

> 1.      General extensions on SMTP negotiation This group will work on
> extensions to general SMTP syntax with primary focus on mechanism for
> negotiation on type of verification and security for transmission of mail
> message between two mail servers.

EHLO - a done deal a decade ago.

> 2.      Callback and delayed transmission extensions
> This group will work on extensions to SMTP for email callback mechanism.
> Callback should allow for special type of negotiation on transmission where
> instead of immediately sending a message, one email server would request a
> callback and specify time when the email message can be picked up from the
> original server. Additional work should also be done on delayed transmission
> extensions as proposed in draft-vaudreuil-futuredelivery-00 draft.

ETRN could be extended, and you have a draft that should probably be handled
in the IETF-SMTP group.

> 3.      Secure SMTP transmission
> This group will focus on extensions allowing for additional security and
> encryption for SMTP transmission for situations where such functionality is
> desired by both parties.
> 4.      Certificate based verification
> This group will work on certificate-based verification. This functionality
> would involve incorporation of SSL-like functionality into SMTP to allow two
> mail servers to verify each other by exchanging certificates.

RFC2487.  Already shipped as part of Sendmail 8.11.0 over 2 years ago.
Only thing missing here is a good X.509 PKI, which is out-of-scope for
an SMTP working group anyhow.

> 5.      Callback verification
> This group will also work in conjunction with group#2 on how callback
> mechanisms can be used to verify authenticity of mail servers. Work would also
> be done on callback verification as proposed at draft-nunn-ssmtp-00.txt draft.

And this needs a new working group why, rather than doing it in the IETF-SMTP
group?

> 6.      User/Password and other authentication verification
> This group will focus on authentication verification that can be used in
> conjunction with SMTP. The primary use of authentication should be to allow
> end-users to relay messages through their ISP's mail server, but this group
> should also work on how the same methods can be used in ISP-ISP mail server
> verification. Work should also be done in conjunction with group#3 to make sure
> that clear text passwords are not sent across public networks.

The same methods can be used no problem.  There's no reason SMTP AUTH can't be
used between ISP's, except for the lack of a PKI, unless you want to manage
O(n**2) password/authentication token pairs.

> 7.      Signatory and other verification mechanisms
> This group will work on verification schemes involving special type of
> signatures that would accompany email and on other similar verification methods

We already have S/MIME and OpenPGP standards.

> 8.      Delivery confirmation and address verification
> This group will work on extensions allowing for delivery confirmation options
> to be incorporated into SMTP, the initial start can be
> draft-moore-rfc1891bis-01draft. Additional work should also be done on ways to
> use mail server verification mechanism in conjunction with email address
> verification (certain level of trust between mail servers is often desired
> before one mail server would allow another to know if certain subscriber
> exist).

Delivery confirmation is already a solved issue, with DSN and MDN support.
Address verification is going to be a can of worms - consider the reasons many
sites disable VRFY before you go much further.

> 9.      MIME extensions
> This group will work with all other groups on necessary additions and changes
> to MIME content types as used in email transmissions.

Too vague for a charter, I suspect.

> 10.  Email headers
> This group will work with other groups to define if necessary new email headers
> and work on clarification of use of existing email headers by mail transfer
> agent programs.

Similarly.

I see 2 "too vague", two "can of worms/scaling" problems (PKI and verification),
2 that should probably be handled in the current SMTP group, and a number of
already-solved problems.

I'm not sure what the working group would be charged with accomplishing.
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech