On Tue, 20 Aug 2002 14:04:27 PDT, william(_at_)elan(_dot_)net 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
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
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
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
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
and work on clarification of use of existing email headers by mail transfer
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
I'm not sure what the working group would be charged with accomplishing.
Computer Systems Senior Engineer
Description: PGP signature