Subject: Re: IPR Disclosure for Sender-ID

From: Andrew Newton <[email-masked]>
Date: Tue, 3 Aug 2004 06:52:49 -0400

John,

I have received no additional information regarding IPR for Sender-ID.

I do note the following:
   o Reading the "Status of this Memo" section of 
http://www.ietf.org/internet-drafts/draft-ietf-marid-core-02.txt, there 
is a statement that all IPR has been submitted.
   o The text of 
http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-atkinson-callerid.txt 
(which, incidentally, cites draft-ietf-simple-iscomposing-00) is titled 
"Microsoft's Statement about IPR Claimed in draft-atkinson-callerid"
   o The title of the draft 
http://www.ietf.org/internet-drafts/draft-atkinson-callerid-00.txt is 
"Caller ID for E-mail".
   o Section 3.2 of draft-atkinson-callerid-00.txt and Section 4 of 
draft-ietf-marid-core-02.txt discuss the same process for determining a 
"responsible" domain though the wording is not identical.
   o The title of draft-ietf-marid-core-02.txt is "Sender ID: 
Authenticating E-Mail".
   o The following web page is cited in the Caller ID IPR claim as 
containing a license to implement: 
http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx
   o The above web page is titled "Sender ID" and contains a link to 
"Caller ID for E-Mail Implementation License".

Based on this, I can see how a person could reasonably assume that the 
patent claim for draft-atkinson-callerid-00.txt also covers 
draft-ietf-marid-core-02.txt.

This topic is still on the agenda for the 4 August meeting.  The 
deadline of 2 August was given so that participants could have time to 
read any additional material before the meeting.

-andy

On Aug 3, 2004, at 4:25 AM, John Glube wrote:

> Andy,
>
> Having completed a search of the IETF's IPR notices it seems
> the only filing by Microsoft to date is:
>
> http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-atkinson-calleri
> d.txt
>
> This was filed on May 28, 2004 and concerns
> draft-aktinson-caller-id.
>
> From the Sender-ID Schedule posted on 19.07.2004:
>
> "Aug. 2 - Deadline to have all IPR information to the MARID
> working group mailing list. This includes patent claims,
> licensing information, and trademark issues."
>
> http://www.imc.org/ietf-mxcomp/mail-archive/msg02749.html
>
> With no filings being made and nothing being posted to the
> mailing list, further to the comments of Ted Hardie on
> 19.07.04 regarding the license issue:
>
> http://www.imc.org/ietf-mxcomp/mail-archive/msg02748.html
>
> I request guidance.
>
> * What is the present relevance if any of the filing by
> Microsoft on May 28, 2004 to draft-ietf-marid-core-02.txt
> titled "Sender ID: Authenticating E-Mail" filed in July and
> found at:
>
> http://www.ietf.org/internet-drafts/draft-ietf-marid-core-02.txt
>
> May this WG proceed forward on the basis that:
>
> * MS has not abandoned its original position?
>
> I ask this question as the MS web page dealing with Sender
> ID continues to state:
>
> "If you are a software developer and are interested in
> implementing this specification in software, please review
> the terms of the Caller ID for E-Mail Implementation License
> before you begin, as the patent license discusses the rights
> that Microsoft would grant you or your organization."
>
> http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx
>
> On 18.07.04, Henry Katz wrote:
>
> "Thanks Bryce.  I am drafting an FAQ to answer the questions
> that have been raised.  As I'm sure you can appreciate, this
> needs review and approval by attorneys (plural) and other
> folk here.  I hope to be able to publish this FAQ to the
> list within the next few days.
>
> I understand and appreciate the questions people have been
> asking.  Let me just say at this point that our intent is to
> contribute our IP to this working group and to encourage
> widespread implementation and adoption.  I very much
> appreciate everyone's patience while I gather the answers to
> your questions."
>
> http://www.imc.org/ietf-mxcomp/mail-archive/msg02737.html
>
> * MS is not making an IPR claim concerning Sender-ID and
> therefore software developers who are interested in
> implementing the Sender-ID specification have no need to
> seek a license from MS?
>
> I ask this question as:
>
> * there has been no filing by Microsoft concerning
> draft-ietf-marid-core-02.txt
>
> * nothing was posted to the list on August 2, 2004;
>
> * the following comment by Mark Lentczner on July 30, 2004
> when he wrote in part:
>
> "The current form of the PRA algorithm (in core-02) is
> neither heuristic nor proprietary nor arcane: It is a direct
> embodiment of the 2822 concept of the mailbox that sent or
> resent the message.  The priorities and orderings of the
> headers checked is follow directly from the 2822 definition
> of the headers.  I'm sure the description in core-02 could
> be more clear in this regard."
>
> http://www.imc.org/ietf-mxcomp/mail-archive/msg02927.html
>
> I appreciate your time in this matter and await your
> guidance.
>
> John
>
> P.S. There is a sense of urgency. MS announced on 22.07.04
> it will begin testing Sender-ID on 01.10.04 on the
> MSN and Hotmail domains. MS is urging other ISPs to follow
> suit. Time is beginning to run out for this deadline.
>
> The IPR issue was placed on the WG Agenda for August 4.
> In anticipation, on 19.07.04 the WG asked for a posting
> by 02.08.04. The time line has lapsed.
>
> cc. Ted, Harry, Mark and the IETF Marid Mailing List
>
> 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: "Douglas Otis" <[email-masked]>
Date: Tue, 3 Aug 2004 09:38:23 -0700 (PDT)

I find it difficult to imagine the licensing terms to be reasonable for
most.  See:

http://download.microsoft.com/download/6/0/a/60a02573-3c00-4ee1-856b-afa39c020a95/callerid_license.pdf

An alternative with the _same_ feature set can be found as follows:

1) Authenticate and verify the authorization of the EHLO domain with CSV.

2) To restrict the RFC 2822 From domain, list all acceptable EHLO domains
for From domain allowed in a MARID TXT record.

Call the <From:EHLO> (Mailer-ID) and the TXT record the MARID Channel
permissions (MCP).

