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.
It it seriously not capable of handling what is needed, particularly any
kind of verification, callback, exchange of certificates, etc, etc.
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.
ETRN can be extended. Unfortunetly I do not see mail server operators
adobpting new extensions unless they have more reason then just this.
The whole idea is to do it all together and make serious case for upgrade.
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.
First of all I do not disagree that its out of scope. Second I'v actually
done technical work on this issue and I have SMTP working over SSL tunnel
as do many other but its not as simple as this and we need standards on
how SMTP certificates would be issued, etc. The problem is that there is
no standard on this and no wide use and only few MTAs have any kind of
support for it. And if you notice I'm actually big advocate of using
certificate for mail transmission & server verification and I know all
about this - I do not see it being used in many places (and its a good
way to stop SPAM BTW) until more work has been done on it.
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?
Since you mention it again, I do not see IETF SMTP working group in the
list of current working groups. And there was no organized effort to work
on SMTP for quite some time except for S/MIME. There are some groups
workin on unified messaging but this is not the same.
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.
SMTP AUTH sends passwords in clear text for starters.
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.
I meant to find a way to use exactly this standards in the more general
SMTP server verification mechanism. As alternative to PKI based
verification. This has been raised on IETF before as being less secure,
but this maybe sufficient for many.
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.
Delivery confirmation will only be solved issue when everyone supports it.
Address verification in its current form is unsecure that is why everyone
disables it. But it is usefull feature to have and we need to look into this.
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.
The current draft of the charter is in places vague and needs more work. I
do however think that only what would can be new version of SMTP would be
able to solve number of needed features, this question has been raised
here on IETF numerous times and I know people are interested in technical
resolution to number of outstading issues. I also think that if number
of features added into new version is substantial, it will provide serious
reason for users to upgrade where as gradual one feature additions do not
seem to be working.
BTW - I fully understand that number of issues raised already have
solution to a degree. I would however like to see official standards
and besides having solution to number of these issues will just make the
entire process go falster (and I'm already been told 2 years is too
optimistic for working group like this..). So more to the point, those who
have done work on real solutions are even more welcome then others :)
--
William Leibzon