Subject: How is SPF different from RMX?

From: Dean Anderson <[email-masked]>
Date: Mon, 26 Jul 2004 14:29:34 -0400 (EDT)

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.

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 27 Jul 2004 18:18:35 -0400

Dean Anderson <[email-masked]> wrote:
> the abusers could jump through,

  .. to send mail from domains that they legitimately have access to.

  This isn't news.

> which creating significant impediments for legitimate email
> outsourcing.

  Which is why great care must be taken in its design and implementation.

> With the preceding in mind, how does SPF prevent a virus-infected,
> hijacked computer from sending abuse email?

  It doesn't.  It DOES, however, make them accountable to either the
domain used by the owner of the infected machine, or by a throw-away
spammer domain.

  IMHO, MARID (RMX, etc) is about closing a hole in SMTP, which says
"messages MUST be accepted for delivery or bounced", but it makes no
provisions for ensuring that the message CAN be bounced.  One
intention behind all of these related ideas is to provably have an
accountable entity which will accept responsibility for messages,
including bounces.

  Alan DeKok.

---

From: "Larry Seltzer" <[email-masked]>
Date: Tue, 27 Jul 2004 19:04:18 -0400

It's worth pointing out, unless I'm mistaken, that the entire endemic
population of mail worms would fail under SPF. None of them would
authenticate because they all pick MAIL FROM addresses essentially at
random and then use built-in MTAs, none of which will be registered in
any DNS. 

It would also be much harder to write one that would be successful, and
the messages would actually come from where they purport to come from,
making it easier to shut down the worm. For instance, if there is a
throwaway domain involved it would be quickly shut down.

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 28 Jul 2004 22:04:07 +0200

> random and then use built-in MTAs, none of which will be registered in

People have domains and use them. Modern viruses contruct new
sender/receiver address pairs by randomly mixing user and domain
parts of addresses they find anywhere on the infected host.

Only the DE zone has as of now 7,788,391 second level domains. Today
(21:52 GMT+2) there were 2038 new registrations.
Do you really seriously think that the mechanisms developed by this
group during the last five months will be deployed by a significant
part of the existing domains within the next 5 years?

I think it will take a really long time before the first virus or
worm will be rejected at SMTP level because of SPF or any similar
method and if it can't be caught before the DATA command it doesn't
make a difference, because then the message will be received and it
is probably cheaper to let the virus scanner catch it instead of
cruising the DNS, collect records and feed all this to a spam filter
for evaluation that classifies it then to a "maybe spam" folder, IF
the sender domain has deployed SPF or similar methods at all.

But as Phillip wrote the train is on the way and we'll see how many
will jump on it and how many will jump off and how many won't simply
care at all.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

---

From: Meng Weng Wong <[email-masked]>
Date: Wed, 28 Jul 2004 17:35:30 -0400

On Wed, Jul 28, 2004 at 10:04:07PM +0200, Markus Stumpf wrote:
| 
| I think it will take a really long time before the first virus or
| worm will be rejected at SMTP level because of SPF or any similar
| method and if it can't be caught before the DATA command it doesn't
| make a difference, because then the message will be received and it