This would allow authentication to happen without adding a single DNS
lookup.  Unlike Sender-ID with DNS timeouts that fail to implement
exponentional back-off while making huge demands upon DNS, or where the
duration of their query may otherwise take hours.  By using only names,
the delegation problems are removed.  A simple wildcard used in this
permitted list could encompass the required scope.  There would not be
CIDR block lists that allows easy abuse.

All the advantages, none of the disadvantages...

-Doug

---

From: wayne <[email-masked]>
Date: Tue, 03 Aug 2004 12:29:25 -0500

> I find it difficult to imagine the licensing terms to be reasonable for

I agree.  From the research that I have done, it appears that the
SenderID license is incompatible with several important free software
packages (exim, postfix, spamassassin, bogofilter, etc.).

As far as I'm concerned, this makes the PRA a non-starter.  Even if
the PRA RFC makes it past the working group last call, I see very
little chance that it would make it through the general IETF last
call.

I think that Microsoft's failure to come up with an acceptable license
has created a very unfortunate waste of time for this working group.

> for From domain allowed in a MARID TXT record.

Yes, this general idea has been suggested many times by many people,
including me near the beginning of the on the SPF lists and PHB during
the interim meeting.  I'm sure I'm not the first, nor will you be the
last to see this obvious idea.

So, the one I-D with the PRA algorithm could be replaced with:

http://www.ietf.org/internet-drafts/draft-schlitt-marid-spf-from-hdr-00.txt

-wayne

---

From: Michel Bouissou <[email-masked]>
Date: Tue, 3 Aug 2004 20:34:30 +0200

> packages (exim, postfix, spamassassin, bogofilter, etc.).

I agree.

> As far as I'm concerned, this makes the PRA a non-starter.

I fully share this point of view.

Sorry for this me-too style reply to the list, but I think the matter is 
important enough, so I express again my opinion on the matter, which I have 
expressed in more detail previously.

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

---

From: "Douglas Otis" <[email-masked]>
Date: Tue, 3 Aug 2004 14:19:05 -0700 (PDT)

> "Douglas Otis" <[email-masked]> writes:
>

This has a problem with scaling.  As a means to reduce the information and
to simplify publishing and support, use the CSV authorized and
authenticated name for the channel, rather than repeating this address
information.

CSV provides a means for accreditation to be related exclusively to the
polices of the domain sending the mail.  This domain must be watching
their logs to detect SMTP errors.  If they see too many errors, these must
be investigated further and matched against the abuse@ reports.  The
holder of the log, as denoted by the EHLO response, is the gatekeeper for
the mail sent. They have the greatest effect in blocking abuse.

Build upon CSV, where mail domain permission records do not need to
include any IP address.  As example, if a record wishes to restrict the
RFC 2821 MAIL FROM and RFC 2822 From for [email-masked] to be emitted by
SMTP servers offering the EHLO mx1.big.isp.com mx2.big.isp.com and
java.ads-r-us.com ...

These records could be something like:

"Marid_1 rf=*.big.isp.com, *.ads-r-us.com;"

This record puts a restriction on both the RFC2822 From and the return
path (RFC2821 MAIL FROM).  If to just to limit the MAIL FROM, then the
text may be:

"Marid_1 r=*.big.isp.com, *.ads-r-us.com;"

If the identity of the sender includes a display something like-

From: [email-masked] <mx1.big-isp.com.>

If the ehlo domain did not offer CSV records, then the it could be:

From: [email-masked] <mx1.big-isp.com!>

This would offer a means for people to recognize the identity of the
sender by both their return address and their channel identifier.  If
there is a crime, then the channel identifier becomes the place to look
for the logs.

If big.bank.com puts a restriction on their From field, one would not
expect them to be sending from a list server with this domain.  Even
without the restriction, the user would be able to see if they were
talking to someone on the same channel.

This would allow the same methods for filtering, with Sender-ID.  Assume
that most major ISPs would have reacted by putting Resent-From: headers
into outgoing mail to isolate thier customers from the problems Sender-ID
cause.  The EHLO domain places the same role.  It is already being sent. 
CSV simply fixes the problem discovered with STMP EHLO domain
authentication.

For those domains that prevent abuse, but don't wish to restrict the From
address for their domain, then only the CSV SRV records are needed for
this MAIL-ID to be useable and beneficial.

-Doug

---

From: Michel Bouissou <[email-masked]>
Date: Wed, 4 Aug 2004 00:34:08 +0200

> "Marid_1 rf=*.big.isp.com, *.ads-r-us.com;"

About CSV, I have taken a quick look at the drafs (sorry, I haven't had the 
time to read them thoroughly), and I have a question, and a remark :

- Question : SPF currently has the extremely useful and flexible "exists" 
mechanism, that, combined with its built-in macro-expansion, allows for 
designing very fine-grained and flexible exceptions to the general SPF rule 
for a given domain, i.e. per user and subnet.

Let's say big-company.com has an SPF record listing their main outgoing mail 
servers, they can easily include supplementary records that would list 
field-people posting from a given ISP server, or a local office people using 
their own local SMTP server, etc.

This can be most useful in a number of situations.

Does CSV have provisions for such a mechanism, or an equivalent ?

Now for the remark : I am strongly opposing to the idea of would-become- 
mandatory "accreditation services".

I'm opposing to it both for philosophical reasons, and practical reasons.

First, "accreditation services" will turn into businesses, which will 
translate into cost, which means that every domain that will want to send 
mail out will have to support this new cost : having to pay a commercial 
"accreditation" company to get listed there, if they want their mail to be 
accepted.

This will introduce costs that many non-profit, personal or vany domains will 
not be able to afford, and I oppose the idea that anybody should have to pay 
a commercial company for being allowed to send mail.

The advantage of current blacklist systems is that no one has to pay for 
getting blacklisted ;-) and, if some blacklists are commercial, such as MAPS, 
you need to pay to use and query them, not to be listed in them or not...

Also, big companies that send large amounts of email will be well-know and 
listed by most, if not all, accreditation services, where little domains, 
small businesses and individuals that send a very small amout of mail will 
mostly be "unknown" everywhere, and the acceptance of their mail might suffer 
from this.

IMHO, one should be deemed innocent until proved guilty, and the 
"accreditation services" system turn the things upside-down : One will be 
presumed guilty unless listed as innocent. Bad, bad, bad.

