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.
Well, there are really two issues here. The first and most important,
as I mentioned above, is that the current proposal allows
sender-supplied and intermediary-supplied information to go in the same
field in the envelope. The second is that both mechanisms (sender
labelling and intermediary labelling) are being described in the same
document, when the two have very different degrees of reliability and
applicability. The document is our quantum unit of standardization - it
is awkward for us to say "this part of the document is proposed standard
and recommended, while this other part is experimental and dangerous
to interoperability".
Also, the bulk of this document is discussing a mechanism for senders
to label their content, and for MTAs to convey that labelling and to
convey recipient and/or site policies for accepting that content.
The mechanism for intermediaries to label content, while it's certainly
a related topic, doesn't currently get the amount of attention it
deserves.
I think it would be dangerous to give separate mechanisms. As you
said later in your note, a clueful MTA wouldn't want to use the same
keywords. But, rather than us making those decisions, I'd rather
provide a simple registry mechanism and then let users decide
what the words mean. All we're saying in this extension is that
the sender or an MTA asserts a series of keywords. We simply deliver
the mail.
There is one thing that I do think might help address your
concern. I've assumed that the only time a message is
going to be rejected based on a solicitation class keyword is
by an MTA which exercises a policy under the *direct control of the
recipient.* The decision to accept or reject mail is well outside
of the scope of this standard. I thought that was clear, but
I'd be happy to hit that point with a hammer a few more
times.
4. You indicated that we might want to do both
SYSTEM-WIDE *and* PER-RECIPIENT (e.g., more
restrictive policies for one user). I thought
about that a lot and was worried that implementation
becomes significantly harder. My goal with
system-wide was to provide a *really* easy entry
point. I could hack sendmail to do system-wide: there
is no way I could program per-recipient myself.
Maybe I wasn't clear. I want the protocol definition to support the
ability of a single MTA to impose both system-wide and per-recipient
policies if it wants to do that.
I'm fine with that. System-wide defines a base class and may be
optionally supplemented by additional per-recipient policies.
Again, would like to hear if anybody else has strong opinions
on this.
I also want the protocol definition
to allow a conforming MTA to request SOLICIT parameters from clients
and convey SOLICIT parameters to receivers even if it doesn't impose
any restrictions on mail relayed through that MTA.
That's already in there. This proposal is about the
conveying of keywords *not* the decision to accept or
reject messages. That is, potentially, the subject
of other standards or laws, but this proposal is a
mechanism for the message sender and others involved
in the delivery of the message to assert keywords,
and for the recipient to assert keywords. These
words are all drawn from a registered list. The
decision to 250 or 550 or to attempt delivery or
not is not what we're specifying here.
If we split the source/intermediate keywords in the
envelope, allow system-wide+per-recipient, and
make it *really* clear that just because a keyword
matches, we're not telling you what to do, have
I addressed your concerns? (This is in addition
to the cleanup of grammer, deletion of fluff,
etc... we talked about yesterday.)
Regards,
Carl