SPF (Sender Policy Framework) discussion list

Graham Murray | 1 Oct 2004 07:28

Picon

Re: The pretty name

"Hector Santos" <winserver.support <at> winserver.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)

Hector Santos | 1 Oct 2004 08:30

2822 Header Analysis [Re: The pretty name]


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

> "Hector Santos" <winserver.support <at> winserver.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

(Continue reading)

Jason Gurtz | 1 Oct 2004 15:15

Re: 2822 Header Analysis [Re: The pretty name]

On 10/1/2004 02:30, Hector Santos wrote:

<snip>
> * Once accepted, you must deliver or provide reason for non-delivery.
> 
> Since SA is a post smtp process[...]

That's not necessarily true.  For instance, when SA is run via something
like the MIMEDefang sendmail milter you can do something like this
pseudo code

if($spamScore>10)
    action_smtp_reject("550:  Spamscore too high");
else
    action_tag_subject("****Possible SPAM**** " . "$subject");

Yea, MIMEDefang rocks...  :)

Cheers,

~Jason

--

--

Hector Santos | 2 Oct 2004 00:59

Re: 2822 Header Analysis [Re: The pretty name]

In other words, it is done at the SMTP DATA state point.   In this case, as
I said, a few times, the laws is on your side.

Followup:

The SA lawsuit was settled.  Unfortunately, the settlement details was not
disclosed.  I would of love to see how the courts would of view this
important case.

See  http://www.webservertalk.com/message377661.html

I see Ann Mitchell has made a statement about this.  I don't agree with her
assessment that the case was "legally unsupportable."   Obviously the
spammer had enough of a legal argument to make Ironport settle. If it was
cut and dry as she states, there would be no reason to settle. The court
would of throw the case out just like it has in the past prior to CAN-SPAM.

I would like to end my input on this with basically stating my main point we
must be careful with 2822 analysis concepts, especially those that preach
modifications.  It is a fallacy to believe that an ISP can do whatever it
wants with accepted mail without notifications.

Thanks

Sincerely,

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

(Continue reading)

Greg Hewgill | 2 Oct 2004 02:25

Re: 2822 Header Analysis [Re: The pretty name]

On Fri, Oct 01, 2004 at 06:59:38PM -0400, Hector Santos wrote:
> The SA lawsuit was settled.
> See  http://www.webservertalk.com/message377661.html

Oh, now that makes more sense. I was trying to figure out what sort of
legal trouble SpamAssassin had got themselves into. This is SpamCop,
which is quite a different organization.

Greg Hewgill
http://hewgill.com

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta features SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your subscription, 
please go to http://v2.listbox.com/member/?listname=spf-discuss <at> v2.listbox.com

Attachment (smime.p7s): application/x-pkcs7-signature, 2225 bytes

Chris Drake | 2 Oct 2004 03:40

Picon

SPF-Enabled open-source product announcement and request-for-input: Generic anti-spam platform

I have budgeted and contracted workers to build a generic (free)
Win32/Unix/Mac multilingual anti-spam open-source GUI "platform"
product - the point of which will be to provide a standard interface
to producers of anti-spam technologies.

It operates as one (or simultaneously 2 or more) of either:
 * a native email plugin to popular email products (eg: outlook /
   outlook express)
 * a transparent proxy (intercepting POP / SMTP / webmail traffic
   streams)
 * a traditional proxy (requiring email client adjustments to POP/SMTP
   servers)
 * a serverside multiuser POP/SMTP "front-end" (interface to existing
   back-end servers, or, called-out-to by existing servers)

The "platform" itself does nothing more than provide the installation,
message handling, and GUI interaction for anti-spam technologies.
Vendors of antispam ideas can distribute or sell "plug-ins" for this
platform confident in the knowledge that their code will work for all
major email programs and webmail services on all popular operating
systems (either on the client-end or server-side), *and* that their
anti-spam code will interoperate correctly with other vendor antispam
code and antivirus products etc. 

This "platform" is either a client (end user) "download", or a server
(ISP installed) component.

This posting is to solicit comments and suggestions.  My staff have
just worked their first month on this project, and I'm looking out to
make sure that nothing has been overlooked before significant amounts

(Continue reading)

william(at)elan.net | 1 Oct 2004 10:13

Re: 2822 Header Analysis [Re: The pretty name]


> 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.

I've thought about this many times, probably even mentioned it at asrg or 
ietf-smtp once or twice. And its not too difficult to write an extension
to SMTP draft that if you advertise HEADERS capability, SMTP Client can 
use new HEADERS command to send headers first and then use DATA to send
rest of the email. 

The problem is that those that dont want to send headers first (like I 
suspect most spammers) would not do it and for others it'll take long
time to adopt this to the point that those others could be denied access
if they don't support the extension.

--

-- 
William Leibzon
Elan Networks
william <at> elan.net

Mark Shewmaker | 1 Oct 2004 09:43

