spf-discuss
[Top] [All Lists]

2822 Header Analysis [Re: The pretty name]

2004-09-30 23:30:23

----- Original Message -----
From: "Graham Murray" <graham(_at_)gmurray(_dot_)org(_dot_)uk>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Friday, October 01, 2004 1:28 AM
Subject: Re: [spf-discuss] The pretty name


"Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com> writes:

SPAMASSASIN was playing with fire and it got bit with spammers suing for
tortious interference.  It will be interesting to see the end result of
this
case.

How was SpamAssassin playing with fire? All it does it classify mail
according the user specified rules. It does not change content or
block mail (but the user can choose to block or discard mail based on
its report)

Hi Graham,

You are right.  But I'll repeat this key concept:

* Once accepted, you must deliver or provide reason for non-delivery.

Since SA is a post smtp process, it has now taken on the duty of mail
interpretation and action (Rule Based Messaging, which btw is a patented
concept).

From a product liability standpoint, SA is at risk with an automatic
rejection concept.  It has to move the message into a bin for further
review.  In general,  there is case history for this. The original based on
censorship and tort.

Now, this is where the ASRG, IETF among others who have ignored CANSPAM and
people like myself who have been making the case to NOT ignore it, comes
into play.

CAMSPAM allows for User-Vendor contracts.  These contracts can not be broken
without risk. The CANSPAM framework basically says if the spammer follows
all the rules which is generally:

a) Don't lie about your return address, and
b) Don't lie about the topic identification.

then you are open for business.  This is called capitalism. :-)

CANSPAM does not attempt to stop SPAMMERS.  It controls and adds
responsibility.  CANSPAM also does not take away any current laws so all
current laws must still be followed.

Once SA was taken over by a big $$$ company they were now an obvious open
target. A spammer who claimed they were "CANSPAM compliant" sued the company
for malpractice, tort and for breaking user-vendor contracts thus violating
CANSPAM and certain provisions of US ECPA

I predicted this was going to happen and it did.  Research my articles in
ASRG and other IETF forums going back to last year which I specifically
warned against such possibilities.

This case is still pending.  What is important to note, it is not an open
and shut case like in previous spammer suits where the judge dismissed
spammer suits due to not having any laws or precedent behind them.  Now they
do with CANSPAM.

Now. Is SA at fault?

In my assessment,  if SA shows rejection was done at SMTP via a DATA hook,
they are protected. But if  it was done on a post smtp level, any form of
automatic rejection with no notification puts them at a high risk especially
when there is a USER-VENDOR contract established as this spammer claimed he
had.

On the other hand, as you say, if it was established that the user had
defined "rules" for SA to handle, then I don't believe the spammer has a
case.  But apparently this was not the case, there was a user-vendor
contract.

CANSPAM must be taken seriously.  It is being ignored.  SPF is not a CANSPAM
ready technology since it doesn't validate the full return address as
required by CANSPAM.  This is why we don't just use SPF. By itself, it
doesn't meet the criteria for a CANSPAM-ready system.

But overall, my point is that the practice has open up a Pandora box of
problematic issues.  Overall, in my experience over the years,  it has
provided to the admin the erroneous idea they can do whatever they please
with the mail coming to or thru their system.  This is a fallacy and in my
opinion, if it isn't put under control it will continue to create new
problems such as the genesis of ideas being proposed to modify the
2822.MailForm,  the new GMAIL.COM and like systems and then defensive
systems to clean up the mess that a gmail.com altered message may have.

We just need to be careful with this 2822 research stuff.  If done, it needs
be done carefully.

Finally, I should note I have been on record that I will be 100% behind 2822
analysis if we offered a new extended SMTP command like a HEAD command where
this information can provided and analyzed at the 2821 level where any
rejection results will keep intact with the laws allowing
submission/transport level rejections.

Sincerely,

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office