[51104] in North American Network Operators' Group
Re: IETF SMTP Working Group Proposal at smtpng.org
daemon@ATHENA.MIT.EDU (Avleen Vig)
Tue Aug 20 22:11:44 2002
Date: Wed, 21 Aug 2002 03:10:22 +0100 (BST)
From: Avleen Vig <lists-nanog@silverwraith.com>
To: "william@elan.net" <william@elan.net>
Cc: "nanog@nanog.org" <nanog@nanog.org>
In-Reply-To: <Pine.LNX.4.33.0208201551100.5703-100000@sokol.elan.net>
Errors-To: owner-nanog-outgoing@merit.edu
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.
