Subject: IPR: analysis of Microsoft patent applications

From: John Levine <[email-masked]>
Date: 17 Sep 2004 23:51:42 -0000

I have read the two Microsoft patent applications published yesterday
and analyzed the claims.  I'm not a patent lawyer or patent agent, but
I have read enough patents over the years that I think I can do an
adequate job of figuring out what their claims cover.

Visit http://appft1.uspto.gov/netahtml/PTO/search-bool.html and search
for 60/454517, the serial number of the provisional application from
which they both derive, or you can download PDF versions from my web
site at http://www.taugh.com/20040181571.pdf and
http://www.taugh.com/20040181585.pdf

Patents consist of a narrative description of the invention, followed
by claims.  A claim can be independent, standing on its own, or
dependent, based on a previous claim.  Dependent claims are generally
minor tweaks to independent claims, so I'll look at each independent
claim and all of its dependent claims as a group.

* Application 20040181571

This application is the less troublesome of the two.  About 2/3 of it
deals with methods of detecting IP spoofing, which aren't relevant
here (or, if you ask me, anywhere else since TCP stacks started
randomizing sequence numbers.)  The rest describes what is essentially
Caller ID.

Claims 1-8 and 10-21 cover anti-IP-spoofing techniques.  (There's
no claim 9.  Oops.)

Claims 22-38 cover Caller ID.  Claim 22 says:

22. In a receiving domain that is network connectable to one or more
    sending domains, the receiving domain including one or more
    receiving messaging servers configured to receive electronic
    messages from sending domains, a method for determining if a
    sending messaging server is authorized to send electronic messages
    for a sending domain, the method comprising: 

    an act of receiving an electronic message purportedly sent from
    the sending domain;

    an act of examining a plurality of parameter values of the
    electronic message to attempt to identify an actual sending side
    network address corresponding to a sending computer system;
    
    an act of querying a name server for a list of network addresses
    authorized to send electronic messages for the sending domain;

    an act of determining if the actual sending side network address
    is authorized to send electronic messages for the sending domain;

    and an act of providing results of the determination to an message
    classification module such that the message classification module
    can make a more reliable decision as to classifying the received
    electronic message.

Note the word "plurality" in clause 3, which is patent-speak for "more
than one".  I believe that SPF classic, which only checks a single
message parameter, the bounce address, isn't covered here.  SPF may
also check the HELO domain, but that's not a parameter of the message,
it's a parameter of the connection.  Yes, this is hair-splitting.
Welcome to the wonderful world of patents.

Claims 39-41 and 42-45 cover anti-IP-spoofing.

Claims 46-49 cover Caller ID again, phrased in a different way.  They
also refer to a "plurality of parameter values of the electronic
message".

* Application 20040181585

The claims in this application are breathtakingly broad.  Along with a
lot of computational puzzles, which we don't care about, they cover a
wide class of sender verifications and, as an afterthought, scoring
spam filters.

Claims 1-18 cover sender verification.  Claim 1 is extremely broad:

1. In a receiving domain that is network connectable to one or more
   sending domains, the receiving domain including one or more
   receiving messaging servers configured to receive electronic
   messages from sending domains, a method for determining a sending
   domain's electronic message transmission policies, the method
   comprising:

   an act of receiving an electronic message from the sending domain;

   an act of receiving one or more electronic message transmission
   policies corresponding to the sending domain;

   an act of parsing relevant electronic message transmission policies
   from the one or more received electronic message transmission
   policies;

   and an act of providing the relevant electronic message
   transmission policies to a message classification module such that
   the message classification module can make a more reliable decision
   when classifying the received electronic message.

To me, that covers SPF, Caller ID, Sender ID, and any plausible
variation on them that calls back to the message domain for advice on
handling the message.  By some readings it might also cover CSV, but
from the narrative text it's clear that they're talking about message
domains, not host domains.  Paul Vixie's original domain verification
proposal was published in May 2002 and he said it wasn't new at that
time, so I have my doubts about the novelty of this claim.

Claims 19-20 roughly restate claim 1.

Claims 21-35 and 36-44 cover puzzles.

Claim 45 is similar to claim 1.

Claims 46 and 47 are about puzzles.

Claims 48-49 come out of left field and cover scoring spam filters:

48. A computer program product for use in a receiving domain that is
    network connectable to one or more sending domains, the receiving
    domain including one or more receiving messaging servers
    configured to receive electronic messages from the sending
    domains, the computer program product for implementing a method
    for generating inputs to be provided to a message classification
    module, the computer program product comprising one or more
    computer-readable media having stored thereon computer executable
    instructions that, when executed by a processor, cause the
    receiving domain to perform the following:

    receive an electronic message;

    utilize one or more of a plurality of different mechanisms for
    attempting to determine if the received electronic message is an
    unwanted or an unsolicited electronic message; 

    and provide results of each of the one or more different
    mechanisms to a message classification module such that the
    message classification module can make a more reliable decision
    when classifying the received electronic message.

Since Spamassassin 1.0 was published in Sept 2001 and did exactly
this, classify messages based on several criteria, I find it hard to
understand how they'd claim this as new in a 2003 patent application.
Surely they are familiar with Spamassassin.

* Summary

Keep in mind that these are just applications, and we don't know
whether the USPTO will issue a patent and if so which if any of the
claims would be allowed.  I assume that their other applications are
similar, and we don't know what if anything will issue in other
countries.

