ietf-smtp
[Top] [All Lists]

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

2004-01-29 03:57:35

----- Original Message ----- 
From: "Keith Moore" <moore(_at_)cs(_dot_)utk(_dot_)edu>
Subject: Re: Last Call: 'A No Soliciting SMTP Service Extension' to Proposed
Standard


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 only reason for this is to satisfy the CAN-SPAM Act or any other
national law that mandates topic identification.  Otherwise, why would
Spammers support it?

In CAN-SPAM,  Section 10. STUDY OF EFFECTS OF COMMERCIAL ELECTRONIC MAIL.
Item #2 says:

             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.

Assuming this particular proposed is endorsed,  what I envision when the
IETF reports to the FCC its final input CAN-SPAM Act refinement,  the direct
marketer lobbies might  resist it for the following arguments:

1) Complexity and high cost of implementation.

There are two parts that are basically defined:  Support for Server Policy
Detection at the protocol level and topic identification at MAIL FROM and
the body header.    It promotes costly client software changes deemed
unnecessary or more than required for CAN-SPAM compliance, hence a barrier
to acceptance and deployment. The router situation is important here.   They
might argue that only topic identification is necessary.  See #3

2)  Inherently and traditionally mail software use a SUBJECT line for topic
identification.

They might argue their CAN-SPAM Ready software is already using the Subject
line for multiple delivery systems and compliance with other laws that are
based on a natural usage of a subject line.  The solicitation line will be
deemed as unnecessary. Only applies to SMTP.  [Side note: isn't this a
Network Control Line?.  They might argue MUA software are not designed to
deal with network control lines]

3)  Easier Server designs:

If they are smart, they might argue that it is far easier and less costly
design change to add a new state such as SUBJ: for clients and servers. This
is especially true for routing situations.   They might be resistance to
this because this closes the current loophole where topic identification is
only possible when the DATA is received - a highly desirable state point for
spammers to reach.   But this all depends on the strength of the IETF
enforcement for topic identification.

Unless I am completely off base,  thanks to you,  <g>   the only value I see
in this proposal is the server no-solicitation advertisement in EHLO,  As
you said, that's an highly desirable optimization feature.

Finally, of course, none of this will not work unless the IETF takes a
stance on enforcement (i.e, not optional).   What part of the proposal
should be enforceable?   The Server Policy Identification or the Topic
Identification?  If this particular proposal is endorsed,  a server
advertising No-Solicitation finding a solicitation: header at the DATA stage
is grounds for automatic rejections, auditing and tracing and reporting to
the spam-cops because they didn't follow the EHLO tags?

Thanks

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com







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