IETF SMTP Working Group Proposal at smtpng.org

Wed Aug 21 02:07:50 UTC 2002

Several (if not most) of the issues indeed have solutions available (which 
is BIG plus for this project), almost none have any standards and there 
is no wide use at all. I want standards to be defined and in a way that 
would encorage worldwide use of these features and in my view it means
new version of the protocol (with backward compatibility). I fully 
understand that this will not be implemented in couple years and if this 
all goes though, we'll be lucky to see the features used in any serious 
manner in no less then 5 years.

> On Tue, 20 Aug 2002, william at elan.net wrote:
> 
> > This is copy of the message sent to IETF mail list. As subject said,
> > I'd like to organize IETF working group to define new additions to SMTP.
> >
> > ----------------
> > As everyone I'm sure have seen on the last "why is spam a problem" and
> > other similar threads on ietf as well as numerous similar threads on
> > other lists and boards, there is a serious need to do something to limit
> > amount of unsolicited email. While the roots maybe social issue I do not
> > see why we can not work on it from technical point of view. In addition
> > to that during last years, I'v seen real need for new features to be
> > added into SMTP, such as ones for callback, delayed transmission, delivery
> > notification,secure communications, etc, etc and there are in fact
> > several drafts available on some issues. As far as anti-spam  mechanisms I
> > do not belive we should force some particular method on everyone but
> > rather built several verification features into protocol and allow server
> > operators to themselve choose if they want to use it. Where the features
> > were use the email would be considered more secure and users can use that
> > to sort out mail (as many do already with special filters).
> 
> William,
> 
> While not trying to discourage you from your efforts, I would like to
> recommend that you not reinvent the wheel. The list you have presented
> already has some possible solutions to it which I have listed below.
> 
> Delayed transmission: Are we talking about rate limiting, or delivery of
> specific messages at specific times? Either way this is more an MTA issue
> in my eyes, than a protocol issue. Rate limiting is already availible in
> at least one major Unix MTA.
> 
> Delivery notification: Possibly a protocol issue. This is availible as a
> semi-standard. RFC1891 is your friend:
> ftp://ftp.isi.edu/in-notes/rfc1891.txt
> 
> Secure communication: TLS, SSL.