[Top] [All Lists]

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

2004-01-28 08:39:27

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?

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