The issue that concerns me most is that the claims in these
applications, particularly in '585, are much broader than what
Microsoft's IPR disclosed.  Note that since the IPR documents are
written by lawyers, not techs, I'm not faulting any of the MS
employees who have been participating in MARID and don't get to set
their employer's policies.

If '585 issues as a patent in anything like its current form and
Microsoft's license doesn't change, it would make SPF or any other
similiar system legally very risky since the MS license only lets you
implement Sender-ID, not other things that are like Sender-ID.
Regardless of what the MS IPR said, their patent rights depend on
what's in the patent, and if you look at cases where patents were
broader than the IPR disclosure in the standards process, the results
can be really ugly.  Google for RAMBUS JEDEC for a notorious example.

At this point, I see a variety of unappetizing alternatives.  One is
to wait and see what patents issue, but that could take years.
Another is to standardize only what MS is willing to license.  Or we
could decide that the '585 claims are implausible and ignore them, at
our peril.

My personal inclination is to say that none of the domain/IP
verification schemes are good enough to be worth this much heartburn,
put them all back on the shelf, do CSV and BATV, and turn our
attention to MASS.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---

From: David Woodhouse <[email-masked]>
Date: Sat, 18 Sep 2004 11:15:38 +0100

> put them all back on the shelf, do CSV and BATV, and turn our

I was violently in agreement with that assessment even _without_ the
patent issues, which I personally am more than happy to ignore (at my
peril, as you say).

When considered holistically, the domain/IP verification schemes don't
actually manage to achieve anything more than CSV does -- they only give
a way to determine how much to trust the individual mail server which is
offering the mail.

Thus, the heartburn of requiring ubiquitous deployment of SRS and the
addition of the Forwarded-For: header was too much for me, even without
the patent. There are better answers.

-- 
dwmw2

---

From: Roy Badami <[email-masked]>
Date: Sat, 18 Sep 2004 12:34:13 +0100

>>>>> "David" == David Woodhouse <[email-masked]> writes:

    David> When considered holistically, the domain/IP verification
    David> schemes don't actually manage to achieve anything more than
    David> CSV does -- they only give a way to determine how much to
    David> trust the individual mail server which is offering the
    David> mail.

I don't think that's true.  The domain/IP verification schemes
directly address forgery, in a way that CSV doesn't.  Think about
Sender ID as a tool for senders who (for whatever reason) want to be
able to prevent others from sending forged mail claiming to be from
them.

As a tool for recipients, Sender ID and CSV both provide a hook on
which to hang reputation and accreditation systems, and I'm agnostic
as to which will work better in the real world, though my feeling is
that they may in fact turn out to be complementary.

   -roy

---

From: David Woodhouse <[email-masked]>
Date: Sat, 18 Sep 2004 12:50:58 +0100

> able to prevent others from sending forged mail claiming to be from

I do not think of Sender ID in that way. There are true end-to-end
schemes which address that problem reliably through multiple hops, and
without requiring that the world at large upgrade to make their flawed
assumptions come true.

To offer Sender ID as a true solution to the problem of forgery is
disingenuous. It is not a general solution to that problem.

> that they may in fact turn out to be complementary.

I agree that the various reputation and accreditation systems,
maintained by different people with different criteria, will be
complementary. We've already seen that with the various IP-based
systems. 

However my feeling is that the availability of different _keys_ into
such databases would be purely redundant. While the use of IP addresses
has its problems, I feel that _any_ key which we can _reliably_ tie to
the owner of the MTA in question would suffice as a replacement.

In fact, I feel that the presence of redundant schemes for identifying
such 'keys' would be counterproductive, because it would lead to the
separate implementation of different databases which have the _same_
criteria for listings, but different keys. 

-- 
dwmw2

---

From: Meng Weng Wong <[email-masked]>
Date: Sat, 18 Sep 2004 11:49:28 -0400

A patent application is not a patent; I understand that
nowadays applications are filed containing many claims that
the filer doesn't actually expect to be approved, but if
they are approved, bonus!  So let's look at which claims we
can realistically expect to survive into patent form, and do
our best to educate the patent office about the rest.  The
ones that do make it into the patent may not turn out to be
an encumbrance after all, or if they are an encumbrance at
least we have a solid idea of how to route around them.

On Sat, Sep 18, 2004 at 12:34:13PM +0100, Roy Badami wrote:
| 
| I don't think that's true.  The domain/IP verification schemes
| directly address forgery, in a way that CSV doesn't.  Think about
| Sender ID as a tool for senders who (for whatever reason) want to be
| able to prevent others from sending forged mail claiming to be from
| them.
| 

I agree that the anti-fraud aspects of SPF/Sender ID are
stronger than CSV, and should not be abandoned just yet.

CSV alone is not sufficient because it has a weaker
deployment driver than SPF / Sender ID.  To wit:

Suppose we have lazy.example.com.  We want to encourage
lazy.example.com to deploy whatever we come up with.  But
they're lazy, so they naturally want to know the
consequences of noncompliance.

    "If I don't publish CSV records, what have I got to lose?"

    "Spammers might spoof with your HELO domain name."

    "Will people reject my mail simply because I have no CSV
    record?"

    "Considering that lots of MTAs don't even HELO with a
    resolvable hostname, and we seem resigned to that, frankly
    I'd have to say they're not going to reject your mail."

    "Then why should I bother?"

    "Because it makes life easier for other people who'd be
    victimized by spoofing --- we aim to get CSV records on
    every legitimate HELO hostname in the world so we can
    close that loophole."

