Subject: Re: How is SPF different from RMX?

From: Dean Anderson <[email-masked]>
Date: Mon, 2 Aug 2004 02:25:46 -0400 (EDT)

On Sat, 31 Jul 2004, Michel Bouissou wrote:

> Le samedi 31 Juillet 2004 03:46, Dean Anderson a écrit :
> >
> > 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?
> 
> 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.

That sounds very much like a DNS whitelist.  I already have that. Don't 
need a special protocol for that.

Ok. Lets take a likely scenario:  There are roughly 30000 ISPs in the
world. Lets suppose that either for good business or for anti-trust
requirements, they all have to all allow their customers to outsource
parts of their email system to the other ISPs.  So, each ISP has to allow
the servers for each other ISP to send "from:" its domain.

How well does that work?  Every ISP that is "trusted" can forge mail for
the other ISPs. That doesn't really solve any problem at all.  I'll
neglect the impracticality of maintaining the records for each server for
each of those 30,000 ISPs, and the problem of distributing and updating
that database. (Hosts.txt we missed you, or maybe we make root servers
service a special zone of the ISPs mailservers, or maybe we make the root
server operators operate a parallel set of servers for this zone)

Even if you trust no other ISPs, all users at that ISP can still be able
to forge mail from other users at that ISP.  That doesn't really solve any
problem either.

Oh, wait. There's one more thing: They might want to allow the customer to
connect directly from the IP addressed assigned to them by the other ISP.  
So, not only do they need to allow every ISP's mail servers, they need to
allow every IP address. So any IP address forge email from any ISP. Thats
actually how it is now at many ISPs.  Now we've got nothing but useless
DNS requests.  So, what good is SPF?

That just assuming that everyone uses SPF. That isn't likely to be the
case. SPF has to be used by both the sender and the recipient. The sender
has to have an "approved" mail server, and the recipient has to reject
mail that isn't "approved". If either the sender or the recipient do not
use SPF, then email is either blocked, or forgeable.  Most places won't
want it blocked. Though there are certain radicals who do feel it's ok to
block legitimate email, the vast majority of sites don't feel this way.
The most likely scenario is that to some degree of market penetration,
people will put in SPF records, but few or none will reject mail based on
their absence. [cart/horse].  But whatever the case, even if there is full
deployment worldwide, the abuser can still send abuse.  Its just a waste
of time and money.

I was thinking that one of the objectives is to have a "responsible
entity". Possibly a worthy objective, I am reminded of the cartoon about
having to be this high to storm the castle.  We might as well have an RFC
that says you must be 18 to hack into computers.  It would also be useless
in stopping abuse.

But even if we ignore that all these problems exist, and just take it as a
given that everything works as envisioned:  No users can forge the email
from other users.  Abusers wouldn't care. And it still wouldn't stop
abuse.  So, I'm not sure why we care that they _can_ forge email
addresses.  How does stopping that change anything?  I've never assumed 
that the from: address meant anything.  Ahh. I think now we are getting 
somewhere. People who make false assumptions (like the from: address means 
something) want to change the "silly net" to make their false assumptions 
true.  Rob Austein has been trying to do this since 1986, when he didn't 
want to put numeric addresses in the Recieved: header.  

> > The vast majority of domains have 5 records. So, we are talking about
> > 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.

Really?  There is an increase both in database size, and in DNS load. And
it means that as you add new domains, that they are each larger,
incrementally.  That's pretty significant, pretty fast.  It doesn't take
too long before a large domain hoster can't handle all the DNS traffic.  
They are already on the edge, many of them. So then they need to upgrade
servers, local networks, wide area networks, etc.

I am always amazed at the "gee, it worked for me on my littly one-host 
network. It must work for everyone else. Testing done."
 
> And if a big DNS provider that manages hundreds of thousands domains needs to 
> upgrade some servers, it will make the industry happy.

Not the ISP industry. Not the DNS industry. What industry are you talking 
about?

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

Uhh, Yes you can. 

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

