Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Charter (fwd)

From: Dean Anderson <[email-masked]>
Date: Sat, 21 Aug 2004 19:50:09 -0400 (EDT)

Someone was saying on-list that the objective of SPF isn't to reduce spam.  
I was just discussing that subject off-list.  If MTA authorization doesn't
reduce spam, there is little purpose to the MARID WG, as the MARID charter
indicates.

		--Dean

---------- Forwarded message ----------
Date: Wed, 18 Aug 2004 10:48:55 -0400 (EDT)
From: Dean Anderson <[email-masked]>
To: Alan DeKok <[email-masked]>
Subject: Re: How is SPF different from RMX? 

On Tue, 17 Aug 2004, Alan DeKok wrote:
> > Yep. But so far you haven't met any goal of reducing spam.
> 
>   Since that was never the goal in the first place, I can't for the
> life of me figure out why you keep repeating that.  You're not stupid,
> so you must have understood that was never the goal: I said so, and
> the RMX, etc. documents said so.  I guess the only answer is that you
> are saying this for non-reality-based reasons.

FYI: from the MARID charter 
http://www.ietf.org/html.charters/marid-charter.html

"This will help combat a certain class of domain forgery common in spam.
The solution chosen, however, should be generally useful for others which
might check this authorization data.

This working group is being chartered after extensive discussion of
the issues in the IRTF's Anti-spam Research Group, and it is presumed
that all active participants will be familiar with the documents
produced there which describe the problem. It is not, however, an
extension of that research group; it has no general writ to study spam
or to produce specifications on the topic. It will not consider
anti-spam abatement measures outside of the area of MTA authorization."

Reducing spam is a goal of the MARID group. Failure to achieve that goal 
is a failure of MARID.  As my examples show, Email forgery is still 
possible.

		--Dean

---

From: Meng Weng Wong <[email-masked]>
Date: Sat, 21 Aug 2004 20:36:16 -0400

On Sat, Aug 21, 2004 at 07:50:09PM -0400, Dean Anderson wrote:
| 
| Someone was saying on-list that the objective of SPF isn't to reduce spam.  

SPF/MARID/SenderID are not antispam technologies in the same
way that flour is not food.

---

From: Dean Anderson <[email-masked]>
Date: Sun, 22 Aug 2004 15:13:13 -0400 (EDT)

> way that flour is not food.

Flour is food, so I'm not sure what you mean by that.

Perhaps you mean that flour must be processed/baked somehow before it is
food.  But if the flour is inedible, because it was handled improperly and
spoiled, then it can't be processed into food, and your "food program" has
failed.

I guess the metaphor works: We would still be upset with the people for
mishandling the flour, because the purpose of having flour is to produce
food, and if food can't be produced, we'll still starve.

Likewise, if spam isn't stopped by SPF/SenderID/MARID, then those projects 
will have failed.

		--Dean

---

From: "william(at)elan.net" <[email-masked]>
Date: Sun, 22 Aug 2004 12:45:42 -0700 (PDT)

> Likewise, if spam isn't stopped by SPF/SenderID/MARID, then those projects 

No, the projecs will fail if they are unable in serious way to stop forgery
and phishing. If they help with stopping spam, that will be an extra bonus.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Dean Anderson <[email-masked]>
Date: Sun, 22 Aug 2004 16:32:09 -0400 (EDT)

> and phishing. If they help with stopping spam, that will be an extra bonus.

I've shown the examples that it does fail at stopping forgery, in its
present form. However, you can't extricate anti-spam from the MARID
charter.

Phishing can't be stopped. That is a con game as old as, well,
prostitution.  One doesn't need to forge email to phish.  Phisher's do
forge, but they don't need to.  People dumb enough to trust email
addresses despite warnings to the contrary will trust similar-looking
email addresses or completely wrong email addresses because they're
/dumb/.  Similar-looking but not-exact-duplicate letterhead and such have
been used in cons since before there was electricity.

		--Dean

---

From: "Douglas Otis" <[email-masked]>
Date: Sun, 22 Aug 2004 14:10:48 -0700 (PDT)

> | Someone was saying on-list that the objective of SPF isn't to reduce
> | spam.
>

Sender-ID does not provide a means to authenticate the MTA and identify
the entity able to respond to a problem.  This makes Sender-ID as a
mechanism for abating spam questionable.  When pressed on this issue,
several have responded privately, "Sender-ID is not about Spam!"  So it
would seem Sender-ID is not about enforcing polices that attempt to abate
spam.