The SPF story goes like this:

    "If I don't publish SPF records, what have I got to lose?"

    "Spammers might spoof with your domain name in the
    return-path or the headers."

    "Will people reject my mail simply because I have no SPF
    record?"

    "Considering that lots of domains have no SPF record,
    that day is pretty far off.  Though you never know how
    aggressive some people might get."

    "Then why should I bother?"

    "Because when people forge your domain name in the
    return-path or the headers, you get the bounces, and
    your users get phished.  Is that a problem for you?"

    "Oh, then yes, that is a problem."

So it seems to me that the average domain owner has a more
compelling case to do SPF than CSV.  I'm not saying nobody
will do CSV: I fully expect ESPs and ISPs to do CSV on their
MTAs, but you're not going to see uninterested parties
putting negative CSV assertions on all the other hostnames
that could be HELO'ed by MTAs.  By contrast, I expect many
more people to put SPF records on their domains because the
benefits are more immediate and more apparent.

| As a tool for recipients, Sender ID and CSV both provide a hook on
| which to hang reputation and accreditation systems, and I'm agnostic
| as to which will work better in the real world, though my feeling is
| that they may in fact turn out to be complementary.

I agree that they will be complementary.  In the same way
that restaurants offer a variety of eating options to
satisfy different needs, we should aim to offer a variety of
authentication options to accommodate the market better.

I have been observing a pattern of fallacious debate which
can perhaps be called "winner takes all".  In this pattern,
when you are given a choice of N options, you are allowed to
pick only one: so proponents fight tooth and nail for their
favourite choice.  This happens a lot because winning feels
good; many of us are trained to try very hard to win; and
besides, people who do not subscribe to this pattern of
living tend to be interest themselves in things other than
IETF working groups.

Very often, though, in the real world, we end up with a
blend of multiple inputs, or we end up going with a
plurality of the choices that lie before us.  Yesterday at
lunch we ordered the chocolate cake *and* the key lime pie.
There's nothing inherently wrong with getting two desserts
instead of one.  There are some operational considerations,
of course: it costs more, and we certainly didn't want to
order every single dessert on the menu just to have a taste.
In the same way, we probably don't want to tell the Internet
to have to do 512 different things; if we can limit our
recommendations to a small set of four or five they'll
probably find that livable.  Any reasonable person who hears
"this is the one and only thing you have to do" will probably
think was a bit of a hard sell.

The silly sort of "winner takes all" debate ends up looking
like:

    "Children, what is your favourite colour?"
    - "I like yellow!"
    - "I like blue!"
    - "No you don't!"
    - "Yes I do!"

I am implementing a next-generation system based on the
Aspen model of authentication, reputation, accreditation.
In that system, I'll check authentication on SPFv1, SPFv2,
CSV, and Domain Keys.  I'll check Spamhaus and Cloudmark
Rating and the VDL.  Two heads are better than one, and
yellow and blue go very nicely together.

---

From: David Woodhouse <[email-masked]>
Date: Sat, 18 Sep 2004 19:01:14 +0100

>     "Oh, then yes, that is a problem."

Actually the DK/IIM/etc. story about true end-to-end authentication goes
like that too. It's at _this_ point that they diverge, and you left out
the end of the story. The SPF story continues like this:

	"This phishing is mostly academic, but would be nice to stop.
	 But more importantly, I did this SPF record and now there are
	 people out there who are rejecting my _real_ email. That's 
	 more important to me. They tell me I should stop publishing
	 a record like you say. What is the truth?"

	"Er, um, er. They should upgrade because the way the whole world
	 works is different now."

	"I asked around and they say that this hasn't changed for
	 years and you are being naïve. Did you trick me? Do we need
	 to wait for everyone out there to change the way that
	 Internet email works first? I removed my SPF records."

Now when we come to them with the same conversation about
DK/IIM/whatever, they're going to tell us to get stuffed.

This is going to be _entirely_ counterproductive in the long run. If you
want true authentication, implement a true end-to-end scheme rather than
a hop-by-hop scheme which cannot ever solve the problem. MARID has its
place but this is _not_ it.

We need to stop disingenuously selling SPF/SenderID as a real
authentication scheme. Those who sell it like this are doing us _all_ a
disservice because they're going to severely hurt adoption of whatever
true authentication scheme is settled upon by those groups who are
working on it as we speak.

As for selling SPF as a method to stop bounces -- that's just bizarre.
BATV/SES are a totally effective way of doing that, without requiring
_anything_ of third parties for the 'publisher' to get the benefit.

-- 
dwmw2

---

From: "william(at)elan.net" <[email-masked]>
Date: Sat, 18 Sep 2004 11:24:27 -0700 (PDT)

On Sat, 18 Sep 2004, Meng Weng Wong wrote:

> they are approved, bonus! 

At the same time we also heard that only the most obvious claims are 
rejected and that most are not and patent office is expecting that if
patent does not have a leg to stand on then it'll not be possible to 
defend in court.

> So let's look at which claims we
> our best to educate the patent office about the rest. 

It appears patent office will ignore any attempts to contact them
regarding patent applications other then your own (i.e. you can contact
them in regards to somebody else patent application only as long as it
has anything to do with your own patent application and they conflict).

> The ones that do make it into the patent may not turn out to be
Hard to say...

> stronger than CSV, and should not be abandoned just yet.

Lets separate SPF from SenderID - they are in no way equivalent terms.
I see these terms as follows:

"SPF" is protocol in a way that it defines record format for representation
of policy record in dns that can whitelist or blacklist certain ip addresses

