ietf-mxcomp
[Top] [All Lists]

How is SPF different from RMX?

2004-07-26 11:29:32

How is MARID different from RMX?

Let me be more specific.  RMX was a non-starter because many people send
email using services outsourced from several different companies. For
example, Av8 Internet relays email from <user>@earthlink (and others)  
because the customer gets IP connectivity from Av8 Internet, but gets
email from earthlink.  Earthlink doesn't provide relay service for these
users; Av8 Internet does. Under RMX, Earthlink would presumably charge Av8
Internet for the RMX record (and similarly for SPF record). Alternately,
Earthlink could impose its connectivity services on the customer be
refusing to accept records for other providers, preventing outsourcing.  
RMX couldn't overcome this limitation. How does SPF work in this scenario?

It was pointed out that RMX doesn't prevent spam, since the spammer always
has a domain which they can use: either 1) the domain of the ISP of the
(usually hijacked) connection, or 2) a disposable domain.  How does SPF
deal with disposable domains and abusive use of a valid domain?

One thing that has become apparent since the passage of CAN-SPAM is that
we don't have a "bulk commercial email" problem: 90 something percent of
the commercial emailers were partially compliant with CAN-SPAM in January,
and 57% were _fully_ compliant.  If you define spam as "unsolicited bulk
commercial email", then we don't have a _spam_ problem at all. A very
small number of non-compliant emailers are being dealt with according to
CAN-SPAM.  However, they don't represent even a tiny dent in the volume of
"junk"  mail.  Instead, we have a problem with abuse email, which is
completely different from a problem of "commercial bulk email".  With the
preceding in mind, how does SPF prevent a virus-infected, hijacked
computer from sending abuse email?

RMX didn't do any of these things, but just created different "hoops" that 
the abusers could jump through, which creating significant impediments for 
legitimate email outsourcing.

Is SPF just a scheme to prevent outsourcing (or extort money from 
outsourced email service providers)?

Dean Anderson
Av8 Internet, Inc

P.S. In reviewing the archives, I was also disturbed by the misconceptions
being flung about with respect to the ECPA. I am something of an expert on
the subject, having read nearly all the case law on the subject, as well
as the congressional reports on the ECPA, the Wiretap Act, the Right to
Financial Privacy Act and other related legislation and congressional
reports. I've also been in conflict with other ISPs (lawyer to lawyer
conferences) involving potential ECPA violations.

I can say with some certainty and generality that nothing I have seen so
far in either SPF or RMX that would universally violate the ECPA: One can
certainly get permission. The ECPA is principally about permission: If you
have permission, you can do those things that you have permission to do.
If you don't have permission, you have a problem.  The "problem" can be
both civil and/or criminal.  There were several things in particular:

1) The USA PATRIOT Act altered the ECPA and the Wiretap Act with respect
to Law Enforcement access. If you are not a law enforcement officer, then
the USA PATRIOT Act didn't change anything, (unless of course, you have to
give law enforcement access.)

2) The ECPA doesn't make exception for employers. Rather, the employer's
have permission to tap your phone, and read your email, as specified in
employment policies: Its the employer's communications. The employee is
only an agent. Even so, the employer still has to respect personal
communications unless that is itself a violation of the employment policy.

The ECPA violations are practically always a case where someone did
something they didn't have permission to do.  In my personal experiences,
they have involved blocking non-spam email. Most ISPs have permission to
block spam (though there are some that don't).  No ISP's (that I have
found anyway)  have permission to block non-spam email.  Merely having a
password or "ownership of equipment" does not mean you have the customer's
permission to access/block/alter their email.  In each of my personal
experiences, once the appropriate arguments were made to the other ISPs
lawyers, they assured us they won't violate the ECPA, and didn't block
non-spam email.  A case that did go to court on the subject of using a
password beyond what it was meant for is Konop V. Hawaiian Airlines.  A
pilot created a password protected website, and each person receiving a
password agreed not to share the password with others. One fellow pilot
was persuaded to give his password to a manager. The manager used this
password to access the communications on the web site. The court found
that this access was not authorized and violated the ECPA.

The Councilman case also created quite a bit of mis-information: Having
reviewd the documents at
http://www.ca1.uscourts.gov/pdf.opinions/03-1383-01A.pdf

It found that:

Count 1: Conspiracy to violate 18 USC 2511. Court dismissed this count on
the grounds that email is in "electronic storage", and cannot be
"intercepted" under the meaning of '2511.  I agree completely. But this
does not mean that a violation of 18 USC 2701 has not occurred. As I
suspected, the defendant was not charged with a violation of 18 USC 2701.
The defendant argues that his acts were lawful under the ECPA but the
Court does not address this argument, noting on page 16:

  "Defendant's argument takes us beyond the charges in the Indictment.
  Therefore, we need not stray beyond the text of the Wiretap Act into the
  Stored Communications Act because the government sought to indict
  defendant only for conspiracy to violate Title I, 18 U.S.C. S 2511(a)"

Further, Councilman is consistent with and references Konop V. Hawaiian
Airlines, where violation of both the Wiretap Act and the ECPA was
alleged.  The Court in Konop held that the Wiretap Act was not violated,
but the ECPA was violated.  There is every reason to think that if the
defendent had been charged with a violation of the ECPA, that given Konop
and other cases, they would have been found guilty.  There is no reason to
think that one can lawfully read email without authorization or that the
privacy of email is at risk.  The dissenting argument, while persuasive
that justice was not served by allowing Councilman to get off scot-free,
was not persuasive that unlawful access of stored communications should be
prosecuted under the Wiretap Act. Congress moved to make such access
unlawful when it passed the ECPA.

ECPA compliance for SPF is conceptually simple: A provider implementing
SPF would have to obtain permission from its customers and notify them
that their service will no longer accept email from non-SPF sites, and
that most of or much of the internet is expected not to use SPF, and that
they can no longer receive email from anyone on the internet, as their
service descriptions previously read.  Having made the customers fully
aware of the changes and the implications for the customers service in a
timely fashion so that the customer can change their service provider,
then continued use indicates that the customer accepts the change.

One only gets in trouble when customers are left expecting that their
email shouldn't be blocked, and that email was blocked without their
permsission.