The advantage of blacklists, on the opposite, is that, if ever you get listed, 
there is probably a reason, and if you're not listed you're presumed 
innocent. Much better.

Comments ?

---

From: "Douglas Otis" <[email-masked]>
Date: Tue, 3 Aug 2004 16:49:17 -0700 (PDT)

> About CSV, I have taken a quick look at the drafs (sorry, I haven't had
> the time to read them thoroughly), and I have a question, and a remark :
>
> designing very fine-grained and flexible exceptions to the general SPF
> rule for a given domain, i.e. per user and subnet.

If using CSV, any exceptions would be per hostname.  As an alternative to
using the exists, which checks for yet another DNS record, simply set up
differing subdomains with different rules.  Although the same games are
possible when referring to a EHLO domain list, I am philosophically
opposed to expecting DNS queries to replace the domain's task of user
authentication.  DNS does not scale well enough to do this task
iteratively, nor can these records grow to the extent needed to allow this
range of exceptions.

> Let's say big-company.com has an SPF record listing their main outgoing
> mail servers, they can easily include supplementary records that would
> list field-people posting from a given ISP server, or a local office
> people using their own local SMTP server, etc.

They could also setup a subdomain that adds this new domain.

> Does CSV have provisions for such a mechanism, or an equivalent ?

CSV identifies the channel.  This channel name can scale well if there is
a desire to restrict mail fields.  The manner these EHLO domains are
referenced allows a great deal of flexibility.  I would suggest a type of
wildcard would find the TXT record, and within the TXT record would be a
list of wildcarded names.

DNS allows exceptions to a wildcard. This would mean that if there is a
record for staff.big-bank.com, this record would be seen.  If there is no
record for staff but just a general record, then *.big-bank.com could
return this query.

> mandatory "accreditation services".

CSV does not require or mandate an accreditation service.  This was added
to allow for a large market of such services to help reduce the number of
services inspected if to discovery an affiliation.

> "accreditation" company to get listed there, if they want their mail to be

CSV allows each MTA to maintain their own name database.  If it is a new
name, offer highly reduced bandwidth.  A simple scheme is used to control
the bandwidth for cable users as example.  This can regulate to any data
rate without changing the content of the packet, without dropping packets,
and requires only a very small amount of memory to achieve this.

> This will introduce costs that many non-profit, personal or vany domains
> will not be able to afford, and I oppose the idea that anybody should have
> to pay a commercial company for being allowed to send mail.

If you do not use such a service, you still benefit.  BATV will help. 
There is nothing that requires anyone use an accreditation service.  It is
completely optional.

> getting blacklisted ;-) and, if some blacklists are commercial, such as
> MAPS, you need to pay to use and query them, not to be listed in them or
> not...

What?  There is no relationship between a MAPS client and those that get
listed. There are several large ISPs that would testify to that!  The
millions of dollars spent servicing legal defenses (never going anywhere)
forced MAPS into a paid service.

> mostly be "unknown" everywhere, and the acceptance of their mail might
> suffer from this.
>
> The advantage of blacklists, on the opposite, is that, if ever you get
> listed, there is probably a reason, and if you're not listed you're
> presumed innocent. Much better.
>
> Comments ?

There are companies that follow the whitelisting model.  As a matter to
reduce legal exposure, MAPS would like to change this to be a simple
statement of past behavior, good or bad.  The longer a domain exists
without problems, the better the domain will look.  The current DNA
proposal does not reflect where I would hope this to be going.  John has
stated he is open to changes.  This is an area that needs work.

-Doug

---

From: Michel Bouissou <[email-masked]>
Date: Wed, 4 Aug 2004 02:10:42 +0200

Le mercredi 4 Août 2004 01:49, Douglas Otis a écrit :
> differing subdomains with different rules.  [...]

> They could also setup a subdomain that adds this new domain.

When you buy a pair of shoes, do you actually look for shoes that fit right to 
your feet, of do you try to force your feet into a given pair ?

A technical solution needs to fit with user needs. You can't ask a company 
"Oh, you just need to change the way your email system works, create a dozen 
of subdomains, change all of your email addresses, and print new business 
cards, and then it will be right for CSV".

SPF allows a kind of flexibility that permits adapting the SPF records to the 
existing infrastructure, far better than having to adapt the infrastructure 
to fit the requirements of the new authentication system.

If a MARID system (any flavour) necessitates that a number of domains have to 
change their infrastructure architecture significantly for using it, it will 
be a show-stopper.

> forced MAPS into a paid service.

I never said that there was a relationship between MAPS clients and those that 
get listed. You completely misunderstood my meaning, or I didn't express 
myself clearly enough (sorry, english is not my language...).

(Parenthese:
BTW, my own perfectly static and never-spammed IP got listed by MAPS-DUL last 
month. It was unlisted within 24 hours after I complained, but it _did_ cause 
me trouble, and for all the users of the domains I manage as well.
A friend's perfectly static IP (at the other end of France) got listed by 
MAPS-DUL the same day, but it took him more than a week to in the end get 
unlisted. He was really, but really, really pissed off with this.
End of off-topic parenthese)

---

From: John Leslie <[email-masked]>
Date: Tue, 3 Aug 2004 20:37:00 -0400