"SPF Classic" (now SPF Mail From) is using SPF protocol to protect RFC2821 
Mail From (aka ReturhPath) identity of email system

SenderID is using SPF protocol to protect a validate new PRA identity based 
on combination of RFC2822 headers From, Sender, Resent-From, Resent-Sender

> deployment driver than SPF / Sender ID.  To wit:

Agreed. And CSV Authors themselve have proposed extensions to protect
RFC2821 Mail-From. 

> benefits are more immediate and more apparent.

I do not think that we should do CSV + SPF (but its not a strong believe 
as long as both are clearly standartized, its ok - I just think its easier
for implementation if ways to protect different identities is done in
simular way). I think that it would be better for overall standartization 
process if we go with either CSV+MPR or Unified SPF (From + EHLO + PTR + 
etc) with standard  defined list of protected identities base on each method.

> authentication options to accommodate the market better.

Lets not compare Apples to Oranges ....

There is a need to diverse options in the business market place, but there
is also reason why we have unified list of standard internet protocols and
why we have IETF for that matter. 

As an example we have SMTP protocol that is defined and we dont have multiple
email systems (I note that in the IM world that is the case and its sad ...)
but we do have quite a number of diverse mail clients that users can use 
and its very good that is so as it offers several interfaces to the system
so that people can choose one that best suites their enviroment and his/her
behavior in it. But in the end all this systems talk to each other no 
matter how diverse. 

> I have been observing a pattern of fallacious debate which can perhaps 
> be called "winner takes all". 

I do not believe that is the case. What is happening is that we're trying
to decide on best technical solution that can become standard and by 
standard I mean something that everybody can implement. 

It is not unusual for IETF to consider multiple technical approaches on
how to implement something, just recently on CRISP WG we had two ways
for new whois database system - FIRS based on LDAP and IRIS based on XML 
over BEEP and both fully accomplished the requirements. In the LEMONADE
WG we had two proposals on how to implement remote email submission
that can include parts of existing email messages without downloading
them to MUA. DNS extensions WG considered two ways to implement IPv6 dns 
records (A6 and AAAA), MULTI6 is considering several approaches on
how to implement multihoming with IPV6, etc. There are lots and lots
of workgroups that had before them several proposals and approachesto 
solutiona and they had to choose one - that is part of standartization 
process.

It is in fact those situations where standartization failed and where
opposting standards exist that created problems for deployement such is 
the case of S/MIME and PGP and neither one has achieved wide deployment
as the programs supporting one often can not deal with the other type 
of signature. I do not wish to be in the same situation with solutions
created by this WG and if we create something it must be something
that everone can deply and implement and that verification systems
are compatible with each other. 

---
William Leibzon, Elan Networks:
 mailto: [email-masked]
Anti-Spam Research Worksite:
 http://www.elan.net/~william/asrg/

---

From: Douglas Otis <[email-masked]>
Date: Sat, 18 Sep 2004 11:13:04 -0700

> stronger than CSV, and should not be abandoned just yet.

Just as Sender-ID required making the PRA visible, making the validated
MTA EHLO name visible would play the same role in preventing spoofing. 
To also aid those where the EHLO domain is different from that of the
RFC2822 From, a simple name list provides a means of association which
can be obtained within a single DNS lookup.  This makes SPF/Sender-ID
seem extremely clumsy for this purpose.

>     "If I don't publish CSV records, what have I got to lose?"

CSV would allow a low cost means of white-listing.  Rather than
obtaining hundreds of addresses that will need constant maintenance, the
root MTA name plays that role.  As I also illustrated with marid-mpr
draft, this also greatly reduces overhead needed to associate ANY
mailbox domain with the MTA.  CSV lays a solid foundation for more
advanced schemes like MPR later.

>     "Spammers might spoof with your HELO domain name."

Actually, I find BATV more compelling in preventing the MAIL FROM
spoofing than SPF.  That would remove some SPF motivations.  BATV
provides this protection unilaterally. 

>     "Will people reject my mail simply because I have no CSV

I would expect any reputation scheme to evolve into known good, or known
affiliations (verified by way of the CSV name), and have the unknown
receive slow path treatment and perhaps extensive filtering.  The
motivation would be to restore an ability to send higher volumes of
mail.  A reputation scheme can not be based upon the identities obtained
from either SPF or Sender-ID as these identities are far too weak.

>     I'd have to say they're not going to reject your mail."

Until there is also a CSV-CSA record discovered, then the advantages of
being recognized will not exist.  CSV will allow the validation of the
MTA by name.  CSV is resolved to change the depreciation of the EHLO
name.

>     every legitimate HELO hostname in the world so we can

Currently there is a tremendous expense consumed by those that send mail
using false identities.  This may mean a phase-in aimed at slowing this
flood of abusive mail.  To consume less time looking through filtered
mail, and to conserve the remaining network for productive uses, a
combination of white-listing and slow path approaches should provide
plenty of motivation.  The white-list may even allow an ability to
override an IP address black-list. 

>     return-path or the headers."

But if the domain leaves the SPF/Sender-ID list open to allow the
acceptance of forwarded mail, then this will actually invite spoofing as
a means of usurping the domain's reputation. : (

>     your users get phished.  Is that a problem for you?"

BATV solves the bounce mail problem.  SPF NEVER stops the phishing
problem.  Even Sender-ID would be a valuable tool for a confidence
artist, as it allows easy means to either spoof of deceive the
recipient.  Displaying a validated EHLO name would be a much more
difficult name to spoof and where financial institutions should make an
effort to be consistent in their use of these EHLO names.

