Carl Malamud writes:
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.
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.
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=.
TRACE= is a way of saying "while relaying, I looked at this message and
inferred that blah blah" which seems to open the door to activist
relays. IMO opening that door is bad and would need strong
justification. (In principle I think activist relays are okay as local
policy. Local policy is beyond internet standards.)
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.
This sounds good, but IMO it also implies that relays have no business
influencing this decision with TRACE= information of any kind.