Michel Bouissou <[email-masked]> wrote:
> 
> About CSV, I have taken a quick look at the drafts (sorry, I haven't had

   I prefer to answer the question privately: anyone else wanting my
answer, feel free to ask.

> mandatory "accreditation services".

   I believe accreditation services are expected to be part of any MARID
proposal, not just CSV, so I'll respond to this part on-list.

> "accreditation" company to get listed there, if they want their mail to
> be accepted.

   If there is any "mandate" to use accreditation services, it won't be
coming from MARID. However, burying our heads in the sand won't help:
At best, MARID can verify that a domain intends to authorize particular
actions by MTAs: we can say nothing about whether this authorization
gives the receiver good reason to trust that MTA.

   There must be accreditation services (by whatever name we call them)
to provide that critical information link.

   CSV drafts discuss how to make accreditation scalable (and, IMHO,
easier to live with). I don't believe the chairs ever inteded to stifle
discussion of accreditation services; so I'm happy to discuss those
issues on-list.

   Yes, there will be costs associated with getting accreditation services
to (favorably) list you. I believe we can minimize those costs; and I
believe we can make it possible for many domains to avoid even minimal
costs, so long as they're "well-behaved".

   But I don't believe we can avoid accreditation services altogether.

> This will introduce costs that many non-profit, personal or vanity
> domains will not be able to afford,

   I specifically dispute that. Unless we do nothing at all _and_ an
unlikely series of events all happen, nobody's going to be forced to
register with one central expensive accreditation service. The horror
of having to register with multiple expensive accreditation services
can't (IMHO) get much worse than it already is.

   My recommendation, however, is to design scalable accreditation
processes sooner, not later, so as to reduce the current horror of
trying to get multiple "free" accreditation services to de-list you.

> and I oppose the idea that anybody should have to pay a commercial
> company for being allowed to send mail.

   Conceivably, Michel would actually prefer to spend time trying to
convince a swarm of "free" services to de-list an IP range, rather than
to pay a few dollars to one accreditation service. Personally, I doubt
that's the majority opinion...

> The advantage of current blacklist systems is that no one has to pay
> for getting blacklisted ;-) and, if some blacklists are commercial,
> such as MAPS, you need to pay to use and query them, not to be listed
> in them or not...

   (I'm not clear who is "advantaged" by this.)

> Also, big companies that send large amounts of email will be well-known
> and listed by most, if not all, accreditation services,

   To the extent they pay for it, yes.

   Currently, most accreditation services only list large companies if
they behave poorly. There's essentially no business case for charging
to de-list them: it opens you to too many lawsuits; instead the best
business practice is to make yourself hard to find -- thus, de-listing
is "free" but nearly impossible. :^(

> where little domains, small businesses and individuals that send a
> very small amount of mail will mostly be "unknown" everywhere, and
> the acceptance of their mail might suffer from this.

   From what I know of MAPS, they're capable of handling millions of
domains with low (but non-zero) email volume, and reacting quickly to
just those domains that become the source of problems; and their
business case isn't based on charging either for initial listing _or_
for de-listing. I see no reason other accreditation services wouldn't
build similar business plans.

   I discuss this issue in the CSV FAQ at:

http://www.jlc.net/MARID/CSV/FAQ.html

> "accreditation services" system turn the things upside-down : One
> will be presumed guilty unless listed as innocent. Bad, bad, bad.

   I don't see that kind of "accreditation service" as useful --
though I agree it's going to happen. I believe we can best avoid it
by offering a better alternative.

> The advantage of blacklists, on the opposite, is that, if ever you
> get listed, there is probably a reason,

   Evidently, Michel hasn't experienced blacklisting as I have.
Indeed, there probably "is" a reason; but that doesn't mean anyone
will ever be able to tell you what the reason is -- and even if
they do, it's often something over which you have zero control.

> and if you're not listed you're presumed innocent. Much better.

   Much better for spammers, yes.

   I won't give you "much better" for innocent domains, however, since
you never know when you may get listed somewhere and you usually won't
know what to do about it when it happens.

   At most, it's "temporarily better" for innocent parties...

--
John Leslie <[email-masked]>

---

From: Michel Bouissou <[email-masked]>
Date: Wed, 4 Aug 2004 03:08:55 +0200

> to provide that critical information link.

Do we actually need to have "good reasons to trust a MTA" to start accepting 
mail from it, or do we barely need to be able to stop accepting mail from 
ill-behaved domains once they're flagged as "bad" ?

The current major problem with spam comes from the zombies everywhere, and the 
systematically forged Return-Path, From: and Received: headers.

Once we have a system that ensures that mail is not forged, and comes from a 
MTA that is authorized by the domain to which it belongs, I believe we have 
enough.

If this domain is ill-behaved, it will rather soon get blacklisted at 
spamhaus.org, ROKSO, (put the name of your favourite spam-operations 
blacklist here), and we can soon stop accepting mail from it.
I don't believe that spammers can eternally keep on purchasing tens of 
throw-away domains and change hosting or "their legitimate spam-sending 
servers" everyday.

In this regard, reactive blacklists seems to me to be more useful than 
"accreditation services".

> costs, so long as they're "well-behaved".

Hummm... I think we yet have to see this. And I sincerely wonder if every 
little business and shop-around-the-corner will get its domain listed by such 
"accreditation services".

If they don't (and they mostly won't), then accreditation services won't be of 
that much use, as you will never be able to reject mail from all-the-domains- 
that-are-not-listed, just as today it is impractical to reject mail from all 
the MTAs which doesn't have any PTR in-addr record.

> can't (IMHO) get much worse than it already is.

?

> that's the majority opinion...

The best would be not to be listed at all ;-)

I already have lost some hours a couple of times trying to get delisted, 
sometimes from some ISPs "internal" blacklists that had listed a complete /16 
or the like, and usually, being polite and professional is enough to succeed 
quickly.

Blacklists that keep you listed for no reason and refuse to delist you 
forever, yes, there are some (check my IP at openrbl.org, you'll find ONE 
that keeps a /16 listed and refuses to hear about delisting innocents), but 
such unprofessional blacklists are seldom used by serious companies for mail 
filtering.

> by offering a better alternative.

...which would be...?

>    Evidently, Michel hasn't experienced blacklisting as I have.

As you have, I don't know, but yes, and enough for me anyway ;-)

---

From: "Douglas Otis" <[email-masked]>
Date: Tue, 3 Aug 2004 18:42:38 -0700 (PDT)

>> > - Question : SPF currently has the extremely useful and flexible
>> > "exists" mechanism, that, combined with its built-in macro-expansion,
>> > allows for designing very fine-grained and flexible exceptions to the
>> > general SPF rule for a given domain, i.e. per user and subnet.
>>
>> If using CSV, any exceptions would be per hostname.  As an alternative
>> to using the exists, which checks for yet another DNS record, simply set
>> up differing subdomains with different rules.  [...]
>
> When you buy a pair of shoes, do you actually look for shoes that fit
> right to your feet, of do you try to force your feet into a given pair ?
>
> "Oh, you just need to change the way your email system works, create a
> dozen of subdomains, change all of your email addresses, and print new
> business cards, and then it will be right for CSV".