You don't need a ratio of www traffic to Mail traffic. I referred to no
ratio.  

The more records you have to request, the more traffic you'll have.

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

I overlooked the cache effects.  The more records you have to request, the
more records will get flushed from the cache to make room for them, and
the more often they will need to be requested again.  The effect on DNS
caches is also negative.  This hurts performance across the board.

> > > 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.
> 
> If you manage a couple of domains, it's a matter of minutes. If you manage 
> hundreds or thousands of domains :

I do.

> 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

I don't. Neither does register.com. They (and we) will have to create all 
that.

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

Some do, some don't.

Changing it isn't cheap.  If we are going to change it, it better be 
worthwhile. I know I and a lot of other people have just about had it with 
frivolous "anti-spam" changes.  I could go into spam history since 1994, 
but I think everyone here knows full well that we've been told "just do 
this one thing, and it'll all go away". We've done quite a few of those 
things, and spent a lot of money doing it, and it hasn't gone away, and it 
was obvious why those things would fail back then.

You've had your opportunity for the "Just try it, please" song and dance. 
Several times over.

> > Much more easilly said than done. There are complications and costs to
> > doing this.
> 
> 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.

Designing? No. Deploying? Yes.  Don't expect quick deployment of something
that requires a lot of old software to be upgraded.  If you want to design
SPF with the intention that it will be deployed over the next 10 years,
thats different. I'm hearing people say that they want to deploy it in the
next 8 months.

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

They won't run SPF, or won't be able to accept mail from SPF users. Its
your problem.

> > 22,000 out of perhaps 22 million domains?  That's less than one tenth of
> > 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.

I wouldn't say that's "massive". There are probably more SMTP AUTH and
SMTP SSL servers than that.  There are some 400,000 open relays.

However, I neglected to mention one thing: Such numbers are often
meaningless for testing and reliability reasons. For example, a voting
machine maker has recently said their machines are trustworthy because in
tests, they've had 10,000 voting transactions entered and the machine
counted them correctly. OF COURSE it counts correctly when no one is
trying to tamper with it. I'd say that ought to be a given. Any high
school freshman should be able to write a "voting" program that counts
correctly. (though I guess the real machines did actually have some
counting problems)

Similarly, 20000 trivial users doesn't mean that the entire internet can 
make use of it.

> 
> > "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.
> 
> Well, "It works for me at the moment" ;-)
> 
> > So, it seems that you have to track down virus operators and put them in
> > jail.
> 
> Just do it ;-)

Spend your efforts getting more law enforcement attention to this problem,
and it will happen.  Presently, reporting virus infections or cracking to
the Feds results only in dirty looks about the paperwork they have to fill
out before doing nothing. Unless a lot of money is involved. 

Well, have fun storming the castle. Information theory will prevail once
again.  Abuse can't be stopped by protocol changes. But, I can see that
you are not going to be convinced any more than your dozen predecessors
were.  Probably be another dozen schemes after this one fails.

		--Dean

---

From: Graham Murray <[email-masked]>
Date: Mon, 02 Aug 2004 08:28:25 +0100

> DNS requests.  So, what good is SPF?

SPF is still good for those (many) of us who do not use a
[email-masked]' or [email-masked]' style address and even more
so for those of us who also run our own mail servers. It enables us to
state 'if the email was not sent from one of these addresses, then it
is a forgery and not from us'. I agree that it (and many of the other
schemes being examined by MARID) does not offer quite so much
protection for people who use [email-masked]' style addresses or those
who have to send mail via their ISP's servers. But if people are
concerned about forgery then they can register their own domain and
publish appropriately narrow SPF records.

---

From: Michel Bouissou <[email-masked]>
Date: Mon, 2 Aug 2004 09:37:41 +0200

> the servers for each other ISP to send "from:" its domain.

Really ? So there is no point at all publishing SPF records or Sender-ID 
records or whatever for them, except for publishing the list of their own 
servers maybe, so their own servers would get a "pass" and others a 
"neutral". But this basically allows the planet to forge MAIL FROM bearing 
their domain name.