Making the EHLO name visible when it is validate would also be
motivation for the deployment of CSV records.  Making this name visible
would also provide valuable consumer protections that are not possible
with SPF or Sender-ID.  In addition, the use of these names does not tie
consumers to a particular provider, nor will this name risk the
reputation of a domain that uses the services of providers.  CSV leaves
the accountability with the providers.

> benefits are more immediate and more apparent.

The risks publishing SPF records will become more apparent when SPF
based reputation becomes employed.  Expect a flood of unhappy
individuals and litigation.  Should the validated EHLO domain become
visible to the recipient, then this acts to protect their name.  This
can be confirmed by way of a simple list if needed.  Why expend all the
effort listing addresses over and over?

> authentication options to accommodate the market better.

Although I would agree that SPF plays a more significant function than
Sender-ID in combating spam, I suspect BATV remains a better solution in
that respect.  SPF or Sender-ID can not live up to the promise of
providing trustworthy validations of the sending domain.

> living tend to be interest themselves in things other than

There is a large infrastructure built upon an incredibly ubiquitous
application.  Retaining the scalability of this application also means
considering the implications any scheme has upon routing and overhead. 
In my view, SPF and Sender-ID fail in those considerations.  Making a
cornucopia of options for what should be a universal method to send a
message is also counter to such a goal.   

> lunch we ordered the chocolate catheke *and* the key lime pie.

Will you be providing the reputation services for SPF?

-Doug

---

From: Meng Weng Wong <[email-masked]>
Date: Sat, 18 Sep 2004 14:24:28 -0400

On Sat, Sep 18, 2004 at 07:01:14PM +0100, David Woodhouse wrote:
| 
| This is going to be _entirely_ counterproductive in the long run. If you
| want true authentication, implement a true end-to-end scheme rather than
| a hop-by-hop scheme which cannot ever solve the problem. MARID has its
| place but this is _not_ it.
| 

I plan to implement DomainKeys as soon as a plugin is
available for my MTA.  Have you implemented it yet?

| We need to stop disingenuously selling SPF/SenderID as a real
| authentication scheme. Those who sell it like this are doing us _all_ a
| disservice because they're going to severely hurt adoption of whatever
| true authentication scheme is settled upon by those groups who are
| working on it as we speak.
| 
| As for selling SPF as a method to stop bounces -- that's just bizarre.
| BATV/SES are a totally effective way of doing that, without requiring
| _anything_ of third parties for the 'publisher' to get the benefit.

I will try to clarify an important misunderstanding.

SPF Classic targets the practice of return-path spoofing.

The immediate benefit to publishers is that they will begin
to get fewer bounces.

But that is not the only benefit.

The total benefit is that return-path spoofing will be
reduced.

Part of the harm of return-path spoofing is that
undeliverable addresses generate cause bogus bounces.

But another part of the harm of return-path spoofing is that
deliverable addresses receive forgeries.  A bounce may not
get generated, but harm is still done.

I agree that BATV/SES are the best solution to the
stop-bogus-bounces problem, better than SPF Classic because
they can be implemented unilaterally.  The cost is only
slightly higher than SPF Classic: both require domains to
corral all their users into using the domain's approved
servers.  In addition, BATV/SES sign outbound return-paths.

However, BATV/SES only limit the harm from the fraction of
the mail that does bounce.  It does not address the fraction
of the mail that is delivered.  SPF Classic and Sender ID do.

Therefore, the benefit of SPF Classic goes beyond reducing
bounces.  Likewise, the purported benefit of Sender ID
addresses phishing, which for whatever reason is not being
addressed by true end-to-end methods today.

When banks start DomainKeys or S/MIME signing all outbound
mail, I promise to give up SPF and Sender ID.  If you want
me to stop campaigning for SPF and Sender ID, I suggest you
focus your energies on the dependency.

To reiterate my position: if you believe you have the One
True Solution, please go and help make it happen.  If you
believe that someone else's One True Solution is wrong, it
is more productive in the long run to work on your solution
than attack somebody else's.

    Mathemeticians stand on each other's shoulders.
    Computer scientists stand on each other's feet.
    -- originally Richard Hamming, I think.

---

From: "william(at)elan.net" <[email-masked]>
Date: Sat, 18 Sep 2004 12:06:36 -0700 (PDT)

> available for my MTA.  Have you implemented it yet?

No and I don't believe anybody else should either. That is unless you're 
prepared to loose legitimate email when it comes through email list.

DK is badly engineered mail signature system that will cause many false 
positives - it falls particularly badly with maillists and with majority 
of other cases of email being reintroduced by gateways or intermediate 
email processors, in fact anything that changes headers in any way!

If you want something that is ok consider MTA Signatures or possibly
Cisco identified email proposal. Neither one is perfect, but at least
there is not as much space for failures.
 
> | authentication scheme. 
Nobody does. But at the same time SPF offers ability to protect communication
parameters of the transmission (envelope) and its a lightweight approach
that can be more easily implemented and can allow to reject mesage before
transmission even began.

All encryption methods while offering a lot stronger protection, they also
carry heavier penalties for those doing signatures and verification and
they require a lot more changes to all MTAs to support it.

---

---

From: [email-masked] (Claus Färber)
Date: 18 Sep 2004 22:26:00 +0200

> The SPF story goes like this:
...
>     "Oh, then yes, that is a problem."

Some time later:

        "I'm getting more rouge bounces."

        "That's because some servers bounce messages when the SPF check
        failed."

        "I thought they should not do that."

        "Well, some do anyway."