You are referring to a desire to restrict the use of an address to their
servers.  This may be good for a large enterprise such as a bank wishing
to constrain where these messages may emerge.  This restriction depends
upon the receiving MTA checking for this request, or it means nothing. 
The normal use of mail today does not offer this restriction.  Whether
there is such a constraint, making the EHLO domain visible would still be
helpful in guarding against spoofing.

The feet needing shoes do not wish to have a nail poking them in the heel.
 SPF or Sender-ID puts a burden upon those using mail in a normal fashion.
 That would be sending mail without regard to the point of access.  SPF or
Sender-ID allows this mode, but at a high cost.  Domains not imposing this
new restriction should then expect their DNS record to be used as a spam
exploit.  If big-bank.com wants to have exceptions to this rule, then yes,
I am suggesting this be done by using a subdomain.  I would not expect a
mail list name would need to appear on someone's business card.

> SPF allows a kind of flexibility that permits adapting the SPF records to
> the existing infrastructure, far better than having to adapt the
> infrastructure to fit the requirements of the new authentication system.

SPF and Sender-ID breaks forwarding as example.  Sender-ID decided to
limit the time these extensions may cause, but this solution ignores the
UDP exponential back-off requirement.  DNS records must be constrained and
not allowed to grow to such an extent.  One or two sequential lookups per
message is far better than hundreds as now defined.  SPF limited recursion
and not the number.  For a very brief period, Sender-ID limited the number
of queries.  This is out of control, in my opinion.

If big-bank.com wants to have different rules for different users, giving
these users a different subdomain is not asking to much.  SPF and
Sender-ID want all forwarding and "exploding" list servers to change. 
That is a shoe that does not fit.

> If a MARID system (any flavour) necessitates that a number of domains have
> to change their infrastructure architecture significantly for using it, it
> will be a show-stopper.

You are describing the effect of imposing a restriction on a domain, but
are then unhappy with problems this restriction may cause.  It seems fair
to have those making the changes, endure the impact.  Sender-ID and SPF
impose their change on others, and ask domains, without any desire to make
these restrictions, to suffer.

Employing CSV and making <From:EHLO> a visible "Mailer-ID" will not impact
anyone, but will stop spoofing, phishing, and curtail Trojans.  That can
not be said of Sender-ID or SPF.  Frankly, any large enterprise that wants
to nail down where their emails emerge should also have VPN to allow these
messages to come from the machines they designate.

>> millions of dollars spent servicing legal defenses (never going
>> anywhere) forced MAPS into a paid service.
>
> I never said that there was a relationship between MAPS clients and those
> that get listed. You completely misunderstood my meaning, or I didn't
> express myself clearly enough (sorry, english is not my language...).

There is no relationship with those that don't as well.