2004-07-27 18:13:07 : SPF fail: sender=qgcyvotmbd%40topmail.de&ip=69.166.143.181, domain of [email-masked] does not designate 69.166.143.181 as permitted sender
2004-07-27 18:15:48 : SPF neutral: sender=mhtuuldnvh%40hotmail.com&ip=207.8.226.3, Microsoft Caller-ID for Email record at _ep.hotmail.com
2004-07-27 18:52:38 : SPF neutral: sender=bernardcallaway%40hotmail.com&ip=24.218.254.106, Microsoft Caller-ID for Email record at _ep.hotmail.com
2004-07-27 19:42:14 : SPF neutral: sender=gkskeocnfdfd%40hotmail.com&ip=218.155.37.165, Microsoft Caller-ID for Email record at _ep.hotmail.com
2004-07-27 21:23:50 : SPF neutral: sender=vgrove_ay%40aol.com&ip=208.58.1.194, 208.58.1.194 is neither permitted nor denied by domain of [email-masked]
2004-07-27 22:14:09 : SPF fail: sender=khathi%40yahoo.com&ip=208.210.124.70, explicit fallback found: yahoo.com defines v=spf1 ptr -all
2004-07-27 22:33:49 : SPF fail: sender=noreply%40dumbo.pobox.com&ip=207.93.212.56, domain of [email-masked] does not designate 207.93.212.56 as permitted sender
2004-07-27 22:33:49 : SPF fail: sender=noreply%40dumbo.pobox.com&ip=207.93.212.56, domain of [email-masked] does not designate 207.93.212.56 as permitted sender
2004-07-27 22:33:57 : SPF neutral: sender=ub6s3au%40hotmail.com&ip=207.8.226.2, Microsoft Caller-ID for Email record at _ep.hotmail.com
2004-07-27 23:22:31 : SPF fail: sender=obzipbvs%40yahoo.com&ip=208.210.124.73, explicit fallback found: yahoo.com defines v=spf1 ptr -all
2004-07-27 23:50:13 : SPF neutral: sender=kmobley_qo%40aol.com&ip=208.210.124.70, 208.210.124.70 is neither permitted nor denied by domain of [email-masked]
2004-07-27 23:57:47 : SPF fail: sender=lkling146%40yahoo.com&ip=208.58.1.198, explicit fallback found: yahoo.com defines v=spf1 ptr -all
2004-07-27 23:57:47 : SPF fail: sender=mandynsl%40yahoo.com&ip=208.58.1.198, explicit fallback found: yahoo.com defines v=spf1 ptr -all
2004-07-27 23:58:05 : SPF neutral: sender=soonyee_wong%40hotmail.com&ip=219.94.101.106, Microsoft Caller-ID for Email record at _ep.hotmail.com
2004-07-28 00:44:12 : SPF fail: sender=spf-discuss%40v2.listbox.com&ip=82.77.64.5, domain of [email-masked] does not designate 82.77.64.5 as permitted sender
2004-07-28 00:51:26 : SPF fail: sender=ffwypcwtsu%40uol.com.br&ip=222.99.96.24, domain of [email-masked] does not designate 222.99.96.24 as permitted sender
2004-07-28 00:56:32 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=166.153.177.169, domain of [email-masked] does not designate 166.153.177.169 as permitted sender
2004-07-28 00:56:34 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=166.153.177.169, domain of [email-masked] does not designate 166.153.177.169 as permitted sender
2004-07-28 01:11:24 : SPF fail: sender=noreply%40dumbo.pobox.com&ip=193.96.40.29, domain of [email-masked] does not designate 193.96.40.29 as permitted sender
2004-07-28 01:11:24 : SPF fail: sender=noreply%40dumbo.pobox.com&ip=193.96.40.29, domain of [email-masked] does not designate 193.96.40.29 as permitted sender
2004-07-28 01:23:36 : SPF fail: sender=caminul_1%40yahoo.com&ip=82.137.16.154, explicit fallback found: yahoo.com defines v=spf1 ptr -all
2004-07-28 01:25:46 : SPF neutral: sender=ryan_hue%40hotmail.com&ip=219.94.101.106, Microsoft Caller-ID for Email record at _ep.hotmail.com
2004-07-28 01:34:41 : SPF fail: sender=ham_yu%40yahoo.com&ip=219.94.101.106, explicit fallback found: yahoo.com defines v=spf1 ptr -all
2004-07-28 01:56:25 : SPF neutral: sender=irene_lhl%40hotmail.com&ip=208.58.1.198, Microsoft Caller-ID for Email record at _ep.hotmail.com
2004-07-28 02:07:07 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=217.226.127.165, domain of [email-masked] does not designate 217.226.127.165 as permitted sender
2004-07-28 02:07:08 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=217.226.127.165, domain of [email-masked] does not designate 217.226.127.165 as permitted sender
2004-07-28 02:08:24 : SPF neutral: sender=kinetik_ang%40hotmail.com&ip=219.94.101.106, Microsoft Caller-ID for Email record at _ep.hotmail.com
2004-07-28 02:20:52 : SPF neutral: sender=CEFYZJXBS%40hotmail.com&ip=207.8.226.3, Microsoft Caller-ID for Email record at _ep.hotmail.com
2004-07-28 02:42:16 : SPF fail: sender=nsjptr%40yahoo.com&ip=222.117.216.227, explicit fallback found: yahoo.com defines v=spf1 ptr -all
2004-07-28 02:45:51 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=217.165.80.205, domain of [email-masked] does not designate 217.165.80.205 as permitted sender
2004-07-28 02:45:53 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=217.165.80.205, domain of [email-masked] does not designate 217.165.80.205 as permitted sender
2004-07-28 03:06:13 : SPF fail: sender=noreply%40dumbo.pobox.com&ip=166.180.38.10, domain of [email-masked] does not designate 166.180.38.10 as permitted sender
2004-07-28 03:06:22 : SPF fail: sender=noreply%40dumbo.pobox.com&ip=166.180.38.10, domain of [email-masked] does not designate 166.180.38.10 as permitted sender
2004-07-28 03:15:01 : SPF fail: sender=maxdu_de_varos%40yahoo.com&ip=219.94.101.106, explicit fallback found: yahoo.com defines v=spf1 ptr -all
2004-07-28 03:33:09 : SPF neutral: sender=melody_holliday_gl%40hotmail.com&ip=208.58.1.193, Microsoft Caller-ID for Email record at _ep.hotmail.com
2004-07-28 03:38:41 : SPF neutral: sender=dkghs%40hotmail.com&ip=61.248.94.112, Microsoft Caller-ID for Email record at _ep.hotmail.com
2004-07-28 03:38:44 : SPF neutral: sender=dkghs%40hotmail.com&ip=61.248.94.112, 61.248.94.112 is neither permitted nor denied by domain of [email-masked]
2004-07-28 03:57:31 : SPF neutral: sender=leison%40hotmail.com&ip=211.172.109.21, Microsoft Caller-ID for Email record at _ep.hotmail.com
2004-07-28 03:57:39 : SPF fail: sender=alexandr%40cedex.net&ip=211.178.13.133, domain of [email-masked] does not designate 211.178.13.133 as permitted sender
2004-07-28 04:01:25 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=203.200.26.134, domain of [email-masked] does not designate 203.200.26.134 as permitted sender
2004-07-28 04:01:59 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=203.200.26.134, domain of [email-masked] does not designate 203.200.26.134 as permitted sender
2004-07-28 04:02:19 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=209.157.48.1, domain of [email-masked] does not designate 209.157.48.1 as permitted sender
2004-07-28 04:18:22 : SPF fail: sender=ogdnx%40yahoo.com&ip=207.8.226.6, explicit fallback found: yahoo.com defines v=spf1 ptr -all
2004-07-28 04:32:51 : SPF neutral: sender=nicoleycy%40hotmail.com&ip=208.58.1.193, Microsoft Caller-ID for Email record at _ep.hotmail.com
2004-07-28 04:33:03 : SPF neutral: sender=taifei%40hotmail.com&ip=219.94.101.106, Microsoft Caller-ID for Email record at _ep.hotmail.com
2004-07-28 04:50:56 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=195.171.135.222, domain of [email-masked] does not designate 195.171.135.222 as permitted sender
2004-07-28 04:50:57 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=195.171.135.222, domain of [email-masked] does not designate 195.171.135.222 as permitted sender
2004-07-28 04:58:53 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=80.90.7.24, domain of [email-masked] does not designate 80.90.7.24 as permitted sender
2004-07-28 04:58:54 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=80.90.7.24, domain of [email-masked] does not designate 80.90.7.24 as permitted sender
2004-07-28 04:59:05 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=193.41.195.11, domain of [email-masked] does not designate 193.41.195.11 as permitted sender
2004-07-28 05:13:24 : SPF fail: sender=noreply%40dumbo.pobox.com&ip=213.218.232.88, domain of [email-masked] does not designate 213.218.232.88 as permitted sender
2004-07-28 05:13:27 : SPF fail: sender=noreply%40dumbo.pobox.com&ip=213.218.232.88, domain of [email-masked] does not designate 213.218.232.88 as permitted sender
2004-07-28 05:13:30 : SPF fail: sender=noreply%40dumbo.pobox.com&ip=81.6.232.50, domain of [email-masked] does not designate 81.6.232.50 as permitted sender
2004-07-28 05:34:20 : SPF fail: sender=xyfxinqcygh%40yahoo.com&ip=207.8.226.2, explicit fallback found: yahoo.com defines v=spf1 ptr -all
2004-07-28 05:42:12 : SPF neutral: sender=jmorvw%40aol.com&ip=208.210.124.70, 208.210.124.70 is neither permitted nor denied by domain of [email-masked]
2004-07-28 06:11:39 : SPF neutral: sender=lfchiow%40hotmail.com&ip=208.58.1.194, Microsoft Caller-ID for Email record at _ep.hotmail.com
2004-07-28 06:11:45 : SPF fail: sender=shiauchyn%40yahoo.com&ip=219.94.101.106, explicit fallback found: yahoo.com defines v=spf1 ptr -all
2004-07-28 06:25:19 : SPF fail: sender=fcyeo2002%40yahoo.com&ip=219.94.101.106, explicit fallback found: yahoo.com defines v=spf1 ptr -all
2004-07-28 06:37:19 : SPF neutral: sender=wmxalgfhixfe%40aol.com&ip=208.58.1.193, 208.58.1.193 is neither permitted nor denied by domain of [email-masked]
2004-07-28 06:58:13 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=130.89.66.133, domain of [email-masked] does not designate 130.89.66.133 as permitted sender
2004-07-28 06:58:13 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=130.89.66.133, domain of [email-masked] does not designate 130.89.66.133 as permitted sender
2004-07-28 07:25:54 : SPF fail: sender=cjvvzmbsapss%40yahoo.com&ip=208.210.124.73, explicit fallback found: yahoo.com defines v=spf1 ptr -all
2004-07-28 07:25:54 : SPF fail: sender=cjvvzmbsapss%40yahoo.com&ip=208.210.124.73, domain of [email-masked] does not designate 208.210.124.73 as permitted sender
2004-07-28 08:05:14 : SPF fail: sender=andrei0241%40yahoo.com&ip=82.137.38.58, explicit fallback found: yahoo.com defines v=spf1 ptr -all
2004-07-28 08:07:22 : SPF fail: sender=traschke%40yahoo.com&ip=200.183.75.132, explicit fallback found: yahoo.com defines v=spf1 ptr -all
2004-07-28 08:10:08 : SPF softfail: sender=www%40mail.com&ip=80.178.80.244, transitioning domain of [email-masked] does not designate 80.178.80.244 as permitted sender
2004-07-28 08:22:39 : SPF fail: sender=202231%40dumbo.pobox.com&ip=61.31.145.12, domain of [email-masked] does not designate 61.31.145.12 as permitted sender
2004-07-28 08:22:40 : SPF fail: sender=202231%40vw.mailzone.com&ip=61.31.145.12, domain of [email-masked] does not designate 61.31.145.12 as permitted sender
2004-07-28 08:28:51 : SPF fail: sender=adah%40yahoo.com&ip=207.8.226.3, explicit fallback found: yahoo.com defines v=spf1 ptr -all
2004-07-28 09:03:37 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=199.172.212.254, domain of [email-masked] does not designate 199.172.212.254 as permitted sender
2004-07-28 09:03:38 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=199.172.212.254, domain of [email-masked] does not designate 199.172.212.254 as permitted sender
2004-07-28 09:03:41 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=199.172.192.5, domain of [email-masked] does not designate 199.172.192.5 as permitted sender
		    : SPF fail: sender=zpbad%40yahoo.com&ip=208.58.1.198, explicit fallback found: yahoo.com defines v=spf1 ptr -all