Claus
-- 
http://www.faerber.muc.de

---

From: Douglas Otis <[email-masked]>
Date: Sat, 18 Sep 2004 16:27:29 -0700

> available for my MTA.  Have you implemented it yet?

I suspect the ultimate solution for digital signatures will be a merger
of IIM and DomainKeys.  I'll wait to see how these solutions are
resolved once MASS gets going.

> undeliverable addresses generate cause bogus bounces.

The reason for the spoofed MAIL FROM strategy is to circumvent
blacklists which prevent the message from being sent directly.  BATV
blocks this back-door technique entirely.  A public version of BATV
should also allow the return path to be discarded before an attempt to
send the bounce is made.  The message will be stopped before it is sent
in most case however, even with the private mode.   

> get generated, but harm is still done.

By preventing the success of this strategy with BATV, there should be
fewer such attempts over time.

> of the mail that is delivered.  SPF Classic and Sender ID do.

BATV can be done by the MUA as well as the MTA.  There is not a
requirement to constrain where the message originates for the BATV
scheme to still function.  The granularity of the BATV can be over both
users and time.  Once implemented system wide, there will be a high
percentage of bounces eliminated.

SPF or Sender-ID schemes do not address the sources of abuse.  Abusers
can publish these records as well as legitimate domains.  As both the
SPF and Sender-ID identities are easily spoofed, these names are
worthless for asserting a reputation without the risk of harming
innocent domains.  Their weak identities likely make these schemes more
of a risk than an asset.  

> addressed by true end-to-end methods today.

Sender-ID does not address phishing!  If anything a confidence artist
will likely use the "validations" of Sender-ID as a means to establish
credibility which can be done a number ways.  If financial institutions
adopt consistent EHLO names and have these validated names made visible,
this would make phishing significantly more difficult.  As it would be
difficult to spoof the EHLO name, it is not likely to serve to falsely
increase the credibility of a message.

Unlike Sender-ID, a consistent field would be made visible which
prevents the sneak path made possible by differences in the PRA
selection algorithm.  Until the MUA is upgraded to display this
validated EHLO name information, nothing changes with respect to the
level of reliance consumers are asked to give the mailbox addresses they
see.  In the case of Sender-ID, the PRA may be fully validated by the
MTA, but the From can remain Big-Bank.com.  Suggesting consumers can
trust the mailbox domain once Sender-ID is in place would be extremely
hazardous.  

> focus your energies on the dependency.

Just like Sender-ID and SPF, these signatures will not reduce the spam
problem.  With the higher overhead needed to process these signatures,
it becomes even more urgent to address the spam issue for these
technologies to be viable. 

> than attack somebody else's.

Focus on goals more than a specific solution.  It seems serious issues
are not addressed out of a sheer desire to promote "the" solution
irrespective of potential downsides.  As was illustrated by the
marid-mpr draft, taking two steps in the process actually takes less
time, incurs less cost in terms of maintenance, and protects the
customers of providers by not forcing a mailbox domain or allowing a
provider's neglect to unfairly tarnish their domain's reputation.

By the same token, responsible providers must be allowed to defend their
address space from abusive customers.  This is often done through
transparent interception or port blocking.  Devising a scheme that works
for an end-to-end exchange is not appropriate for mail that must
consider the use of a shared MTA.

-Doug

---

From: Matthew Elvey <[email-masked]>
Date: Sat, 18 Sep 2004 16:45:53 -0700

>least we have a solid idea of how to route around them.
That's important.  Also, isn't anything that's provably prior art that 
makes it into the patent not an encumberance either?  In other words, 
what will make it into the patent and can be successfully defended is 
the relevant question, yes?