> (Parenthese:
> BTW, my own perfectly static and never-spammed IP got listed by MAPS-DUL
> last month. It was unlisted within 24 hours after I complained, but it
> _did_ cause me trouble, and for all the users of the domains I manage as
> well.  A friend's perfectly static IP (at the other end of France) got
> listed by MAPS-DUL the same day, but it took him more than a week to in
> the end get unlisted. He was really, but really, really pissed off with
> this.

Yes, vetting by address sucks in a big way.  I will say that the DUL list
is responsible for stopping the majority of the abuse, but is also
responsible for much of our service overhead.  The information we get from
ISPs is not always perfect.  Many don't know what is assigned.

The CSV approach would not step on the toes of the innocent as does
address blacklisting addresses.  Blacklisting, as will CSV, curtails spam.
Proponents of Sender-ID must not claim to provide a reduction in spam,
spoofing, or phishing.   CSV can provide a reduction in spam, phishing,
and spoofing, without any additional records added to impose domain
restrictions.  Just show the user the <From:EHLO> and that would be a
world of improvement over today's problems.  It would not require any
changes to anyone's use of mail, as does Sender-ID.  If you wish to add
the ability to contrain what EHLO can post a From domain, then those
making this change may need to do things a bit differently, but that is
only fair.  These records will never become a spam exploit as will
Sender-ID or SPF records.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 04 Aug 2004 15:42:36 +0200

> http://www.ietf.org/internet-drafts/draft-schlitt-marid-spf-from-hdr-00.txt

That's the first time I see this.  It's not on the page with
the MARID drafts (see <http://purl.net/xyzzy/-ietf/marid>),
it's not on <http://spf.pobox.com/rfcs.html>, IIRC it was not
published on the SPF announce list, and if it was mentioned on
the SPF-discuss list I must have missed it:

| Comments on this draft are welcome.  In the interests of
| openness, before contacting the authors directly, please
| post to the spf-discuss mailing list.

The date says July 12 2004.  The algorithm is incompatible with
SPF classic, therefore it cannot be used with existing v=spf1
sender policies.

| There are no changes in semantics to existing protocols

That's not true.

IP okay for xyzzy:        SPF classic  SPF/FROM-HDR
MAIL FROM:<valid@xyzzy>   PASS         PASS only if whitelisted
2822 From:<some@example>  don't care   (FAIL => test MAIL FROM)

IP not okay for xyzzy:    SPF classic  SPF/FROM-HDR
MAIL FROM:<[email-masked]> UNKNOWN      (UNKNOWN in step 3)
2822 From:<valid@xyzzy>   don't care   FAIL (step 5)

IP okay for spam@test:    SPF classic  SPF/FROM-HDR
MAIL FROM:<forged@xyzzy>  FAIL         don't care
2622 From:<spam@test>     don't care   PASS (step 1)

I'm not really interested in the 1st example, because I don't
use arbitrary 2822 From headers with a SPF-protected MAIL FROM.

But the 2nd example is real and almost the same problem as with
Sender-Id.  In fact it's even worse because Sender-Id at least
allowed to use a matching Sender:<[email-masked]> to bypass its
2822 From:-test.

And the 3rd example is evil, SPF/FROM-HDR results in a PASS,
but the bounce for this spam is later sent to a 3rd party (?)

What's the purpose of step 2 spf_test(To:,IP) ?  Bye, Frank

---

From: wayne <[email-masked]>
Date: Wed, 04 Aug 2004 10:03:46 -0500

> the SPF-discuss list I must have missed it:

This I-D is not on the page of MARID drafts because it is not an
official MARID document.

You are correct that it wasn't announce anywhere.  This I-D is part of
the "Unified-SPF" group of I-Ds that Meng et al talked about
publishing several weeks back.  It was decided that that the
Unified-SPF I-Ds should be delayed until after the work from this
group had progressed a little further.  Unfortunately, due to some
miscommunication, I didn't hear about the decision to delay until
after I had already submitted the Unified-SPF/From: draft.

Since only two parts of the Unified-SPF I-Ds have been published (the
marid-protocal I-D and the Unified-SPF/From: I-D), none of us have
made a big deal over the existence of the Unified-SPF/From: I-D.  I
mentioned it in response to Doug's post simply to point out that his
general idea has been talked about quite a bit and, in fact, work has
already progressed on the idea of checking only the From: header and
whitelisting exceptions.

> SPF classic, therefore it cannot be used with existing v=spf1

The Unified-SPF/From: algorithm is not intended to replace the
SPF-classic algorithm (Unified-SPF/MAILFROM).  I think that Meng, Mark
and I are all of the opinion that existing SPF records can be used
with the various Unified-SPF checks.  This is really no different than
Sender ID checking existing SPF records.  (Equivalent functionality to
marid-core was written up as the Unified-SPF/PRA I-D.)

> | There are no changes in semantics to existing protocols

This line was copied from boilerplate versions of the Unified-SPF
I-Ds.  I believe that what Mark meant by it is that it doesn't change
things like RFC2822 or RFC2821.

> use arbitrary 2822 From headers with a SPF-protected MAIL FROM.

This is a common case for mailing lists and such.  Yes, the
Unified-SPF/From: I-D requires you to whitelist mailing lists that you
have subscribed to.

> allowed to use a matching Sender:<[email-masked]> to bypass its

I'm not sure what exactly the problem with this is.  If I understand
things correctly, someone used MSA.test to submit a message claiming
to be from valid@xyzzy, but xyzzy doesn't say that MSA.test is an ok
source for such email.

> but the bounce for this spam is later sent to a 3rd party (?)

The idea of the Unified-SPF suite of I-Ds was that you would check any
and all identities that you want to.  Your choices are
Unified-SPF/MAILFROM, Unified-SPF/HELO, Unified-SPF/PTR,
Unified-SPF/PRA and Unified-SPF/From:.  If you want to protect both
the MAIL FROM and the From: header, you would need to do both
Unified-SPF/MAILFROM and either Unified-SPF/PRA or Unified-SPF/From:.

> What's the purpose of step 2 spf_test(To:,IP) ?  Bye, Frank

Whitelisting the To: address is something that SpamAssassin does.  It
allows many emails sent through mail forwarders to be whitelisted.  If
I send email to <[email-masked]>, and it gets passed onto
<[email-masked]), the email will be coming from an IP address associated
with forwarder.tld.  Since [email-masked] has been involved with the
creation and running of this forwarding relationship, they can easily
whitelist it.

Similarly, most mailing list traffic will contain the mailing list
address on the To: header.

In a real-world implementation of the Unified-SPF/From: system, much
of the needed whitelisting can be automated.  For example, using the
To: header, you can determine likely HELO and MAIL FROM domains that
should be used as a fall back when someone sends email with a CC: or
BCC: to a forwarder or a mailing list.  (Hmmm... I should check to see
if SpamAssassin considers CC: to be equivalent to the To: header for
their whitelisting.)

I think that Unified-SPF/MAILFROM (aka SPF-classic) is the safest
check, but people really want to also protect the From: header.  As a
result you can use Unified-SPF/PRA (aka Sender ID), but this doesn't
really protect the From: header and appears to have a much higher
error rate than SPF-classic).  Or you can use Unified-SPF/From: which
requires whitelisting.  I strongly suspect that Unified-SPF/From: can
be made to have a much lower error rate than PRA if there is a good
interface to the whitelisting in the MUA.

-wayne

---

From: Michel Bouissou <[email-masked]>
Date: Wed, 4 Aug 2004 17:17:03 +0200

> creation and running of this forwarding relationship, they can easily

If you whitelist the "To: " corresponding to your address at the forwarder, 
you will whitelist all the spam sent to this address, won't you ?

Unless you rely on the forwarder itself to perform the checks and reject 
failures in the first place...?

It is most probable that the address @your_forwarder is the address that you 
publicly communicate the most as "this is my permanent address", where your 
actual destination address @your_isp may vary when you change ISP, and you 
may want to keep it private. A lot of people proceed this way...

Thus, the address @your_forwarder will be the address that will receive the 
bigest quantity of spam, viruses and forgeries...

Did I miss something ?

---

From: wayne <[email-masked]>
Date: Wed, 04 Aug 2004 10:43:20 -0500

In <[email-masked]> Michel Bouissou <[email-masked]> writes:

>> allows many emails sent through mail forwarders to be whitelisted. 
>

Yes, this is also true for SPF-classic (Unified-SPF/MAILFROM) and
SenderID (Unified-SPF/PRA).

> failures in the first place...?

Right, mailing lists and forwarders need to do a good job of spam
filtering and in my opinion, that includes SPF checks.  However, if
someone chooses to use a poorly run forwarder, or simply wants no spam
filtering done for the forwarded address, that is up to them.

> Did I miss something ?

Nope.

-wayne

---

From: "John Glube" <[email-masked]>
Date: Wed, 4 Aug 2004 13:02:09 -0400

Frank

The drafts Wayne is referencing were discussed on the SPF
discuss list in June and July.

These drafts did not make it to the IETF table. Instead we
had revised SPF, Sender-ID and Submitter.

With the realization we continued to have an IPR and
licensing issue with the existing Sender-ID draft, Wayne
suggested a substitution.

Last night I raised the Unified theory as a work around to
many of these problems.

http://www.imc.org/ietf-mxcomp/mail-archive/msg03007.html

This morning, Andy kindly informed the list the chairs had
decided to solicit reviews of Sender-ID within the time 
frame of the WG schedule.

The Agenda calls for discussion of the IPR issue and the
PRA algorithm this afternoon. 

I made a further post early this morning concerning these
issues, following up on Harry's comments concerning
Microsoft's difficulties filing an IPR.

http://www.imc.org/ietf-mxcomp/mail-archive/msg03010.html

