This falls under anti-spam which IMO currently represents the main impetus
for SMTP "change."
There are many anti-spam proposals that imposes change. Because of this,
the technical design approach we used was to analyze all proposals
(including Malamud's proposal) and see how they are all related to each
other and also addressed other design goals. The end was result was a new
generalized SMTP model for our mail server providing two new design
features:
1) 3rd party programmable logic to process new commands with the expectation
of new possible SMTP commands introduced (including our own), and
2) A "Black Box" access control hook system at each state from connection to
quit.
In addition, the CAN-SPAM Act is seriously viewed as a very important item
that we must support. In my technical review of the CAN-SPAM Act, there
are two basic technical mandates that relates to SMTP:
1) Verifiable Return Addresses
2) Subject/Topic Identification
Although there is a 3rd mandate (opt-out capability for the user), I don't
believe this is applicable to SMTP unless some standard opt-out trigger/tag
automation concept is introduced.
A summary of the CAN-SPAM Act can be viewed at:
http://www.spamlaws.com/federal/summ108.html#s877
Item #1 (Return Paths) is already addressed in our new design. Our "Black
Box" hook allows us to provide validate the data pass to it. In this case,
the return path along with other already established data (connection IP and
machine domain, etc). Currently, we use a CBV concept only because its the
only thing currently possible and proven to work with the current SMTP
protocol. I don't wish to rehash the issues related to it but to simply
note it is the CONCEPT that is important. It is a BLACK BOX and thus it
allows a future replacement when a more ideal IETF endorsed method is
invented.
Item #2 (Topic Identification) is the main issue right now that is not
possible with the current specs and for this reason, I believe it is one
aspect about the CAN-SPAM Act that has the spammers licking their chops. As
you can read in the summary referenced above, a conflictive statement is
made with the parenthetical clarification of the labeling requirement:
The Controlling the Assault of Non-Solicited Pornography and
Marketing Act requires
unsolicited commercial e-mail messages to be labeled (though not by
a standard method) .....
I believe this is one item the IETF should address when refinement input is
provided to the FCC. We need to remove this potential "non-standard
labeling" loop hole. I will address this again below.
Currently, the only way possible for a new SMTP system to offer a system
policy to address Subject/Topic Identification processing is to allow the
data to be transmitted. Spammers provide a higher weight to email
addresses when DATA can be delivered (transaction completed). This is based
on a spammer's statistics report that was leaked out by 'some dumbass spam
company' [sic] to an ASRG participate showing their entire year-to-date spam
history. Interested parties can check out the sapmmer data here:
http://www1.ietf.org/mail-archive/working-groups/asrg/current/msg08868.html
In our particular case, our "hook" into the DATA state will provide us with
a way to offer operators or 3rd party developers to perform Subject/Topic
Identification filtering.
Also, there seems to be a "disturbing trend" currently perpetuated by YAHOO
to permits spammers to complete their transactions and to perform all
checking at the DATA state. For YAHOO, this DATA state validation
processing currently includes performing the final local user recipient
validation since it has allows for all RCPT addresses to be initially
accepted at the RCPT state. Since YAHOO is also promoting their Domain Key
proposal which a functional specification we can currently classify as
"vapor-specs," they have a high interest instilling the idea that all
validation should be performed at the DATA stage.
Now, how all this relate to Malamud's proposal?
Well, when I first reviewed the proposal (rev 02) I wanted to see if the
proposal addressed the CAN-SPAM Act topic identification mandate.
According to the proposal's current class keywords, there are 3
classifications:
MAPS-UBE Unsolicited Bulk Email
ADV Unsolicited Commercial Email
ADV:ADLT Sexually Explicit Commercial Mail
Per the proposal, the classification is provided as MAIL FROM: extended
attributes. So it seems that this proposal will help SMTP developers
provide system policy "CAN-SPAM" Ready features in thier software.
Of course, the obviously problem as with all new SMTP altering proposals,
this will only apply to compliant clients. However, what is important to
realize is due to the non-standard labeling loophole in the Act, spammers
will have no incentive nor legally required reason to comply with this
method.
This is reason why I have repeatedly stated that we need to seriously review
the SMTP functional specification and provide "enforcement" concepts.
Unless the fundamental philosophy and "relaxed spirit" of SMTP functional
specification is reviewed to begin offer developers the ability to enforce
compliance, we seriously minimize the acceptance and deployment of any
anti-spam proposal.
Of course, we still have the ability to do topic identification at the DATA
state so all is not lost by any means, but the impact is this proposal (and
all others) is reduced drastically. In short, designers will need to do
provide two logics to address topic identification.
Fortunately, there is one item in CAN-SPAM Act that allows us to provide us
a direction of compliancy enforcement. CAN-SPAM section 11.2 says:
SEC. 11. IMPROVING ENFORCEMENT BY PROVIDING REWARDS FOR INFORMATION ABOUT
VIOLATIONS; LABELING
(2) a report, within 18 months after the date of enactment of this
Act,
that sets forth a plan for requiring commercial electronic mail to
be
identifiable from its subject line, by means of compliance with
Internet
Engineering Task Force Standards, the use of the characters `ADV' in
the
subject line, or other comparable identifier, or an explanation of
any
concerns the Commission has that cause the Commission to recommend
against the plan.
So there you have it. We have the opportunity to do this correctly.
In summary, I throwing this out for thought:
Do we tell the FCC that spammers must comply with "SMTP 821.3" which
includes support for Malamud's "A No Soliciting SMTP Service Extension"
with allowance for 6 month (or 1 year) time frame for compliance?
Basically my concern here is that unless the IETF addresses compliancy
enforcement, SPAMMERS can use this to legally side step support for any new
SMTP extended protocol.
Is the proposal too complicated creating an acceptance and deployment
barrier? and if so, do we help spammers "simplified" their efforts by
offering a new simpler SUBJECT command concept that can be issued before
(RCPT or DATA)?
I personally like the SUBJECT idea because it keep the concept open and
flexible for other automation ideas. Malamud's proposal is well written and
I believes helps address the main issue it attempts to address. However, it
is too restrictive to a particular need where the same result can be
achieved with a simple SUBJECT line. The SUBJECT line idea can address
this and many other neat concepts such as overhead reducing mail driven
events. For example, subcribing to a mail list:
EHLO mailer.foobar.com
MAIL FROM: <jsmoe(_at_)example(_dot_)com>
RCPT TO: listadmin-somelist(_at_)whereever(_dot_)com
SUBJECT: subscribe
QUIT
The feature and product benefits offered by a SUBJECT line design change is
much greater and wider than this specific EHLO/MAIL FROM design change which
targets only one concept.
I will support Malamud's proposal if endorsed, but I like something like a
SUBJECT command from a design standpoint and greater benefits it offers.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: <ned+ietf-smtp(_at_)mrochek(_dot_)com>
To: <ietf-smtp(_at_)imc(_dot_)org>; <carl(_at_)media(_dot_)org>
Cc: <ned(_dot_)freed(_at_)mrochek(_dot_)com>; <hardie(_at_)qualcomm(_dot_)com>
Sent: Saturday, January 24, 2004 6:14 PM
Subject: Comments requested on draft-malamud-no-soliciting-04.txt
Folks,
A couple of weeks ago I received a request from the author to progress
draft-malamud-no-soliciting-04.txt to proposed standard. I reviewed the
document and sent a rather long list of corrections and suggestions to the
author, most of which have been incorporated into the -04 version.
Here's the document abstract:
This Internet-Draft proposes an extension to SMTP for an electronic
mail equivalent to the real-world "No Soliciting" sign. In addition
to the service extension, a new message header and extensions to the
existing "received" message header are described.
Under differerent circumstances I probably would have just brought this
document up for discussion on this list. However, timing constraints are
such
that Ted Hardie, my co-AD, suggested, and I agreed, that moving forward
with a
last call at this time is the right thing to do. As such, I have requested
the
IETF Secretariat to last call the document. (The last call announcent
hasn't been sent yet but presumably will be sent soon.)
Let the discussion begin...
Ned