2004-07-28 10:09:59 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=82.228.46.41, domain of [email-masked] does not designate 82.228.46.41 as permitted sender
2004-07-28 10:10:01 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=82.228.46.41, domain of [email-masked] does not designate 82.228.46.41 as permitted sender
2004-07-28 10:11:33 : SPF neutral: sender=utkvdmqhyamqh79598%40hotmail.com&ip=207.8.226.3, Microsoft Caller-ID for Email record at _ep.hotmail.com
2004-07-28 10:16:18 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=149.225.94.152, domain of [email-masked] does not designate 149.225.94.152 as permitted sender
2004-07-28 10:16:37 : SPF fail: sender=MAILER-DAEMON%40dumbo.pobox.com&ip=149.225.94.152, domain of [email-masked] does not designate 149.225.94.152 as permitted sender
2004-07-28 10:35:46 : SPF softfail: sender=ncqddyaodfzpxf%40bk.ru&ip=66.214.251.32, transitioning domain of [email-masked] does not designate 66.214.251.32 as permitted sender
2004-07-28 10:41:30 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=216.68.162.139, domain of [email-masked] does not designate 216.68.162.139 as permitted sender
2004-07-28 10:41:30 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=216.68.162.139, domain of [email-masked] does not designate 216.68.162.139 as permitted sender
2004-07-28 10:41:51 : SPF fail: sender=noreply%40dumbo.pobox.com&ip=192.128.134.71, domain of [email-masked] does not designate 192.128.134.71 as permitted sender
2004-07-28 11:15:03 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=195.208.209.117, domain of [email-masked] does not designate 195.208.209.117 as permitted sender
2004-07-28 11:15:04 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=195.208.209.117, domain of [email-masked] does not designate 195.208.209.117 as permitted sender
2004-07-28 11:15:08 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=195.208.208.19, domain of [email-masked] does not designate 195.208.208.19 as permitted sender
2004-07-28 11:23:58 : SPF softfail: sender=ingmar%40seznam.cz&ip=207.8.226.3, transitioning domain of [email-masked] does not designate 207.8.226.3 as permitted sender
2004-07-28 12:02:06 : SPF neutral: sender=mollyoconnell_pf%40bankkadr.com.pl&ip=211.115.216.225, 211.115.216.225 is neither permitted nor denied by domain of [email-masked]
2004-07-28 13:28:10 : SPF fail: sender=nlwrs%40yahoo.com&ip=208.58.1.198, explicit fallback found: yahoo.com defines v=spf1 ptr -all
2004-07-28 13:52:07 : SPF neutral: sender=velasquezmario%40hotmail.com&ip=24.218.254.106, Microsoft Caller-ID for Email record at _ep.hotmail.com
2004-07-28 13:53:16 : SPF neutral: sender=fantastic34%40hotmail.com&ip=24.218.254.106, Microsoft Caller-ID for Email record at _ep.hotmail.com
2004-07-28 14:14:47 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=146.9.22.127, domain of [email-masked] does not designate 146.9.22.127 as permitted sender
2004-07-28 14:14:54 : SPF fail: sender=postmaster%40dumbo.pobox.com&ip=146.9.22.127, domain of [email-masked] does not designate 146.9.22.127 as permitted sender

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 28 Jul 2004 17:56:50 -0400

