[Top] [All Lists]

Re: Last Call: 'A No Soliciting SMTP Service Extension' to Proposed Standard

2004-01-28 07:37:31

----- 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>; 
Sent: Tuesday, January 27, 2004 8:40 PM
Subject: Re: Last Call: 'A No Soliciting SMTP Service Extension' to Proposed

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

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

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.

<Prev in Thread] Current Thread [Next in Thread>