>deployment driver than SPF / Sender ID.  To wit:
I don't disagree with your arguments in support of this claim, but I 
disagree with the conclusion because of strong counterarguments.
Here are some arguments that the opposite is true (an edited version of 
Meng's post):

SPF / Sender ID alone is not sufficient because it has a weaker
deployment driver than CSV / SPF3.  To wit:

    "Spammers might spoof with your HELO domain name.  Besides,
    it's quicker to do it than to spend a few minutes discussing
    'why bother?'.  Heck, if you don't run your own mail servers,
    you can just publish an empty record, which will ensure you
    have a good reputation when you decide you want to have your
    own mail servers.  It's much, much easier than creating a
    good SPF1 record."

    "Will people reject my server's mail simply because I have no CSV
    record?"

    "If spammers spoof with your HELO domain name, it'll get blacklisted.
    They're going to reject your server's mail once that happens."

    "Oh, then yes, that is a problem.  I'd better make a CSV record.
    There'll be CSV records on
    every legitimate HELO hostname in the world soon,
    so as to close that loophole, huh?"

    "How do I create an SPF record to prevent this?  My users
    send mail through servers like smtp.comcast.com. According
    to AOL's Hutzler, 'AOL already gets >85% of our spam from
    other ISPs main outbound MTAs.'

    "You can't.  (Unless you force your users to use servers you control.)"

    "No..."

So it seems to me that the average domain owner has a more
compelling case to do *CSV than SPF*.  I'm not saying nobody
will do SPF...

>living tend to be interest themselves in things other than
Yes, the wannabe-standards can be seen as complementary.  The IETF can 
endorse (so to speak) several of them.
However, there's a cost to implementation of each one (and they vary!).  
To the extent that we can standardize on the minimum number that is 
sufficient to accomplish the goals best (in terms of, e.g. the amount of 
effort needed to implement them) we reduce the total cost of 
implementation.  Given that all the proposals require A&R (Accredidation 
and Reputation Services) to be effective*, the amount of work needed for 
A&R should be considered important as well.
(*notwithstanding Doug argument that that SPF-style A&R is nigh 
impossible.)  Hence it's appropriate for you and I to argue, as we are 
doing, which is better.

Remember all the effort that sysadmins went through to close open 
relays?  It was thought that this would go a long way toward solving the 
spam problem.  It failed to stem the tide.  We need to have some 
confidence that when we go to sysadmins and ask 'em to do something else 
to solve the problem that it WILL stem the tide.  Hence the urgent need 
for a *closely scrutinized / debugged* BCP on how M.A.R.I.D.s should be 
used.

(Yes, I'm agreeing with William - we should choose one MARID scheme.

>yellow and blue go very nicely together.
Cool.  I expect SpamAssassin will be doing much of this as well (not the 
SenderID bit!).
OT: How does one access the VDL? 

David Woodhouse said:

>We need to stop disingenuously selling SPF/SenderID
>
Yup.

>        "I'm getting more rouge bounces."
It's 'rogue'; folks keep misspelling it or I wouldn't mention it.

>        "I thought they should not do that."
That's true but the spec itself doesn't say whether they should or not. 
Anyone want to work on the BCP?  I'm thinking of putting it up on a wiki 
(the ASRG wiki, so that contributions are covered by needed policy) for 
collaborative improvement.

---

From: Douglas Otis <[email-masked]>
Date: Sat, 18 Sep 2004 23:57:51 -0700

> able to prevent others from sending forged mail claiming to be from

When financial institutions use consistent EHLO names for their MTAs and
validated EHLO names are presented to users, then this too serves to
foil forgeries.  This depends upon users being able to recognize these
names through their normal correspondence.  The marid-mpr draft was to
illustrate a simple name list could be used to confirm the message is
within the nominal mail channel. 

The advantages using CSV/MPR over Sender-ID are as follows:

a) The RFC2822 From will be marked out of the nominal mail channel
   irrespective of any other headers. 

b) A single DNS lookup is required to obtain the mailbox domain/MTA
   association.

c) Phase-in is safer with reliance upon the EHLO name and not the
   mailbox domain.  Until seen, there is no increased expectations.

d) The EHLO is stronger, and more difficult to spoof than Sender-ID and
   allows for reputations to be safely asserted.

e) Reputation assertions upon the EHLO name-
   1) Isolate problems where this is not true for Sender-ID.
   2) Does not constrain the use of the mailbox domain allowing provider
      choice.
   3) Protects consumers from lax providers tarnishing their reputation.
   4) Allows mailbox domain associations to safely be open without
      inviting spoofing exploits.

> that they may in fact turn out to be complementary.

Sender-ID does not provide a safe hook for reputation assertions nor
does it provide good forgery protection as it can be easily spoofed.

-Doug

---

From: Tony Finch <[email-masked]>
Date: Sun, 19 Sep 2004 13:38:55 +0100

On Sat, 18 Sep 2004, Meng Weng Wong wrote:
> servers.