If they do publish an SPF record, it should look more or less like the current 
AOL SPF record:

aol.com text "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 
ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 
ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all"

However, when most domains will publish more restrictive SPF records, these 
permissive domains will become the preferred source for email forgeries, so 
many sysadmins will setup local policies submitting MAIL FROM permissive 
domains to extra and extreme antispam checks, or treating a "neutral" as a 
"fail" for aol.com for example. This is surely what I will do myself.

We can expect these permissive domains to shift progressively from "?all" to 
"~all", then "-all"

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

---

From: "Andrew W. Donoho" <[email-masked]>
Date: Mon, 2 Aug 2004 06:58:13 -0700

> to forge mail from other users at that ISP.  That doesn't really solve 

Folks,

	I'm a newbie lurker here so take my comments with a grain of salt.

	Since Mr. Anderson uses the word trust above, he has entered the realm 
of security considerations.

	It seems to me that spam is a security problem. The very first step in 
security is identification. SPF/SenderID looks like it implements the 
very stable three party security pattern. The sender is possibly a 
valid sender. The receiver does not know who the sender is or if they 
are authorized to send mail. Therefore, with SPF/SenderID, the receiver 
can ask a possibly independent IP address for another piece of evidence 
that identifies the sender IP as authorized to send mail for a domain. 
Like all good security, this is just one of the many mechanisms that 
both the sender and receiver will use to ensure valid transmissions. 
Other mechanisms, such as SSL/TLS or DomainKeys or S/MIME or PGP, will 
also help establish identification. SPF/SenderID, by helping defend 
brand identity, also helps stop something with financial consequences - 
phishing.

	The debate here seems to center around the cost/benefit ratio. Those 
of us who know that we cannot depend upon the authorities to defend our 
brand and reputation and must do it ourselves want to start enhancing 
the SMTP protocols to allow this to happen. Those of us who have built 
businesses that exploit current design features of SMTP that are at 
risk due to these changes understandably object to these changes. This 
debate cannot be resolved using technical issues, the basis of 
traditional IETF decision making. These are business concerns. As such, 
we should probably focus upon enabling this capability and letting the 
market of ideas sort this out. If SPF/SenderID has business value, it 
will survive. If not, MTA authors will stop asking for SPF/SenderID 
records and the extension will die. Those vendors whose business has to 
change during this experiment, as have all of our businesses during the 
spam deluge, will bear, perhaps, an undue burden. They should speak up 
now and help minimize that burden.

	SPF/SenderID does not end spam but it provides a useful tool for, 
those of us who care about our brand identity, to help minimize spam 
and improve email as a more trusted medium. As such, it appears to be a 
useful, simple addition to my email toolkit.

Andrew

____________________________________
Andrew W. Donoho
[email-masked], PGP Key ID: 0x81D0F250
+1 (512) 453-6652 (o), +1 (512) 750-7596 (m)

---

From: "John Glube" <[email-masked]>
Date: Mon, 2 Aug 2004 11:05:51 -0400

The basic premise behind's Dean position as to why SPF is a
waste of time, is that we don't have a UBE problem, but
rather a problem with viruses.

I would beg to differ and suggest we have a problem with
fraudulent email, UBE volumes and viruses.

Published filtering company statistics seem to suggest on a
volume basis:

* Roughly 20 - 30% of email is wanted and 70 - 80% is
unwanted bulk email.

As to fraudulent email, the same statistics suggest:

* Compliance with the CAN SPAM Act of 2003 by filtered UBE
is around 1 - 2% of total volume.

This suggests there is an overall volume problem and a
significant problem with fraudlent email. 

At the same time, reports also suggest of the unwanted bulk
email, roughly 70 - 80% is coming from infected networks
and computers.

Other reports suggest to deal with spam filters, spammers
have significantly cranked up volumes resulting in a
literal tidal wave of spam.

Further, we know from a recent study by Arial Software of
over 1,600 major online publications, there is no
corelation between compliance and spam volumes. 