Re: 2822 Header Analysis [Re: The pretty name]

On Fri, 2004-10-01 at 02:30, Hector Santos wrote:
>
> 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

Can you explain more clearly exactly how SA could be violating can-spam?

If can-spam says to a spammer "You may do X if you have made sure of Y
and the end recipient has not done Z; else we can press charges", what
does that have to do with the ISP or their mail filtering code at all?

I saw nothing in the act that implied that it would restrict the end ISP
in any way.  (Although I saw enough horrible, illegal, and also
amazingly vague nonsense in it that I can only hope the whole law is
thrown out in court.)

I especially saw nothing linking the fed's presumed future use of
canspam's definition in prosecuting spammers, with any requirement that
anyone else must *also* use or even consider canspam's definition, such
as ISP's when they set up mail filters for end recipients.

If you see such a link somewhere, please help me see it too.

--

-- 
Mark Shewmaker
mark <at> primefactor.com

Hector Santos | 1 Oct 2004 10:58

Re: 2822 Header Analysis [Re: The pretty name]

----- Original Message -----
From: "Mark Shewmaker" <mark <at> primefactor.com>
To: <spf-discuss <at> v2.listbox.com>
Sent: Friday, October 01, 2004 3:43 AM
Subject: Re: 2822 Header Analysis [Re: [spf-discuss] The pretty name]

> On Fri, 2004-10-01 at 02:30, Hector Santos wrote:
> >
> > 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
>
> Can you explain more clearly exactly how SA could be violating can-spam?

Simple.

The argument can be made is SA is breaking user-vendor contracts.  Before
CANSPAM, there was nothing within the Federal Laws and guidelines that give
Direct Marketers the privy to do business using user-vendor contracts.
Early lawsuits were based on mal-practice which were thrown out of court.
Now there is a Federal Law in the books.

Why do you think the Direct Marketers quickly endorsed the bill?    It gives
them the right to do business, and if you going to break what could be
considered a Legal transaction, you better have a good reason for doing so
because they now have legal grounds to stand on.

Of course, this is based on the idea if SA is automatically doing the job of

(Continue reading)

Mark Shewmaker | 1 Oct 2004 12:21

Re: 2822 Header Analysis [Re: The pretty name]

On Fri, 2004-10-01 at 04:58, Hector Santos wrote:
> From: "Mark Shewmaker" <mark <at> primefactor.com>
>
> Before
> CANSPAM, there was nothing within the Federal Laws and guidelines that give
> Direct Marketers the privy to do business using user-vendor contracts.

I'm sorry.  I don't see where CANSPAM caused marketers to gain any
rights they didn't already have, (excepting the fact that it pre-empted
state anti-spam laws.)

As far as I can tell, it merely made certain actions illegal.  I don't
see how it actually legitimized anything, or caused senders to be able
to have any additional privileges that they didn't already have.

> Why do you think the Direct Marketers quickly endorsed the bill?    It gives
> them the right to do business, and if you going to break what could be
> considered a Legal transaction, you better have a good reason for doing so
> because they now have legal grounds to stand on.

I had always assumed that the direct marketers liked the fact that it
*looked* like their shoddy business practices gained some legitimacy
from the act.  I never saw where they actually did gain any new actual
legal legitimacy at all, even though they did gain the 
marketing-lie-type appearance of such.

(I also figured they wanted some sort of weak bill to pass, to ease
pressure and attention away from having a stronger bill go through.  And
of course they didn't object to the serious flaws in it that aren't
important to them.)

(Continue reading)

Paul Howarth | 1 Oct 2004 12:56

Re: 2822 Header Analysis [Re: The pretty name]

Mark Shewmaker wrote:
> On Fri, 2004-10-01 at 04:58, Hector Santos wrote:
> 
>>From: "Mark Shewmaker" <mark <at> primefactor.com>
>>
>>Before
>>CANSPAM, there was nothing within the Federal Laws and guidelines that give
>>Direct Marketers the privy to do business using user-vendor contracts.
> 
> 
> I'm sorry.  I don't see where CANSPAM caused marketers to gain any
> rights they didn't already have, (excepting the fact that it pre-empted
> state anti-spam laws.)
> 
> As far as I can tell, it merely made certain actions illegal.  I don't
> see how it actually legitimized anything, or caused senders to be able
> to have any additional privileges that they didn't already have.

Not being in the US, I personally couldn't care less what CAN-SPAM says, but 
my understanding was that it "asserts no legal effect on Internet Service 
Providers rights to reject unwelcome email traffic, implement and enforce any 
spam blocking or email service policy they see fit" - quote from
http://www.spamhaus.org/position/CAN-SPAM_Act_2003.html

Implementing SA would therefore seem to be one of the things an ISP can do 
without legal risk from CAN-SPAM?

Paul.

(Continue reading)

Return

Return to gmane.mail.spam.spf.discuss.

Project Web Page

SPF (Sender Policy Framework) discussion list

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane