----- Original Message -----
From: "Carl Malamud" <carl(_at_)media(_dot_)org>
To: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>
Sent: Wednesday, January 28, 2004 8:47 PM
Subject: Re: Last Call: 'A No Soliciting SMTP Service Extension' to Proposed
Standard
Carl,
The basic problem with it is that it REQUIRES passthru systems to
support
this.
Not true. Read it again and look at the traffic
on the list. That wasn't my intent and, if in my
draftmanship I didn't get it right, I believe we
can make that all clearer.
Can you give me a chance to revise based on the discussion
we've heard and see if it addresses your concerns?
Regards,
Hi Carl,
I have put much thought and time into this among other things. I have read
your specs over and over, like I had back in rev 01 and rev 02 and yes, I
have read it again now and re-read the thread.
But you are the cog of this proposal, so obviously you have probably better
seen it thru. If you believe I am wrong, by all means, please show me why.
The following is my technical view on this. Lets take a stand back into the
balcony and look at what we have with SMTP today. The SMTP original spirit
and fundamental ground rules are:
1) Accept all final destination mail, and
2) Restrict relaying to authenticated or trusted sessions only (established
by whatever means, IP relay tables, AUTH, POP B4 SMTP, etc).
That's pretty much it I believe. I think it was Henry Ford who said
"Fundamental, simple, anyone can drive it!" <g>
So to me, if the sender is non-anonymous (trusted session), I really don't
give a hoot . The trust is already established. They can send whatever
they want. The server implementation may or may not display the
NO-SOLICITATION. I believe your specs (section 4) say the absence of the
tag "SHALL NOT" be construed as consent. That's works for me. Its an
implementation issue. But I will like to get back to this later.
However, when we have no trust, that is where the trouble begin. The
current industry problem is a result of the lack of ability to reliably and
optimally "gain or obtain that trust" at the SMTP level. I call this
anonymous access.
So in this vain, anonymous access controls need to be place on what can be
delivered to the local user (either with system wide or per recipient based
on the implementation). This and any other proposal in this area best
applies to anonymous access final destination mail only.
But now lets gets back to non-anonymous routed messages by spammers.
The problem I see is this Technical Software Design issue that MUST be
considered in the implementation.
When a CLIENT is compliant with CAN-SPAM (which you need to agree will be
the only reason why they may want to support this proposal in the first
place), the receiver now routing the message will need to be COMPLIANT
whether or not the router and/or the downlink receiver have a
no-solicitation policy.
Why?
Because the router NEEDS to be ready compliant just in case the downlink
receiver is compliant. If the downlink is not compliant, then that is not a
problem.
Look at it this way.
We have a compliant client and the compliant final destination receiver
host. No routing. The sender is going direct to the final destination host.
The server's system admin policy expects and only allows "CAN-SPAM ready"
clients following your proposal to gain access. The CAN-SPAM ready client
expectation is both technical and legal as well.
Nothing in the middle can alter this technical and legal expectation of the
client and final destination server.
So the only way around I see is as follows:
You must document a technical specification that final destination SMTP
server software with protocol level dynamic no-solicitation accept/reject
logic, MUST support the compliant CAM-SPAM client by performing the
accept/reject logic at both the MAIL FROM (or RCPT) state and also the DATA
state in order to catch the possible solicitation: header.
If I am missing something, please tell me.
Please remember, in my view, CAN-SPAM is the only reason this need is
required. Spammers are not going bother otherwise. CAN-SPAM ready clients
are going to make sure that any direct trust with a user is not broken by
some non-compliant middle ware. So a final destination server can not
solely rely on just using the MAIL FROM SOLICIT= to reject/accept spam. It
will need to also have a redundant logic at the DATA stage just in case a
non-compliant router broke that trusted spammer-user relationship.
Also, you do realized this isn't going to work unless the IETF mandates that
CAN-SPAM Ready clients follow this specification? Which to me is another
monkey wrench because in my view, when this is endorsed, I believes
spammers will resist it and reject it because it complexity creates a
deployment problem and they already use the SUBJECT line for topic
identification. They will scratch their heads on why a Solicitation line is
needed when it may be quite possible that they are using multiple and new
delivery systems down the road.
Anyway, thats my view on the matter.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com