This study found that while over 50% of all major online
publications were not in compliance with various
requirements of the Act, less than .03% of online
publishers sent email after a subscriber opted out.

As to solving the virus problem, Dean suggests we need to
put people in jail. However, he goes on to imply unless
"lots of money is involved," the Feds won't do anything.

This is a gratitous swipe at law enforcement officials. The
vast majority of whom, from investigators to prosecutors
take their duties and responsibilities quite seriously.

As to the whole question of testing and implementation,
Sendmail recently issued a white paper which is a useful
read on their view of what is likely to transpire.

https://www.sendmail.com/smi/web_reg/sender_auth_whitepaper.jsp

At page 4 of the white paper, Sendmail notes in part:

"Timelines and Recommendations ...

"Phase 0 – Testing: The current focus is to try these
authentication systems [Sender ID and DomainKeys] with real
mail on real systems to determine if the approaches
proposed are robust enough to survive in the current
infrastructure. 

This process needs the participation of large and small
sites alike, as the goal is to exercise the many different
paths that a message might take and see how the
authentication information for those messages might break."

On the question of implementation, Sendmail suggests early
adoption will reach critical mass by end of 2004, with an
unofficial "flag day" by sometime in the last half of 2005,
signalling "the end of the old unaccountable email system."

The report also notes "AOL already verifies incoming
messages for authentication and gives those that pass
privileged processing."

Since the issuance of this report, Microsoft announced it
will begin the same processs using Sender ID as of October
1, 2004.

One quick comment.

* The present step is to carry out "robust testing." 

* As Sender ID and SUBMITTER remain experimental proposals,
it would be prudent for this WG to request outside review
of these proposals by a panel of graybeards on an expedited
basis.

John Glube
Toronto, Canada

The FTC Calls For Sender Authentication
http://www.learnsteps4profit.com/dne.html

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.729 / Virus Database: 484 - Release Date: 27/07/2004

---

From: Dean Anderson <[email-masked]>
Date: Mon, 2 Aug 2004 14:14:24 -0400 (EDT)

> significant problem with fraudlent email. 

How do you define "fraudulent email"?  I define it as mail attempting to 
defraud the reader of money. 

In a somewhat unscientific experiment, I replied to 20 Nigerian scams as 
soon as they came in with a nonchalant "How can I help?" expecting a reply 
to direct me to reveal a bank account number or some other information. 
Only one recieved a response, and that was from a person who said their 
address had been forged.  Even the apparently frauds often aren't really 
frauds.  Certainly there are frauds, but not as many as it might appear 
from the contents of the messages.

> email, roughly 70 - 80% is coming from infected networks

All networks are infected. It is just a matter of degree. Some are worse 
than others.  This suggests that there are some incorrect assumptions 
about whether networks are infected.

> literal tidal wave of spam.

I've seen this "suggested" since 1994. In truth, I've only seen this on 
usenet news, when the spammers war with the cancel bots. The users see 
thousands of messages. But this is as much the fault of the radical 
antispammers running the cancel bots as it is the spammers reposting their 
messages.  