In this post I referenced dealing with the issues raised at 
the meeting in the morning. This was an error on my part. 

If the Unified Theory is to be the work around, subject to
guidance from the WG chairs, it seems it has to come
forward during the review of the IPR and PRA algorithm in
the afternoon. 

In turn this would allow the chairs to solicit reviews
within the WG's time frame of at least the 'Sender-ID'
portion. 

This in turn would facilitate finalizing the needed drafts
so the WG can meet its time lines.

Also, one other point. Should people decide to proceed in
this direction, instead of calling it Unified Marid or
Unified SPF why not call it Unified Sender-ID?

I apologize if these matters have already been discussed at
the meeting and I am raising something which is not
necessary.

John

cc. Andy, Meng, Mark, Dave, Harry and Jim

John Glube
Toronto, Canada

---

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 05 Aug 2004 10:31:59 +0200

wayne wrote:

> This I-D is part of the "Unified-SPF" group of I-Ds that
> Meng et al talked about publishing several weeks back.

For some obscure reasons I always thought that "unified SPF"
is the same as "MARID SPF" (protocol-00 and core-02).  I don't
count "submitter" because anything allowing bounces to a third
party is IMHO a perversion of classic SPF resp. RMX.

> I didn't hear about the decision to delay until after I had
> already submitted the Unified-SPF/From: draft.

No problem with that as long as I'm not supposed to grep the
I-D list to find new SPF / MARID drafts.

> in fact, work has already progressed on the idea of checking
> only the From: header and whitelisting exceptions.

2822 From: headers are not necessarily related to the original
RMX / SPF problem, i.e. useless bounces caused by billions of
forged MAIL FROM addresses.  Classic SPF will solve my problem,
and I'm very reluctant to consider "better" solutions breaking
legacy software.

> I think that Meng, Mark and I are all of the opinion that
> existing SPF records can be used with the various Unified-SPF
> checks.

 From my POV that's not the case, one of my mail providers has
not implemented the "MSA MAY" RfC 2476 8.1.  Sender-Id changes
this implicitly to a SHOULD or even a MUST.  But maybe I can
convince you that the recipient could simply pretend that this
not yet existing MUST has been done ("default Sender:"), it's
less trouble than different spf1 vs. marid1 sender policies.

> what Mark meant by it is that it doesn't change things like
> RFC2822 or RFC2821.

Okay, but for Sender-id there's a problem with RfC 2476 8.1

> the Unified-SPF/From: I-D requires you to whitelist mailing
> lists that you have subscribed to.

Then it's probably a solution only relevant for MUAs, the MX
of a big ISP can't whitelist mailing lists for all users. (?)

>> 2822 From:<valid@xyzzy>   don't care   FAIL (step 5)
[...]
> I'm not sure what exactly the problem with this is.

That's the RfC 2476 8.1 "MAY", or rather its "maybe not".  My
MUA prepares all outbound messages with From: nobody@xyzzy

Later I send it with via one of two smart hosts, that's either
MAIL FROM:<nobody@xyzzy> or MAIL FROM:<[email-masked]>.  There
is no matching Sender:, and it's "maybe not" inserted.  If you
ask why I use msa.test:

Sometimes (depending on costs and the time of the day, or if
the primary MSA is blocked by a recipient) I cannot use "my"
primary MSA, and then I use the secondary MSA (msa.test).  And
the secondary MSA isn't interested in Sender-Id / RfC 2476 8.1,
it "only" insists on a correct MAIL FROM:<[email-masked]>

> If I understand things correctly, someone used MSA.test to
> submit a message claiming to be from valid@xyzzy, but xyzzy
> doesn't say that MSA.test is an ok source for such email.

That's it.  xyzzy is only a vanity host with a wildcard sender
policy, and my primary ISP has no reason to change this, after
all I can use its MSA as long as I'm online with this ISP.  If
I use another dialin ISP then that's my problem.  OTOH the 2nd
MSA also has no compelling reason to implement RfC 2476 8.1: I
could add a matching Sender: manually (for Sender-Id).

But for SPF/FROM-HDR even a manually added Sender: won't work.
Okay, I could still modify From: into ReplyTo:, and then add a
new matching From: manually, but that's a very clumsy solution.

> you would need to do both Unified-SPF/MAILFROM and either
> Unified-SPF/PRA or Unified-SPF/From:.

This _and_ is very important.  Maybe we should mention it in
SPF/PRA resp. SPF/FROM, these tests make no sense without a
prior SPF/MAILFROM test.  The important thing is SPF/MAILFROM,
and at the moment we have no draft for SPF/MAILFROM (= the old
draft-mengwong-spf-01.txt minus all stuff now covered by MARID
protocol-00.txt).

>> What's the purpose of step 2 spf_test(To:,IP) ?

> Whitelisting the To: address is something that SpamAssassin
> does.  It allows many emails sent through mail forwarders to
> be whitelisted.

So far that's clear.

> If I send email to <[email-masked]>, and it gets passed
> onto <[email-masked]), the email will be coming from an IP
> address associated with forwarder.tld.

That's also clear.

> Since [email-masked] has been involved with the creation and
> running of this forwarding relationship, they can easily
> whitelist it.

ACK, now I got it, To: [email-masked] and the forwarding IP
should be matched by the sender policy of forwarder.tld, and
that's something the MUA of [email-masked] knows.  But again a
case which won't work at the MX of isp.tld for big ISPs.

> people really want to also protect the From: header.

More than 1000 useless bounces to "my" catch-all vanity domain
per day are a much more pressing problem for me.

> I strongly suspect that Unified-SPF/From: can be made to
> have a much lower error rate than PRA if there is a good

Maybe.  But things are really confusing if the recipient either
tests this or tests that, and I as sender don't know how my
sender policy is interpreted today.  I'd prefer a KISS solution
where sender policies only for SPF/MAILFROM are possible.

                           Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 05 Aug 2004 11:04:18 +0200

> suggested a substitution.

Yes, that point was clear.  But as I said on the SPF list
some days ago, IANAL and more interested in technical details.

All drafts based on SPF protocol-00 test "something" against a
IP and a sender policy in a certain more or less obvious order.
I don't see how anybody could patent the order of these tests.

