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.
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