Further, the single highest volume spams advertise Viagra. However, I have
tried to purchase viagra from a number of these spams, on the premise that
Viagra is a presription drug and I don't have a prescription and the
seller probably doesn't have a license. Thats also a federal felony, no
different from dealing cocaine or heroin. While some have led to websites,
none have led to sales or even contacts from salesmen or even fraudulent
credit card charges.  These are mostly fakes. (I say 'mostly' because
perhaps there is some example I didn't find)

> corelation between compliance and spam volumes. 

Do you have a pointer at this study?  My own experience is that very
little spam is genuinely commercial or even genuinely fraudulent--in the
sense that someone is really trying to scam money--even the obviously
fraudulent nigerian scams aren't responded to, and are really just
joe-jobs.  So I haven't seen, nor would I expect any correlation between
compliance and volume.

Though I'm not sure what you mean by a "correlation between compliance and 
spam volumes".  Do you mean that compliant emailers send more or less 
volume? Do you mean that total volume is unaffected by compliance? Please 
explain this.

> publishers sent email after a subscriber opted out.

I'll have to read that. In January, the FTC reported that 90 something 
percent of the commercial bulk emailers were partially compliant and 57% 
were fully compliant.

> take their duties and responsibilities quite seriously.

Nonsense. This is just the way it is.  The feds will tell you (they told
me) that if there aren't significant financial loses, they won't
prosecute.  The FBI is understaffed the way it is. Public interest and
funding set the priorities.  There is no "swipe" in stating what the
prosecution and investigation priorities are.  But speaking of "gratuitous
swipes" ....

> messages for authentication and gives those that pass

And has this proved beneficial to AOL users?  Will it still be beneficial
after abusers adapt to it?

> will begin the same processs using Sender ID as of October

October 1 is 59 days away.

> of these proposals by a panel of graybeards on an expedited

No doubt, a good idea.

---

From: "John Glube" <[email-masked]>
Date: Mon, 2 Aug 2004 22:18:11 -0400

Dean,

You wrote a very long message in response.

I had drafted a long reply, but then realized this whole
debate is getting far away from the purpose of this working
group which is to provide constructive review or
suggestions concerning the proposals on the table.

I will therefore limit my comments as follows:

* Go to http://www.arialsoftware.com to read the study.
Scroll to the bottom of the page.

(The study was of 1,057 companies and not 1,600 my mistake.)

* I can find no report issued in January, 2004 by the FTC
concerning compliance by bulk mailers as you suggest.

What I can find is the report made to Congress by Muris in
May, 2004 to the US Senate concerning implementation of the
CAN SPAM Act of 2003 and dealing with the spam problem:

http://www.ftc.gov/speeches/muris/040520spamemailtest.pdf

The only thing I can find of relevance is a footnote,
referencing a study dealing with falsity in spam, conducted
in April, 2003:

http://www.ftc.gov/reports/spam/030429spamreport.pdf

In essence, the survey found roughly 2/3rds of all spam had
some indicator of falsity.

According to the related footnote, as of April, 2003, the
FTC had 11.6 million pieces of spam as reported to it by
consumers in its database.

By May, 2004 this number had gone to over 100 million
pieces of spam as reported by consumers.

This suggests we do have a volume problem as it relates to
UBE.

The American Congress made a decision in December, 2003 to
enact a law which focuses on regulating commercial email.

Apart from giving consumers the right to opt-out, this law
does not control volume levels. 

It delegates this task to internet access services. In
essence the Act gives these service providers two years to
deal with the problem.

(Why do I say this? Because the FTC has to report to
Congress in December, 2005 on what has happened.)

We can posit lots of theories as to why Congress acted the
way it did. 

The FTC has formed the view that an opt-in law will not
control volumes. This underlines the remarks of the
Commission before the Senate in May, 2004.

See also the following:

http://inbox2004.blogspot.com/2004/06/can-spam.html

However, the situation unfolding in Australia would seem to
put paid to this suggestion.

http://www.aca.gov.au/aca_home/media_releases/media_enquiries/200
4/04-55.htm

- and -

http://www.spamhaus.org/news.lasso?article=154

But all this does not matter. 

At present, the proposal is sender accountability, which
includes authentication, accreditation and reputation. 

The MARID charter, based on the work done by the Anti Spam
Research Group is focused on the use of DNS to allow for
accountability between mail transfer agents.

The purpose of this WG is now to put forward constructive
proposals in reviewing the work done to date.

My own suggestion is simple. Any experimental proposal
which may have significant impact on the Internet
infrastructure should be reviewed by a panel of greybeards. 

Since Sender ID and Submitter is an experimental proposal
with significant potential impact, this WG should ask a
panel of greybeards to review the work on an expedited
basis to facilitate the process.

On the underlying philosophical question, do, I think any
technical solution will solve email abuse. Nope. Never did. 

Why? The Internet is a human creation and humanity ain't
perfect.

The best we can hope for through one or more technical
solutions is to bring the situation under control and to
keep the situation under control through effective law
enforcement, along with consumer education. 

No different than dealing with abusive behaviour generally,
except in this instance the problem and solutions have
technical components.

John Glube
Toronto, Canada

---

---

From: Dean Anderson <[email-masked]>
Date: Tue, 10 Aug 2004 19:28:34 -0400 (EDT)

> But all this does not matter. 

The main issue John is disputing above seems to be whether junk mail
mostly comes from virus infected machines (as I suspect) or whether it
comes from commercial emailers breaking the law (as I think John thinks).
This is basically a quibble. In either case, the abuser is violating the
law in some way, and that has a couple implications:

  1) They won't be concerned with breaking other laws of similar severity, 
