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.
I have some doubts about this. I understand the desire to speed
deployment. The problem is that to some extent the values that should
go in the SOLICIT= and the Solicitation field should be dependent on
context, and in particular, the set of recipients to whom a message is
being sent. The values in the Solicitation field might be correct when
the message is originally sent to the set of recipients specified by a
sender, but not valid when the message is resent to another party with
the header intact.
I guess it boils down to a question of whether it's acceptable to copy
SOLICIT= from Solicitation: field even on message submission. If it
is, then it will automatically be copied during a resend operation into
that operation's envelope, and there's little harm to be done by having
a subsequent MTA re-copy that field.
Overall I hate to encourage MTAs to do even more peeking into content
than they do now - I think it's a trend in the wrong direction even if
we do sometimes find it useful.
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? :)
I don't mind the phrase, but you need to define it somewhere. For
instance, does "direct control of the recipient" allow an ISP to make
assertions on behalf of its customers? Does it allow a business's SMTP
server to make assertions on behalf of its employees?