[Top] [All Lists]

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

2004-01-28 06:01:34

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.