The semantics of Sender; / From: / Return-Path: is "prior art",
and even the people who invented the internet can't claim that
this is new.

> Last night I raised the Unified theory as a work around to

Okay.  Then we'd still need a separate SPF/MAILFROM text for
the classic SPF test, and some technical corrections in SPF
protocol-00 (ABNF-issues, typos, RfC 3849 for IPv6 examples).

                          Bye, Frank

---

From: Meng Weng Wong <[email-masked]>
Date: Fri, 6 Aug 2004 09:47:22 -0400

On Thu, Aug 05, 2004 at 10:31:59AM +0200, Frank Ellermann wrote:
| 
| This _and_ is very important.  Maybe we should mention it in
| SPF/PRA resp. SPF/FROM, these tests make no sense without a
| prior SPF/MAILFROM test.  The important thing is SPF/MAILFROM,
| and at the moment we have no draft for SPF/MAILFROM (= the old
| draft-mengwong-spf-01.txt minus all stuff now covered by MARID
| protocol-00.txt).
| 

Actually, we do.  There is a set of drafts out there that
collectively describe the "unified" model.  They have not
been published to the list for fear of distraction; given
the tight time constraints, it seems prudent to focus on
getting Sender ID off the ground before opening the door to
more theoretical discussion.  But I will mention them
for the record, and because there has been some interest in
the past in defining the term "Unified SPF".

At the WG meeting, some folks suggested we should extract
the PRA algorithm from the core document because it has
general utility in the 2822 space independent of MARID work.

That refactoring represents a step in the direction of the
unified drafts.

The "unified" document describes the overall structure.

The "protocol" document describes the SPF test.

"ptr", "helo", "mailfrom", and "pra" describe the semantics
of the SPF test in the context of each identity.

"best" shows how the four instances interact.

The documents at http://spf.pobox.com/unified/id/ are a
rough draft.  They represent only my take (together with
Mark) on another way to present Sender ID.  I have no plans
to submit them as I-Ds.  They have informational value at
best.  I hope they are a constructive contribution.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 6 Aug 2004 23:40:04 -0700

Meng,

MWW> Actually, we do.  There is a set of drafts out there that
MWW> collectively describe the "unified" model.

"out there" is not meaningful for an IETF working group, as has been
pointed out a few times.

if you want the IETF to consider some work, you need to bring that work
to it. Talking about it -- as you have done since you introduced it to
the list and continue on with your latest posting -- without bringing
the documents in, is not just distracting, it is confusing.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: "James Pullicino" <[email-masked]>
Date: Sat, 7 Aug 2004 11:20:25 +0200

>> I have no plans to submit them as I-Ds.  They have
>> informational value at best.  I hope they are a
>> constructive contribution.

Thanks Meng, I found pleny of value in these drafts. They look promising. I
would like to see them put forward to IETF one day.

Regards,

James Pullicino

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Meng Weng Wong
Sent: Friday, August 06, 2004 3:47 PM
To: Frank Ellermann
Cc: [email-masked]
Subject: "unified spf"

---
Mail Scanned
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.692 / Virus Database: 453 - Release Date: 5/28/2004

---

From: John Leslie <[email-masked]>
Date: Sun, 8 Aug 2004 17:33:23 -0400

Michel Bouissou <[email-masked]> wrote:
> Le mercredi 4 Ao?t 2004 02:37, John Leslie a ?crit :
>>
> Do we actually need to have "good reasons to trust a MTA" to start
> accepting mail from it, or do we barely need to be able to stop
> accepting mail from ill-behaved domains once they're flagged as "bad" ?

   This is a distinction without a difference: we need "good enough"
reasons to trust the MTA using that EHLO domain-name.

   "Good enough" is in the eye of the beholder.

   Hopefully, most sites will accept email from previously-unknown domains
until the first instance of abuse (which can be propagated by reputation
services within seconds); and accept email from previously-trusted domains
until a pattern of abuse (possibly extending over several days) is seen.

   But all of that is a local option; and local options will drive the
kinds of reputation services which are widely used.

   (Fortunately, there's a gray area between accept-unconditionally and
reject-unconditionally, involving various devices like rate-limiting.)

> Once we have a system that ensures that mail is not forged, and comes
> from a MTA that is authorized by the domain to which it belongs, I
> believe we have enough.

   Not everyone will agree with you...

> blacklist here), and we can soon stop accepting mail from it.

   ... a particular kind of reputation service which I'm sure will
continue...

> throw-away domains and change hosting or "their legitimate spam-sending 

   Time will tell...

> "accreditation services".

   Reactive blacklists are one kind of reputation service. The importance
of accreditation services is to allow a mechanism to automate recovery
from listing by reactive blacklists.

> Hummm... I think we yet have to see this. And I sincerely wonder if
> every little business and shop-around-the-corner will get its domain
> listed by such "accreditation services".

   Most likely not... until they run afoul of blacklists.

> If they don't (and they mostly won't), then accreditation services
> won't be of that much use, as you will never be able to reject mail
> from all-the-domains-that-are-not-listed, just as today it is
> impractical to reject mail from all the MTAs which doesn't have any
> PTR in-addr record.

   I don't believe anyone in MARID is seriously proposing to reject all
email which isn't listed. (The closest I've heard of is delaying email
which doesn't come from a "listed" MTA; and that wasn't proposed for
everyone: just for a few domains in order to jump-start implementation.)

>> convince a swarm of "free" services to de-list an IP range, rather
>> than to pay a few dollars to one accreditation service. Personally,
>> I doubt that's the majority opinion...
> 

   Not always possible...

> sometimes from some ISPs "internal" blacklists that had listed a
> complete /16 or the like, and usually, being polite and professional is
> enough to succeed quickly.

   "Usually" may not be good enough; and "some hours" may be more expensive
for some than for others. (Not to mention the cases where you don't even
learn which service is blacklisting you.)

> forever, yes, there are some (check my IP at openrbl.org, you'll find
> ONE that keeps a /16 listed and refuses to hear about delisting
> innocents), but such unprofessional blacklists are seldom used by
> serious companies for mail filtering.

   That they're used at all can be a problem.

>> by offering a better alternative.

   ...accreditation services which list you favorably at minimal charge
until abuse is discovered.