----- Original Message -----
From: "Carl Malamud" <carl(_at_)media(_dot_)org>
To: "Keith Moore" <moore(_at_)cs(_dot_)utk(_dot_)edu>
Cc: <iesg(_at_)ietf(_dot_)org>; <iesg-secretary(_at_)ietf(_dot_)org>;
<ietf-smtp(_at_)imc(_dot_)org>
Sent: Tuesday, January 27, 2004 8:40 PM
Subject: Re: Last Call: 'A No Soliciting SMTP Service Extension' to Proposed
Standard
1. By far the biggest problem I have with this proposal is the idea that
solicitation classes that are assigned by intermediaries can then be
copied into the SOLICIT= field of the envelope and/or used as the basis
for failure to deliver the mail.
OK, I'm convinced. In the message, you have a set of received headers
and a solicitation header: you know who made what assertions. How
about doing this:
1. The SOLICIT= parameter in the envelope MUST contain all solicitation
class keywords found in the Solicitation header.
2. An optional TRACE= parameter MAY contain additional solicitation
class keywords found in received: headers.
I'm fine with that, but would like to hear from some others how they
feel.
I agree with Keith from the basic fundamental standpoint the (SMTP) passthru
process should not be in the mail interpretation or mail alterating game.
What about Gateways? It will fall in the same category of recording the
Return-Path: header. This will force the router design to begin reading the
header to prepare SMTP envelope transactions.
I now believe the proposal is too complicated for what it is trying to
achieve.
Having the client identify the intent of the mail at the smtp protocol is
highly desirable and assist in the CAN-SPAM mandate. So this part of the
concept is good but I am now leaning to believe that a SUBJ: concept
achieves the same result and it is alot simpler in design and also has
additional benefits outside the scope of this proposal.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com