ietf-smtp
[Top] [All Lists]

Re: FYI: Interesting CAM SPAM court case as it relates to 2821 vs 2822

2005-06-18 01:41:38

From: "Robert A. Rosenberg" <hal9001(_at_)panix(_dot_)com>

Since the act requires an Unsubscribe Link in the Message Body (as
well as other contact info), how can the judge rule that only header
info is covered. I think he needs a class in remedial reading (and
probably logic) based on this ruling.

As an example, if an invalid Unsubscribe URL Link appears in the
message body wouldn't that qualify as "false information"?

I'm itching to find time to read the case transcript,  but one would think
that might be a valid argument for appeal.

But off hand, I believe the judgment is basically saying the wrong law was
applied here as CAN-SPAM addressed the "fixed" header  information .  It
would be more like a fraud case covered by other laws when dealing with the
body I would think.

What had interest me is that CAN-SPAM does enforce the idea that header
information must be correct from a 2821/2822 stand point. So it would be
nice to get a good definition on the legal minimal requirements.  IOW, is
100% traceability a requirement?  Is anonymity still an option (legally)?

For example, I have been seeing an increase in 2822 headers with a missing
To: Header in phished messages.    2822 only requires  Date: and From:  (822
required Date:, From:, and To: or CC:)  and I believe Lilly has a proposal
to further relax 2822 by removing the From: requirement.     The question
then becomes which is more if a legal requirement (per CAN-SPAM)  2821
headers or 2822 headers?   A missing To is easy to understand - the
2821.RCPT TO is the target address.  But a missing From: is more
questionable since the 2821.MAIL FROM: does not necessary match it.

I guess it doesn't matter under CAN-SPAM as the basic elements of the law
is:

 1 - Don't lie about the sender address
      (Mail From? Sender:? From:? Reply-To:?)

 2 - Don't lie about the Topic (Subject?)

 3 - Give users option to opt out (any proposed standard method??)

and for spammers following these rules, in return they have a "right" to do
business with users.

From a SMTP standpoint, we can handle #1 (somewhat with recent proposals)
and possibly #2 with a DATA hook or by using Carl Malamud's proposal.  Or
possibly this where a new "SUBJ" SMTP command might be useful.

The body stuff (#3) is less SMTP related, and I guess, this is iffy part of
the law and what you were referring too.

Also, the other interest is that there are pro spammer elements of the
CAN-SPAM act which is basically about Vendor-User contracts.  As long as
they follow the above basic rules, SMTP and Admins needs to be careful about
breaking "vendor-user contracts."   In fact, I believe there was a case
settled last year with IronPort when a big direct mail spammer sued for
breaking vendor-user contracts citing CAN-SPAM.

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





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