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