> part of the existing domains within the next 5 years?

  Are there any methods that *will* be deployed by a significant part
of the existing domains within the next 5 years?

  If so, what are they?

  If not, what should we do instead of MARID?

  Alan DeKok.

---

From: Michel Bouissou <[email-masked]>
Date: Thu, 29 Jul 2004 00:53:12 +0200

Le mercredi 28 Juillet 2004 23:35, Meng Weng Wong a écrit :
> 2004-07-27 18:13:07 : SPF fail:
> sender=qgcyvotmbd%40topmail.de&ip=69.166.143.181, domain of
> [email-masked] does not designate 69.166.143.181 as permitted sender

I have a couple as well on my humble little machine ;-) and keeps getting more 
everyday : the damned thing works :-))

Plain ole' good classic SPF ;-)

Résultats SPF sur totor.bouissou.net le Jul 27 :

Jul 27 04:02:42 totor postfix/smtpd[30484]: NOQUEUE: reject: RCPT from 
unknown[211.139.120.2]: 550 <[email-masked]>: Sender address rejected: 
Violation SPF: Mail de [email-masked] doit etre transmis depuis serveur 
approuve pour domaine 12inch.com. Contactez administrateur de 12inch.com pour 
plus d'info, ou voyez 
http://spf.pobox.com/why.html?sender=alien%4012inch.com&ip=211.139.120.2&receiver=totor.bouissou.net; 
from=<[email-masked]> to=<[email-masked]> proto=ESMTP 
helo=<bouissou.net>