such as spoofing DNS, theft of user credentials, etc.

  2) The solution is to have the law enforced.  

  3) The solution is not technical. We already have the best
authentication and accountability we can obtain in the tuple of IP address
and time of use.  This tuple is sufficient for law enforcement to identify
the virus infected machine (if that is the problem) or the commercial
emailer (if that is the problem)

> includes authentication, accreditation and reputation. 

I don't see how reputation has anything to do with SPF. The domain owner 
simply puts in an SPF txt record.  Entities of bad reputation can easily 
create SPF records.

The authentication and accountability aspects of SPF are illusory and are
not achievable in the SPF proposal as it stands, nor can DNS be used to
achieve these goals.  This subject has been discussed at length on the
DNSOP and DNSEXT lists, and it is generally agreed that DNS cannot be the 
basis of authentication.

Having found that its goals aren't achievable, it seems that the Working
Group is obligated to report this finding.  Failing to report honestly on
research is inappropriate.

Dean Anderson
Av8 Internet, Inc

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 11 Aug 2004 10:41:43 -0400

> simply puts in an SPF txt record.  Entities of bad reputation can easily 

  When MTA authentication is used *correctly* in conjunction with
anti-spam systems, publishing those records doesn't help "entitites of
bad reputation".

  Publishing the records allows any recipient to know when originators
are non-authentic.  So if spammer A decides to forge the domain of
spammer B, and spammer B publishes authentication records, you can
catch that forgery.  But it doesn't, and shouldn't, help a spammer
send messages from their own domain.

> DNSOP and DNSEXT lists, and it is generally agreed that DNS cannot be the 

  MX records say "this is the authentic place to send mail for the domain".
  RMX records say "this is the authentic place mail comes from for the domain".

  I don't see why the records are drastically different in scope.

  Alan DeKok.

---

From: "John Glube" <[email-masked]>
Date: Wed, 11 Aug 2004 10:53:03 -0400

Dean -

>The main issue John is disputing above seems to be whether
>junk mail mostly comes from virus infected machines (as I
>suspect) or whether it comes from commercial emailers
>breaking the law (as I think John thinks). This is
>basically a quibble.

Actually, the underlying issue from my perspective was your
reliance on a report which you claim was published by the
Federal Trade Commission containing a set of statistics
which you claim supports your conclusion as to UBE sources.

My problem? I can not find this report to verify your
conclusions and you have not provided a working link to
the Commission report you claim supports your position. 

Having said this, as noted previously, this is not directly
relevant to the issue at hand.

Why? It is my understanding the purpose of this discussion
list is to provide constructive comment on the design
proposals presently before the WG.

As to the remainder of your comments, I fully respect your
right to express your views in counter to mine.

Let me explain why I do not propose to go further with the
debate.

The time and place for this debate was when the IETF
decided to form this working group.

To go further would be to wander far from the purpose of
this list given the working group's charter.

Finally, you go on to write:

>The authentication and accountability aspects of SPF are
>illusory and are not achievable in the SPF proposal as it
>stands, nor can DNS be used to achieve these goals.  This
>subject has been discussed at length on the DNSOP and
>DNSEXT lists, and it is generally agreed that DNS cannot be
>the basis of authentication.

