[Top] [All Lists]

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

2004-01-28 08:29:11

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?  :)



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