Jul 27 05:53:14 totor postfix/smtpd[8932]: NOQUEUE: reject: RCPT from 
unknown[200.37.86.106]: 550 <[email-masked]>: Sender address rejected: 
Violation SPF: Mail de [email-masked] doit etre transmis depuis serveur 
approuve pour domaine bouissou.net. Contactez administrateur de bouissou.net 
pour plus d'info, ou voyez 
http://spf.pobox.com/why.html?sender=dude%40bouissou.net&ip=200.37.86.106&receiver=totor.bouissou.net; 
from=<[email-masked]> to=<[email-masked]> proto=SMTP 
helo=<host-200-4-225-106.cablenet>

Jul 27 22:49:46 totor postfix/smtpd[22624]: NOQUEUE: reject: RCPT from 
lns-vlq-8-82-254-216-91.adsl.proxad.net[82.254.216.91]: 550 
<[email-masked]>: Sender address rejected: Violation SPF: Mail de 
[email-masked] doit etre transmis depuis serveur approuve pour domaine 
irislink.com. Contactez administrateur de irislink.com pour plus d'info, ou 
voyez 
http://spf.pobox.com/why.html?sender=support%40irislink.com&ip=82.254.216.91&receiver=totor.bouissou.net; 
from=<[email-masked]> to=<[email-masked]> proto=ESMTP 
helo=<bouissou.net>

Résultats SPF sur totor.bouissou.net le Jul 26 :

Jul 26 05:46:43 totor postfix/smtpd[5465]: NOQUEUE: reject: RCPT from 
pD9EB514A.dip0.t-ipconnect.de[217.235.81.74]: 550 <[email-masked]>: 
Sender address rejected: Violation SPF: Mail de [email-masked] doit 
etre transmis depuis serveur approuve pour domaine email.ro. Contactez 
administrateur de email.ro pour plus d'info, ou voyez 
http://spf.pobox.com/why.html?sender=tnorsrvrgvui%40email.ro&ip=217.235.81.74&receiver=totor.bouissou.net; 
from=<[email-masked]> to=<[email-masked]> proto=SMTP 
helo=<pD9EB514A.dip0.t-ipconnect.de>

Jul 26 17:22:44 totor postfix/smtpd[6960]: NOQUEUE: reject: RCPT from 
unknown[195.121.4.119]: 550 <[email-masked]>: Sender address 
rejected: Violation SPF: Mail de [email-masked] doit etre 
transmis depuis serveur approuve pour domaine arboi.fr.eu.org. Contactez 
administrateur de arboi.fr.eu.org pour plus d'info, ou voyez 
http://spf.pobox.com/why.html?sender=MAILER-DAEMON%40arboi.fr.eu.org&ip=195.121.4.119&receiver=totor.bouissou.net; 
from=<[email-masked]> to=<[email-masked]> 
proto=ESMTP helo=<arboi.fr.eu.org>

-- 
Michel Bouissou <[email-masked]> OpenPGP ID 0xDDE8AC6E

---

From: Jim Fenton <[email-masked]>
Date: Thu, 29 Jul 2004 08:10:50 -0700

>the sender domain has deployed SPF or similar methods at all.

The message isn't accepted until the DATA command is accepted, at the end of the message.  While the receiving domain has to provide bandwidth to receive at least part of the message, it can still reject the message (and doesn't have to provide storage for it) any time before the "OK".  It can, potentially, tear down the TCP connection after receiving the relevant headers if it wants.

-Jim

---

From: "Carl S. Gutekunst" <[email-masked]>
Date: Thu, 29 Jul 2004 11:07:47 -0700

Jim Fenton wrote:

> The message isn't accepted until the DATA command is accepted, at the 
> end of the message. While the receiving domain has to provide 
> bandwidth to receive at least part of the message, it can still reject 
> the message (and doesn't have to provide storage for it) any time 
> before the "OK". It can, potentially, tear down the TCP connection 
> after receiving the relevant headers if it wants.

Just splitting hairs here:

If the server simply tears down the connection, the client MTA will 
handle it the same as a 421 error, and resend the message (and resend 
it, and resend it... for three days). If you really want to reject a 
message after a 354 response, then you'll have to swallow the whole 
message and send a 55x code in response to the dot. Then you'll have to 
hope that the client MTA does the Right Thing when it receives a 55x at 
that point -- some don't.

<csg>

---

From: Dean Anderson <[email-masked]>
Date: Fri, 30 Jul 2004 19:18:11 -0400 (EDT)

> domain used by the owner of the infected machine, or by a throw-away

Which does what?  AOL and MSN and other large domain operators already
have tens of thousands of virus infected machines sending junk. Mostly,
those machines are connecting directly. It wouldn't make any difference if 
they send mail through AOL's mail servers instead, using a forged (or 
accurate) <user>@aol.com From: address.  

Major residential providers have already blocked outgoing SMTP, which 
forces the clients to the providers relays. This hasn't stopped abuse.  
Essentially, all SPF is a way to force everyone to block outbound SMTP 
except from their relays.  But that won't stop abuse either.

> provisions for ensuring that the message CAN be bounced.  

Ahh. Still trying to contact the abuser.  Well, forget it. There is no way
to do that.  You aren't dealing with a commerical operator practically any
of the time. You are dealing with a one-way, virus-operated mail client
whose purpose is not two-way communication but sending one-way abuse. 
"Bounce" has no meaning to such a client, and there is no point in trying 
to "bounce" anything to them.

> One intention behind all of these related ideas is to provably have an

This is impossible. You already have an accountable entity: the IP address
delegate.  Evidently, they either aren't responsible enough or aren't
responsive enough to halt abuse. They are often the same entity as the
domain delegate:  AOL owns the IP address, AOL owns the aol.com domain.  
You haven't "proven" anyone's accountability.

Information theory demonstrates conclusively that that you can't stop
abuse by protocol.  There is an abuse problem: More specifically, there is
a Virus problem. The virus operator doesn't care about the domain owner
any more than they care about the machine owner, or the IP address owner.
The domain owner has no more control over the infected machine than the IP
address owner.  That being so, sender verification is pointless.

It costs us millions, perhaps billions of dollars to go through these 
gyrations. There are millions of domains, for which tens or hundreds of 
records will have to be added to DNS. That expands the distributed DNS 
database by tens or hundreds of millions of records.  Operations like 
register.com and DNS operators have to alter their applications to store 
and update the records.  Millions of dollars are spent doing this.

The virus operator has to add a couple lines of code to his program to use
the infected machines legitimate email address, and use psyBNC to
distibute this to his virus stable.  Time to implement: few days. Cost: 0.

I am sorry to be critical, but this was why the DNSEXT group rejected RMX.  
One has to wonder why it was brought up again without more critical
analysis.

If you want to stop abuse, then forget about SPF, and work on viruses.  
Thats the problem and unless you address that problem, you are just
playing with playdoh: Squeezing it just changes the shape, but not the
mass. It doesn't go away, it just morphs.  But making it change shape
costs the good guys money and the bad guys nothing.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Fri, 30 Jul 2004 19:48:11 -0400 (EDT)

>   Which is why great care must be taken in its design and implementation.

Well, it is interesting that the major corporate sponsors of SPF and RMX
aren't against spam, but only spam not originating from them or not paying
them. It is also in their interest to prevent outsourcing, so that they
get the whole service package.  I find it difficult to believe they are
really taking great care to make sure it doesn't break outsourcing.  

But, great care or not, SPF does make it pretty much impossible to
outsource. You need a record for each mailserver. It is reported that it
is only possible to have 18 root Nameservers because that is the maximum
that can fit in a DNS packet. The TXT record is not as efficient, but I
don't have any exact number for the maximum number of servers will be
possilbe.  But it will probably approximately 18.  This limits the number
of servers that can be outsourced, or even internally used.  Lets try a
more concrete example:  At present, I believe that AOL has a number of 4
inbound MX's and a larger number of outbound servers. I don't have any
special knowledge of AOL internal operations, but I think they have each
user server send outbound email directly. Presumably, they have more than
18 outbound servers.

Then there are deployment issues. Besides the cost of adding the SPF
records to tens of millions of domains and the complications of just
getting that done, there are other complications:

DNS protocols present provide for TCP connections to handle packets larger
than 512 bytes. However, many server implementations still don't support
TCP, or don't support it properly. This leaves a large number of domains
that won't be able to work with SPF, and it means that a lot of mail will
just mysteriously fail depending on the originating site's SPF
configuration.

Then there are domains that will have to re-architect their mail
architecture so that all internal mail is first sent through an "SPF
approved" server. Many systems are configured to send outgoing mail
directly.  This creates more burden on the outgoing mailservers. Some
sites will need to buy new servers as a result. This will be significant
and possibly devastating for some.

Then there are issues getting SPF deployed in mail servers. Not everyone
runs "Debian stable" with automatic update.  For most, this will mean they
will have to upgrade software sooner than they expected.  So it will be a
long while before SPF has any benefit for many sites.