Incorrect: you can implement BATV on a per-user basis. Users can continue
to work as they currently do, but if backscatter is a problem for them
they can reconfigure as necessary (so that they always use authenticated
message submission via the domain's home systems) and turn on BATV,
without affecting other users of that domain.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
HEBRIDES BAILEY: WEST BACKING SOUTHWEST 6 TO GALE 8, BECOMING CYCLONIC LATER
IN BAILEY. SHOWERS THEN RAIN. GOOD BECOMING MODERATE OR POOR.

---

From: David Woodhouse <[email-masked]>
Date: Sun, 19 Sep 2004 18:28:10 +0100

> mail, I promise to give up SPF and Sender ID. 

The problem with DomainKeys is that it's not _ready_ yet. If my
understanding is correct, it still actually breaks in the real world --
mail sent via mailing lists which add a few lines to the mail will
appear to have a _broken_ signature. We need to make sure that is fixed
first.

As I said, it's massively counterproductive to sell something before
it's ready, especially if it's going to reject valid mail. All you'll do
is put people off and then they won't play when it really _does_ work.

But it's being worked on. Be patient :)

> they can be implemented unilaterally.

Right.

> The cost is only slightly higher than SPF Classic: both require
> domains to corral all their users into using the domain's
> approved servers.

As Tony pointed out, that's not strictly necessary. I currently
implement SES on an opt-in basis. You can instantly stop getting any
bounces to mail you didn't send -- but you have to start using SMTP
AUTH. It's a per-user choice (actually per-address).

> of the mail that is delivered.  SPF Classic and Sender ID do.

Actually SES _can_ address the fraction of the mail that is delivered.
Try delivering MAIL FROM:<[email-masked]> to any machine which does
SMTP sender verification callouts, for example. I appreciate that
callouts are unpopular in some quarters -- the use of a stunt DNS server
and something like the SPF 'exists' mechanism has also been suggested,
as a way to assist recipients in identifying fake messages.

> than attack somebody else's.

To a certain extent I agree with that sentiment, but not entirely. For a
start I don't like your choice of pronouns. We're all in this together;
there should be no 'us and them'. 

If we sell them snake oil now, they're less likely to trust us later
when we _do_ get the formula right. 

If I didn't think that SPF was actively harmful in the long run, I
wouldn't argue against it.

-- 
dwmw2

---

From: Dave Crocker <[email-masked]>
Date: Sun, 19 Sep 2004 11:31:11 -0700

Meng,

>  can realistically expect to survive into patent form, and do

You are suggesting depending upon a particular Patent Office outcome. Patent 
processes are not nearly that predictable.  Feel free to present some evidence 
to the contrary.  

In general Internet-scale adoption and use of technology is significantly 
constrained by the number of strategic dependencies to that adoption and use.  
Fewer is always markedly better.  Each critical dependency can have unwanted 
outcomes, thereby jeopardizing the effort that depends on it.

>  stronger than CSV, and should not be abandoned just yet.

First of all, let's be clear about focus, function and dependencies:

SPF is mostly about validating a particular message's original sender.  It does 
this indirectly, by authenticating the RFC2821.MailFrom. It relies on the 
authorization of the MTAs along the delivery path to each recipient.  It 
requires on-going coordination between the originating sender, the administrator 
of the RFC2821.MailFrom's domain name and administrators of each MTA along the 
path the each recipient.  SPF has no accreditation mechanisms.

Sender-ID  is mostly about validating a particular message's author. It does 
authentication of the RFC2822.From and authorization of the the MTAs along the 
delivery path to each recipient .  It requires on-going coordination between the 
author, the administrator of the RFC2822.From's domain name and administrators 
of each MTA along the path the each recipient. These are often independent 
administrative authorities. Sender-ID as no mechanisms relating to 
accreditation.

CSV is about validating the operator of a peer (client) MTA.  It does 
authentication and authorization of the RFC2821.Helo/Ehlo domain name, used by 
that MTA. It requires on-going coordination between the operator of that domain 
name and the administrator the domain name used by the MTA in the 
RFC2821.Helo/Ehlo; this is typically the same administrative entity.  CSV also 
does accreditation of that domain name.

So the scope and focus of each of these is notably different.  One therefore 
ought to be rather careful in comparing them.  

>  deployment driver than SPF / Sender ID.  To wit:

Assessing adoption and use incentives requires a tad more effort.  What are the 
administrative requirements? Who must perform them? How often? What parts of the 
infrastructure must change?  What problems does it solve? How do cost vs. 
benefit compare? And so on.

SPF and Sender-ID require that someone responsible for generating or posting 
content must know ahead of time what MTAs their message will go through. That 
means that virtually every domain name must pre-register path records and must 
maintain them when new or different paths will be used.  So, for example, the 
administrator of the originator's domain must know when the ISP who is running 
the MTAs changes IP Addresses for their MTAs. And SPF and Sender-ID break 
existing third-party origination and relaying scenarios.  

Hence, SPF and Sender-ID work comfortably only for some very simple scenarios.  
The fact that those scenarios are popular is seductive enough to make it easy to 
miss the challenges posed for other, entirely legitimate scenarios.  Attempting 
to apply SPF or Sender-ID to those other scenarios requires changing the nature 
of email admin, ops and use.

CSV requires that the operator of a client MTA use some domain name that 
supports CSV conventions.  Any domain name will do. Hence the number of domain 
names to support is some orders of magnitude smaller than for SPF or Sender-ID. 
And CSV does not try to correlate message content with message path. So there is 
no requirement for ongoing "cross-talk" between administrative realms. Further, 
CSV cannot evaluate an individual message.  Rather it permits assessing an 
operator's aggregate performance.  SPF and Sender-ID cannot do this.  CSV does 
not involve any changes to Internet-scale scenarios, such as forwarding.

For all that, CSV and SPF/Sender-ID try to solve very different problems.  
SPF/Sender-ID try to ask whether a particular message is likely to be safe.  CSV 
tries to ask whether a particular MTA operator is likely to be safe.

>  "Will people reject my mail simply because I have no CSV
....
>  "Will people reject my mail simply because I have no SPF

These exemplars purport to go to the heart of what one can and cannot do with 
the different mechanisms.  What the exemplars miss is that no one attempting to 
use them can reasonably assert a negative, in the absence of support by the 
client.  Hence, these schemes are primarily useful only for making a positive 
assessment.  That is the logic difference between confirming a sender that is on 
a whitelist, versus rejecting a sender that is not.

It is essential to assume that no scheme will have very large-scale adoption 
anytime soon.  Internet experience in changing existing services is quite 
consistent on this point.

That ought to make us all pretty modest about our expectations.  It also means 
we should validate that a scheme is useful when there is small-scale adoption; 
that is, when the typical case is that it is not supported.

>  your users get phished.  Is that a problem for you?"

This says that the SPF is useful for protecting against forged bounce addresses. 
For this we modify the email architecture and we incur on-going path 
registration costs.

>  compelling case to do SPF than CSV. 

CSV is not for the 'average' domain owner.  It is strictly for MTA operators.

SPF and Sender-ID require on-going coordination between those average domain 
owners and MTA operators.  CSV requires no such coordination between independent 
administrative entities.  

Care to re-consider your assessment about adoption and use incentives?

>  but you're not going to see uninterested parties
>  that could be HELO'ed by MTAs.  

I re-read this statement a number of times and I still can't figure out what you 
are saying.

>  can perhaps be called "winner takes all".  

I've been observing a pattern of responding to all new issues with "we can fold 
that into [the undocumented] Unified SPF".  And, yes, that sounds a lot like a 
winner take all model.  

What is troubling is that it misses the long and well-established lesson that 
schemes that try to be all inclusive usually fall down of their design, 
implementation, administration and operations complexity.

d/
--
Brandenburg InternetWorking
[email-masked]
+1.408.246.8253