ietf-smtp
[Top] [All Lists]

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

2004-01-28 18:32:51

As sort of an experiment I'm trying to think about it this way:

The real indication about sender intent is in the Solicitation: header field. This is arguably where it belongs, because it's a description of the message content (or more specifically the intent behind the content) that isn't very related to mail transport.

The MAIL FROM SOLICIT= parameter and the system-wide policy announcement in the EHLO response are basically optimizations. If the SMTP client realizes that a message won't get through anyway because the server is going to filter it due to the server's announced policy, it's better for both the client and the server if they terminate the session early. Similarly if the server realizes that the sender's SOLICIT= parameter is incompatible with the policies of all of the message's recipients, it can avoid accepting the message at all - and by telling the SMTP client that up front, the error reporting becomes more reliable.

Seen from this angle, there's no requirement to "pass" SOLICIT at all from server to client, because it's not an end-to-end service. Each MTA can elect to use the EHLO response, and (if the extension is supported) the SOLICIT option if it wants to, assuming that there's a Solicitation: field in the message. (It's a lot like the SIZE extension in the sense that each MTA derives SIZE by looking at the message rather than looking at the SIZE parameter it got when the message was received.)

The trick to making this work is to REQUIRE the SMTP server that advertises NO-SOLICITATION to implement its policy consistently (based on the Solicitation: field, and also based on the SOLICIT= field if present) regardless of whether the client implements the optimization. So the result of trying to send a message is essentially the same either way; it just saves time and bandwidth to implement the extension.

Keith

p.s. At some point lawmakers might decide that a client's failure to honor NO SOLICITATION is a kind of denial-of-service attack, but I sort of doubt it will ever get to that point. I consider it somewhat more likely that they would require senders to include Solicitation: fields in their messages, and that they would define specific keywords to use in those cases. (let's hope that different legislative bodies don't produce conflicting definitions of the same keywords)

The basic problem with it is that it REQUIRES passthru systems to support
this.

If the router does not support the relaying of this SOLICIT information,
then we now have given a spammer a loophole, or put another way, the
responsibility is now on the router to make sure the client WHO MAY BE
compliant with CAN-SPAM continues to be compliant during a route.   A
passthru system can not alter this, and in some vain can have a legal impact in making what is otherwise a compliant client, non-compliant during the
route.   Someone will take the blame.

The only way this proposal works is for final destinations. But the client
will not know if has reached the final destination or not.


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