This is just scratching the surface.  At each step, there are even more
complications that could go wrong, and cost money or disrupt mail.

Again: abuser takes a few days at most to adapt. Total cost to abuse: $0.

		--Dean

---

From: Michel Bouissou <[email-masked]>
Date: Sat, 31 Jul 2004 02:27:17 +0200

Le samedi 31 Juillet 2004 01:48, Dean Anderson a écrit :
> them.

For sure, they are quite against "illegitimate spam" that dilutes their 
"legitimate corporate advertising" ;-)

> of servers that can be outsourced, or even internally used.

I understand from this that you don't understand at all the way that an SPF 
record works. Please Read The Fu^Hine Documentation...

> getting that done,

Tens of millions of domains are currently supposed to manage and maintain 
their DNS records, and each domain, even really "basic" needs at least 4 
records in DNS, typically
- 1 SOA
- 2 DNS
- 1 MX or more
- 1 A for the MX (if in the same domain)
- Generally one "www.thing.org" that points to the web server

And of course the bigger the domain, the greater the number of machines and 
"A" records in DNS.

Adding SPF to a domain is adding ONE TXT record to the domain.
It is also wise to add one for each "A" record in the domain.

Setting this up is a matter of minutes for one domain, so every domain that 
has an admin maintaining it should be able to afford it -- and those who do 
that externally actually pay for a service, don't they ?

Expressing this in "billion dollars" is like trying to evaluate the time that 
I spent scratching my head today, multiply this by the number of inhabitants 
in my country, and calculate from there how many billion dollars are lost 
each month from work time lost scratching one's head...

> there are other complications: 
>
> TCP, or don't support it properly.

If they don't, they should. If broken, fix.

Well, you're depicting a whole nightmare in which it seems that you much 
exagerate the problems that implementing SPF causes. Remember that more than 
22,000 domains using SPF are known as of today, and some suppose the actual 
total figure is about 100,000 or more.

Ne auderis delere orbem rigidum meum!

---

From: Dean Anderson <[email-masked]>
Date: Fri, 30 Jul 2004 21:46:45 -0400 (EDT)

> record works. Please Read The Fu^Hine Documentation...

I read 
http://www.ietf.org/internet-drafts/draft-ietf-marid-protocol-00.txt

The example records seem a lot shorter than 512 bytes. But that limit
comes pretty quick. I seem to recall that HESIOD records could quickly eat
that up.  Wait, wasn't that one of the reasons why we thought that TCP was
necessary in the first place?

In this respect, RMX was probably better. But it was still rejected 
because 

   It didn't solve the problem and was therefore gratuitous.

> - Generally one "www.thing.org" that points to the web server

The vast majority of domains have 5 records. So, we are talking about
increase the global dns database of 20 percent.  And a corresponding 
increase in DNS traffic, and a corresponding increase in DNS server load.

> And of course the bigger the domain, the greater the number of machines and 

Agree. It has less impact on the large domains. 

> Setting this up is a matter of minutes for one domain

Setting anything is "a matter of minutes for one domain".  Try doing it 
for hundreds or thousands of domains. 

> , so every domain that has an admin maintaining it should be able to
> afford it -- and those who do that externally actually pay for a
> service, don't they ?

Service that doesn't include 20% increase in frivolous domain record 
maintanence: And it is ongoing maintenance. Change the IP of your 
mailservers, and lots most stuff has to change. It gets correspondingly 
more difficult to renumber.

> each month from work time lost scratching one's head...

Yes, to some extent. But that means its not a good idea to make everyone 
on the planet scratch their heads a lot. Policy analysis includes these 
sort of costs in the cost analysis. 

> If they don't, they should. If broken, fix.

Much more easilly said than done. There are complications and costs to 
doing this.

> total figure is about 100,000 or more.

22,000 out of perhaps 22 million domains?  That's less than one tenth of
one percent. I'm sure more than that use "hair growth cream".  It doesn't
matter how many use it if it doesn't work. 

"It works for me at the moment" is not a sufficiently convincing technical
analysis to spend a great deal of money and inconvenience a lot of people.  

Simply rejecting all mail with a 450 response for 5 minutes "works for
some at the moment", too. But it won't work for long, because abusers
simplely need to try again in 5 minutes, and remember for which addresses
they got a temporary error response.  Not a big problem for the abuser to
solve.  Unfortunately, making them solve it means that temporary respite
from spam that one obtains from a crashed server will go away, too. Gee
thanks. Now there is nothing to make those events less bad.  Keep shooting
us in the foot, folks. Maybe you'll hit something vital. Or maybe, you'll 
just kill something like outsourcing email, and no one will notice. 

Before something will be accepted, it needs to work for a long time. That
means that it has to do more than just break the current and past abuse
engines for a few days. It has to break them permanently. Wait,
information theory says something about that. It says you can't ever
achieve that.