Dean, this is a most serious charge. However, it is made
without specific proof or example.

At the behest of myself and others, the WG chairs are
soliciting operational and security reviews of the marid
draft proposals (with a focus on the PRA algorithm) from
the graybeards, based on the various specific concerns
raised on this list and during the formal meetings of the
MARID WG. 

Also, the WG chairs have arranged for tests to be conducted
of Sender-ID and CSV (not Sender-ID versus CSV) by a large
American ISP with the results to be reported back to this
WG.

In my view, this is the appropriate course for this WG to
take to assess the design benefits of Sender-ID. 

I write Sender-ID, because the concepts behind SPF and
Caller-ID have been merged and a new design was brought
forward in mid-July, to be titled Sender-ID.

John

John Glube
Toronto, Canada

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.734 / Virus Database: 488 - Release Date: 04/08/2004

---

From: Dean Anderson <[email-masked]>
Date: Wed, 11 Aug 2004 19:48:32 -0400 (EDT)

> the Commission report you claim supports your position. 

Ahh. I looked for my reference; my bad; it was Email Labs, not FTC:
http://www.emaillabs.com/article_CANSPAMAudit.html

The Email Labs study was in January 2004. Searching just now, I didn't
find anything by the FTC on CAN-SPAM compliance, which I thought strange.
The Act requires the FTC to report on its effectiveness...

> decided to form this working group.

I was not invited to discuss this when the IETF formed the working group.  
Further, the purpose of a working group is to research the questions put
to it, and the answers to questions such as feasibility can't be answered
ordinarilly at the outset.  Though, in this case, information theory does
indicate that it is impossible to create a protocol that can't be abused,
so the notion of MARID is a priori infeasible, in the same way that
perpetual motion machines are infeasible.  Physics departments are thus
able to avoid researching schemes that amount to perpetual motion
machines.  Similarly, we _ought_ to be able to avoid researching schemes
that require violations of information theory.

> this list given the working group's charter.

Feasibility, impact on other protocols, impact on business activities are 
always relevant issues to any working group's task.

> without specific proof or example.

Without specific proof? That is a pretty credulous claim on the subject on
DNS authentication.  It is very well known and generally agreed by the
experts in these DNS working groups that DNS is itself insecure and can't
form the basis of an authentication mechanism.  There are well known DNS
security exploits such as the BSD R-command exploits that improperly
relied on DNS for authentication. Further, there is a specific project
called DNSSEC to address these problems. It has unsuccessfully worked on
the problem for many years (about 10 years I think).

Indeed, the DNS authentication issue is so obvious that I did not list it
in my list of 9 serious problems.  I was genuinely surprised by your
mention of it.  There is clearly a serious disconnect if people in this
working group think that DNS can be used for authentication and
accountability.

> raised on this list and during the formal meetings of the

I don't know who, specifically, you are referring to by "graybeards", but 
it clearly should be reviewed by responsible persons who are impartial to 
its approval/disapproval.

> American ISP with the results to be reported back to this

I think this is rather insufficient, in just the same way as the diebold
voting machine tests were insufficient. Diebold ran its own tests saying
the voting machines counted correctly---well, __of course__ they count
correctly when no one is trying to hack them.  We __expect__ them to work
properly under __ideal__ conditions. It is real world conditions that we
are interested in testing, and where we expect them to fail.

"A large American ISP" might have an ulterior interest in SPF, because of
the previously described harms to email outsourcing. Even if SPF has no
effect on spam, but harms outsourcing, it might still be in the interest
of "a large American ISP" to promote SPF. So there is a conflict of
interest that is unacceptable.

A proper test requires a hostile environment, such as likely to be 
encountered in the real world. A proper test also needs to be carried out 
by someone without a conflict of interest in the outcome of the test.

> forward in mid-July, to be titled Sender-ID.

Ok, I'll have to review that.  Might I propose S-ID as a suitable 
abbreviation for Sender-ID?

		--Dean