Another issue with Sender-ID is that its identities are based upon RFC2822
content.  No negative assertion can be safely made based upon this
information, as the channel integrity or whether the channel is being
shared remains unknown.  An "open" Sender-ID record never allows a safe
positive assertion the message originated within the prescribed channel. 
Again, this makes Sender-ID as a mechanism for abating spam questionable.

Sender-ID ignores the problem of a spoofed return-path address, which is a
common technique used by spammers to evade blacklisting and even things
like Sender-ID.  Again, this makes Sender-ID questionable with respect to
abating spam.

Sender-ID demands perhaps hundreds of sequential DNS lookups to process a
message, but the integrity of Sender-ID depends upon this checking being
done within the channel.  A simple DDoS will likely result in these
high-overhead checks being removed.  Customers will then be advised to
ignore any Sender-ID validations, making Sender-ID as a mechanism for
abating spam questionable.

Sender-ID often claims that it protects the RFC2822 From header.  This
protection is lost when there are other headers such as Resent-From within
the message and this is not normally visible to the user.  This makes
Sender-ID questionable with respect to abating spoofing.  The likely
outcome, if Sender-ID record use is coerced, would be for all mail to then
include a Resent-From header, again making the From header open season. 
This makes Sender-ID questionable with respect to abating spam or
spoofing.

Sender-ID checks RFC2822 identities and as a result can not lower the
network overhead even when spam is rejected, as it has already been
received.  This also makes Sender-ID seem even less about spam or
mitigating the damages done by spam.

When asked how Sender-ID was to be used, Microsoft responded at the Open
Group Forum by explaining there would be folders in their new version of
Outlook to separate mail into various levels of assurance obtained by
Sender-ID.  Sender-ID is not about stopping spam, accurately sorting spam,
or even allowing a complaint about spam.  Sender-ID is about finding your
mail split into dozens of folders and not being able to use your
well-known From address.  Good luck searching for all the new aliases in
all the new folders.

In the past, Microsoft has not been good at abating spam.  To properly
handle a complaint, the entire message is needed with all the headers. 
This is not something Microsoft does properly.  This makes complaints
registered by forwarding mail from a Microsoft client worthless for
obtaining enough details to abate the spam problem.  Microsoft has a
history of not doing the right things to prevent script macros running on
machines that receive mail.  Surprise, Sender-ID continues this practice. 
This dangerous practice is likely responsible for much of the spam seen
today by way of Trojans often spread by mail.  Will these complex DNS
record sets open up new avenues for cache poisoning or DNS spoofing?

As an comparison to Sender-ID please see:
http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt

This draft is aimed at abating spam.  MPR use does not run scripts.  MPR
use does not require hundreds of sequential DNS lookups.  There are no
sequential lookups!  If you wish to protect the From header, it protects
the From header.  MPR identifies the entities able to take action to stop
the problem.  MPR does not interfere with the IPR claimed by Microsoft. 
MPR handles the bounce mail problem.

Microsoft could help abate spam by making the authenticated EHLO domain
visible to the user as a means to help solve a spoofing and phishing
problem.  Sender-ID would not be as beneficial, as it is more easily
spoofed.  Forward mail with the entire set of headers to allow complaints
to be processed, and of course, disable all scripts from running on mail
client and now MTA, if they are running Sender-ID.  And of course, an SMTP
Temp error does not mean try again immediately.  : )

-Doug

---

From: "Douglas Otis" <[email-masked]>
Date: Sun, 22 Aug 2004 14:08:28 -0700 (PDT)

-Doug

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 24 Aug 2004 16:06:37 -0400 (EDT)

Dean Anderson <[email-masked]> wrote:
...

  First, I'd like to thank Dean for forwarding a private message to a
public list.

> reduce spam, there is little purpose to the MARID WG, as the MARID charter

  In your opinion.

  Tools may be intended for one purpose, but still be effective in
others.  Ask anyone who's used a dime to turn a screw.

> http://www.ietf.org/html.charters/marid-charter.html

  It's nice to quote things out of context.  The sentence before the
one you quoted qualifies the remarks in your quote:

  "The primary current use case for this facility is to allow recipient
   MTAs to confirm that peer MTAs' actions are authorized by
   specific domains or networks. "

  For me, the charter is clear: MTA authorization is the goal, any
anti-spam benefit may be a known side-effect.

  Alan DeKok.