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 don't like that.
Parsing Received: and adding the information to SMTP-level arguments is
bad, because it adds complexity: If Received: can be parsed, the
recipient MTA/Sieve/MUA can do it and there's no need for RCPT TO
arguments in the first place.
OK. That's simpler. I thought more about trace= and I think
it's a half solution: you still don't know who asserted what in
the trace= field. I'm fine with solicit= meaning it contains only
the Solicitation header keywords (and contains all of them,
not just a subset).
I'd say that ONLY the first MTA may add SOLICIT=, and ONLY based on the
Solicitation field and/or the MUA's SMTP/SUBMIT SOLICIT= argument.
Other MTAs may not: if there are Received fields at all, neither they
nor Solicitation may be parsed to construct SOLICIT=.
Hmmm ... I'd simplify that one more time. You need to be able to
grab the solicitation header in case there are non-supporting
mtas in the middle.
How about this:
If the mua says SOLICIT=, there MUST be a Solicitation: header.
The keywords should match.
If you receive SOLICIT= using this extension, you must pass it
along intact if the next hop supports this extension.
If you receive a message from an mta that is not supporting this
extension, you MAY (not must), for operational reasons,
grab the keywords (all of them) from the Solicitation: header.
That last one is in the grey area, but I think it meets the
goals of message transport and I believe does not violate
2821 as long as we're clear on the requirement to continue
relaying. Ned and/or John can certainly chime in. IMHO,
this requirement is particularly important during the period
when the extension is starting to be implemented.
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.
This sounds good, but IMO it also implies that relays have no business
influencing this decision with TRACE= information of any kind.
Yes. Relays MUST simply relay messages. Only when a message
has reached an MTA under the *direct control of the recipient*
can other actions be taken. Is everybody happy with that
phrase before I start sprinkling it throughout the draft? :)
Regards,
Carl