So, it seems that you have to track down virus operators and put them in 
jail. 

		--Dean

---

From: Michel Bouissou <[email-masked]>
Date: Sat, 31 Jul 2004 10:47:19 +0200

> necessary in the first place?

So if this is much of a concern for you, and if you have more servers than 
what can fit on a reasonably short SPF record, then use the "exists" 
mechanism and put up an SPF record such as:

v=spf1 a:main_server.company.com mx exists:%{ir}.mailserver._spf.%{d} -all

This one fits in 75 characters, I could have made it shorter, and it allows 
defining an unlimited number of mailservers, each one with one DNS record, 
using the SPF "exists" mechanism.

> increase the global dns database of 20 percent.

The keyword here is "distributed". A company server that manages DNS for a 
company with a dozen DNS records can easily accomodate another dozen.

And if a big DNS provider that manages hundreds of thousands domains needs to 
upgrade some servers, it will make the industry happy.

> And a corresponding increase in DNS traffic, and a corresponding increase in
> DNS server load. 

False deduction. You cannot make a link between the number of records and the 
number of requests for these records. The "www." A record will be requested 
by people who want to access the domain's website, when the TXT SPF record 
will be requested by MTAs wanting to check mail pretending to come from the 
domain. You cannot deduct a ratio between those unrelated events.

Furthermore, you omit considering DNS caching. If one MTA starts receiving a 
lot of mail pretending to come from a given domain, it will have this 
domain's SPF record in its local DNS cache.

> for hundreds or thousands of domains.

If you manage a couple of domains, it's a matter of minutes. If you manage 
hundreds or thousands of domains :
1/ You are not forced to do all of them in the same day ;-)
2/ You probably have the necessary resources for scripting this according to 
your customer database
3/ If you have some kind of web interface for allowing customers to manage 
part of their DNS records (as many DNS hosting companies have), you just need 
to add one field in your web interface, and possibly an engine to generate or 
check syntax and consistency of SPF records.

> > Expressing this in "billion dollars" is like trying to evaluate the time
> > that I spent scratching my head today, multiply this by the number of
> > inhabitants in my country, and calculate from there how many billion
> > dollars are lost each month from work time lost scratching one's head...
>

Policy analysis sometimes show rather stupid, it would be worth analyzing the 
working hours lost in policy analysis ;-)

> > > DNS protocols present provide for TCP connections to handle packets
> > > larger than 512 bytes. However, many server implementations still don't
> > > support TCP, or don't support it properly.
> >

When designing a protocol, we don't have to take into consideration the fact 
that there may be a number of servers that already do not conform to 
long-date established standards.

If machines out there are DNS-broken and don't conform to the DNS standards 
that have been in place for years, it's *their* problem to fix it. Cost for 
them is their problem.

> one percent.

In 6 months, just with "word of mouth" and when SPF isn't yet defined as a 
"standard", I find this rather impressive. 22,638 is just the number or known 
(registred to http://spftools.infinitepenguins.net/register.php as of today) 
SPF-enabled domains, but registering there isn't mandatory at all, and some 
estimate that the actual figure is more than 100,000. Especially because some 
DNS / Mail hosting companies may have SPF-enabled thousands of the domains 
they manage at once, and surely didn't bother entering them all into 
http://spftools.infinitepenguins.net/register.php.

I don't know many new systems that receive such a spontaneaous massive 
adhesion from the sysadmins community, especially if they impose some kind of 
constraint and may force to rethink the outgoing mail path for the domain.

> analysis to spend a great deal of money and inconvenience a lot of people.

Well, "It works for me at the moment" ;-)

> So, it seems that you have to track down virus operators and put them in

Just do it ;-)

---

From: "Alan DeKok" <[email-masked]>
Date: Sat, 31 Jul 2004 09:52:32 -0400

Dean Anderson <[email-masked]> wrote:
> It wouldn't make any difference if they send mail through AOL's mail
> servers instead, using a forged (or accurate) <user>@aol.com From:
> address.

  Really?  I'm sure AOL would disagree.  Another 10^8 or so messages a
day passing through their system would make them take notice.

> except from their relays.

  That's exactly wrong.  SPF is a way of enabling the recipient to
tell if a message was from an outgoing MTA or not.  Blocking outbound
SMTP is orthoganal.

> Ahh. Still trying to contact the abuser.

  Uh, no.  It's a way of finding if there is a responsible party for
the message.  For many spam & virus messages, the alleged domain can
refuse to accept responsibility, and the recipient can discard the message.

> You haven't "proven" anyone's accountability.

  People sell IP conectivity with few restrictions.  Someone sending
2-3 spams a day from an IP isn't much of a problem so far as the IP
owner is concerned.  But a fraud artist claiming association with your
business name *is* a big deal.

> address owner.  That being so, sender verification is pointless.

  Nonsense.  The domain owner controls his domain name.  If the
infected machine uses his name, he can deny responsibility for that
message.

> One has to wonder why it was brought up again without more critical

  Some people think it's useful.

  Alan DeKok.