Subject: TECH: use fetchmail algorithm to select header address to verify

From: John Levine <[email-masked]>
Date: 6 Sep 2004 19:30:31 -0000

The widely used fetchmail package includes a section of code that
determines the most likely responsible party for an e-mail message.
Its algorithm is similar to PRA but not identical.

This part of fetchmail was added in about 1996 and has been in daily
use since then by thousands of users all over the world during the
past eight years.  The fetchmail code is under the GPL, but as far as
I know, nobody claims proprietary rights over its algorithms.  Eric
Raymond, whose name is on the 2001 copyright notice in the file,
doesn't.  Since it was published so long ago it's unlikely that any
claims are yet to surface.

It checks headers in the following order:

Return-Path:  (envelope MAIL FROM address, as noted in code below)
Resent-Sender:
Sender:
Resent-From:
From:
Reply-To:
Apparently-From:

My proposal is to use this scheme to determine the address to check,
perhaps deleting the Apparently-From: check since it's not a header
that's ever appeared in an RFC.  One can argue whether this is the
best possible set and order of headers to check, but since it's worked
in practice for so long, I see no reason to mess with it.

If there's interest in this, I'd be happy to help write it up as an
I-D.  Personally, I don't think that any sort of sender domain vs. IP
address check is particularly useful as an anti-spam or anti-forgery
measure, but since MARID seems determined to publish something along
those lines, it might as well use the best proven technology
available.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"I shook hands with Senators Dole and Inouye," said Tom, disarmingly.

--- lines 918-946 of transact.c from fetchmail 6.2.0 ---
    /*
     * If there is a Return-Path address on the message, this was
     * almost certainly the MAIL FROM address given the originating
     * sendmail.  This is the best thing to use for logging the
     * message origin (it sets up the right behavior for bounces and
     * mailing lists).  Otherwise, fall down to the next available 
     * envelope address (which is the most probable real sender).
     * *** The order is important! ***
     * This is especially useful when receiving mailing list
     * messages in multidrop mode.  if a local address doesn't
     * exist, the bounce message won't be returned blindly to the 
     * author or to the list itself but rather to the list manager
     * (ex: specified by "Sender:") which is much less annoying.  This 
     * is true for most mailing list packages.
     */
    if( !msgblk.return_path[0] ){
	char *ap = NULL;
	if (resent_sender_offs >= 0 && (ap = nxtaddr(msgblk.headers + resent_sender_offs)));
	else if (sender_offs >= 0 && (ap = nxtaddr(msgblk.headers + sender_offs)));
	else if (resent_from_offs >= 0 && (ap = nxtaddr(msgblk.headers + resent_from_offs)));
	else if (from_offs >= 0 && (ap = nxtaddr(msgblk.headers + from_offs)));
	else if (reply_to_offs >= 0 && (ap = nxtaddr(msgblk.headers + reply_to_offs)));
	else if (app_from_offs >= 0 && (ap = nxtaddr(msgblk.headers + app_from_offs)));
	/* multi-line MAIL FROM addresses confuse SMTP terribly */
	if (ap && !strchr(ap, '\n')) {
	    strncpy(msgblk.return_path, ap, sizeof(msgblk.return_path));
	    msgblk.return_path[sizeof(msgblk.return_path)-1] = '\0';
	}
    }

---

From: Sam Varshavchik <[email-masked]>
Date: Mon, 06 Sep 2004 16:18:14 -0400

> claims are yet to surface.

I like this.

Combine this with SPF-classic, and you have a functional, unencumbered 
alternative to Sender-ID.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 6 Sep 2004 22:26:36 +0200

On Mon, Sep 06, 2004 at 07:30:31PM -0000,
 John Levine <[email-masked]> wrote 

> My proposal is to use this scheme to determine the address to check,

Nice idea but, as discussions on this group showed, there is little
hope to have a consensus on this algorithm. Hence the "unified SPF"
(http://spf.pobox.com/unified/) idea which disconnects the protocol
and the DNS RR from the choice of the domain used for the
validation. "Unified SPF" gives you several choices for this domain
and your (fetchmail's) algorithm could be one of them.

> I-D.

Good idea, but as a part of "Unified SPF", like PRA is (see
http://spf.pobox.com/unified/7-pra.txt as an example).

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 06 Sep 2004 17:05:49 -0400

> alternative to Sender-ID.

Lets see if taking PRA out will take care of IPR in marid-core.

Yakov

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 06 Sep 2004 17:04:27 -0400

> and your (fetchmail's) algorithm could be one of them.

The consensus if any so far has been in regards to PRA. I haven't seen 
anybody posting yet in regards to this one.

Personally, I am very for using fetchmail's algorithm if it helps take 
care of the IPR issues. But there is still IPR issues with marid-core 
and I am not sure if this will take care of it.

Yakov

---

From: Roy Badami <[email-masked]>
Date: Mon, 6 Sep 2004 22:22:54 +0100

>>>>> "John" == John Levine <[email-masked]> writes:

    John> The widely used fetchmail package includes a section of code
    John> that determines the most likely responsible party for an
    John> e-mail message.  Its algorithm is similar to PRA but not
    John> identical.

I think the fetchmail algorithm is a red herring.  It basically boils
down to: determine the envelope sender from the headers.  If you've
got a broken MTA, then use an algorithm which is similar to the PRA.
If that fails, there's yet another fallback.

If we're doing this at the SMTP level -- which is the prefered place
for the MARID check -- then the envelope sender is always known,
without any recourse to the headers, to this just boils down to using
the envelope sender (a la SPF).

Having an a complex fallback algorithm solely for use with post-SMTP
checkers that live behind broken MTAs seems the wrong solution for
MARID (though it was the correct engineering approach for fetchmail).

	-roy

---

From: "Michel Bouissou" <[email-masked]>
Date: Tue, 7 Sep 2004 00:17:09 +0200 (CEST)

> claims are yet to surface.

This finding is excellent and the idea is very smart. IANAL, but I believe
this is clearly and doubtlessly old enough "prior art" in determining the
purported sender of a message by checking the presence of a succession of
defined headers in an email, no matter what exact headers are used, this
is blatantly similar to the PRA method.

I believe this should probably be enough to invalidate any pretention from
MS of owning the "property" of such an "invention", and probably breaks
the validity of their (yet undisclosed precisely) patent claim.

(Anyway, even if this is really good news on the PRA standpoint, I still
personally technically much prefer that we should stick to 2821 MAIL FROM
as Classic-SPF does.)

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

paléogallicisme : style "vieille France"

---

From: Dave Crocker <[email-masked]>
Date: Tue, 7 Sep 2004 07:39:28 +0900

Roy,

RB> If we're doing this at the SMTP level -- which is the prefered place
RB> for the MARID check -- then the envelope sender is always known,
RB> without any recourse to the headers, to this just boils down to using
RB> the envelope sender (a la SPF).

   I assume you are not talking about SUBMITTER.

   Because there is no such value as "envelope sender".

   Hopefully, you do not mean the bounce address, MailFrom, since of
   course it need not correlate with sender or from at all.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 06 Sep 2004 18:51:17 -0400

> the validity of their (yet undisclosed precisely) patent claim.

Even if there isn't enough time for the lawyers to get back to us, 
nevertheless an alternative draft without IPR problems should be 
preferred according to RFC 3668, section 8 unless it is superior:

"  In general, IETF working groups prefer technologies with no known IPR
    claims or, for technologies with claims against them, an offer of
    royalty-free licensing. But IETF working groups have the discretion
    to adopt technology with a commitment of fair and non-discriminatory
    terms, or even with no licensing commitment, if they feel that this
    technology is superior enough to alternatives with fewer IPR claims
    or free licensing to outweigh the potential cost of the licenses.
"

Yakov

---

From: "Michel Bouissou" <[email-masked]>
Date: Tue, 7 Sep 2004 00:57:07 +0200 (CEST)

Yakov Shafranovich a écrit :
>>
>> I believe this should probably be enough to invalidate any pretention
>> from MS of owning the "property" of such an "invention", and probably
>> breaks the validity of their (yet undisclosed precisely) patent claim.
>

Sure, I definitely share this point of view.

---

From: Roy Badami <[email-masked]>
Date: Tue, 7 Sep 2004 00:19:28 +0100

>>>>> "Dave" == Dave Crocker <[email-masked]> writes:

    Dave>    Because there is no such value as "envelope sender".

I use the term "envelope sender" to mean the MAIL FROM address.  I
regard this as common usage.

The purpose of fetchmail is to obtain mail by verious means (often POP
or IMAP) that may not give direct access to the envelope, and to
reinsert the mail into the SMTP stream.

It is typically used by people who have POP accounts but want to
deliver their mail to an MTA on a local machine.

In order to do this it needs to determine a "sensible" value to use
for the SMTP MAIL FROM when transfering the mail to the local MTA.  As
you'll see from the posted algorithm, it's first choice is to use the
*actual* previous value of the MAIL FROM, as identified by the
Return-Path header.  If this isn't available, as a fallback it appears
to use something very similar to the PRA algorithm, with a couple of
extra cases at the end.

As I said before, this is a red herring.  The only reason the
fetchmail algorithm exists is because it has to operate in an
environment where the value of MAIL FROM isn't available.

I don't see its relevent to MARID work.

    -roy

---

From: Dave Crocker <[email-masked]>
Date: Tue, 7 Sep 2004 08:32:51 +0900

Roy,

RB> I use the term "envelope sender" to mean the MAIL FROM address.  I
RB> regard this as common usage.

that would be fine, except that it is not the semantics of that field,
and using that term has caused significant confusion.  and all of this
has been discussed extensively on this list and other.

the more recent and accurate term that has attained 'common usage' is
"bounce address".

unless and until these discussions start using terminology carefully,
there is no hope of achieving consensus that means anything.

d/

---

From: [email-masked]
Date: Mon, 06 Sep 2004 17:07:38 -0700 (PDT)

> regard this as common usage.

I'm not sure it is common usage, but that's certainly how I interpreted
it.

> I don't see its relevent to MARID work.

Nice analysis. I completely agree with it. The algorithms may be similar
but their goals are quite different.

				Ned

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 06 Sep 2004 21:01:51 -0400

> I don't see its relevent to MARID work.

What about the algorithms here:

http://email.uoa.gr/projects/fromfilter/doc/fromfilter.html#toc9

and

http://docs.sun.com/source/816-6091-10/contents.htm#CONVERSION

"The email message's originator address is taken from one of the 
following five sources, shown in decreasing order of preference:
1. Resent-from:	 	4. Sender:	
2. From:	 	5. Envelope From:	
3. Resent-sender:"

---

From: Roy Badami <[email-masked]>
Date: Tue, 7 Sep 2004 02:10:58 +0100

> 2. From:	 	5. Envelope From:	

What about it?

The PRA algorithm isn't arbitrary; it's based on the RFC(2)822
definitions of the fields.

The above algorithm makes no sense to me.  The fact that someone has
used it for something in the past is not a justification for using it
here.

	-roy

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 06 Sep 2004 21:32:39 -0400

> definitions of the fields.

So let me get this straight. RFC 2822 (section 3.6.2) defines "Sender" 
as "mailbox of the agent responsible for the actual transmission of the 
message" which would be the party that actually put the email message 
into the initial SMTP transaction. The same RFC (section 3.6.6) 
represents "one individual" who "resends a message on behalf of one or 
more others".

Now, I am an SMTP developer and after reading the RFC I want to find out 
who put the original message into the mail system. In order to determine 
the actual party who sent the original message according to the RFC I 
would have to look for the "Sender" field. If it is not present, then 
the "From" header is used since the RFC states (section 3.6.2) "if the 
originator of the message can be indicated by a single mailbox and the 
author and transmitter are identical, the "Sender:" field SHOULD NOT be 
used." However, since the same RFC states that "Resent" fields are 
basically the same as the regular "Sender" and "From" fields in cases 
where the email is forwarded and re-introduced into the email system, I 
would have to parse "Resent-Sender" first, then "Resent-From", and only 
after that the regular "Sender" and "From" fields.

Now if all of this is stated in the RFC directly, what exactly is the 
IPR that is being claimed here? This seems to me explicit in the RFC itself.

> used it for something in the past is not a justification for using it

I will agree with you that it will not sufficient for our purposes where 
we care about the original party who put the email into the email 
system, not the original author of the message, but it might be good 
enough for prior art.

Yakov

---

From: [email-masked]
Date: Mon, 06 Sep 2004 18:35:29 -0700 (PDT)

> 2. From:	 	5. Envelope From:

I can't speak to the fromfilter algorithm, but the algorithm you dug out of
Sun's documentation is one of a family of algorithms designed to be used as
part of a gateway from Internet mail, with its rich set of addressing fields,
to some other system (in this case SMS) with a relative paucity of fields. The
intent of these algorithms is to assign a certain set of semantics to replies
generated by the more limited environment. Similar algorithms have been devised
for many such systems, including but not limited to cc:Mail, Microsoft Mail,
WordPerfect Office, Novell MHS, and VMS MAIL.

Given that the intent of PRA is to derive a responsible address, not to
determine a place to send replies, I consider all of these to be red herrings
as well, albeit ones pulled out of a different kettle.

				Ned

---

From: wayne <[email-masked]>
Date: Mon, 06 Sep 2004 21:43:43 -0500

In <[email-masked]> John Levine <[email-masked]> writes:

>
> [proposed alternative to the PRA deleted]
>
> I-D.  [...]

As much as I would love to discuss this, the co-chairs are repeatedly
asked us to not discuss alternative proposals until such time as we
are finished working on the current I-Ds.  I realize this puts us in
somewhat of a awkward situation, since many people saying, in effect,
that we must go forward with SenderID because it is the only thing
around.

As usual for threads, there has been a certain amount of topic drift,
in this case into the subject of what the PRA and various other
similar algorithms are trying to accomplish.  I think this is an
interesting topic and it isn't clear to me that what the PRA is trying
to accomplish and the "identitity" that it creates is all that useful.
However, I'm not sure that the co-chairs are even interesting in
seeing a drawn out discussion on this either.  I think we were
supposed to discuss that May.

As a result of those discussions back in May, the co-chairs ruled that
we would focus on RFC2821 identities, and the charter says that
discussions of other identities would be ruled out of order.

-wayne

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 06 Sep 2004 23:21:53 -0400

> discussions of other identities would be ruled out of order.

And which exact RFC 2821 identity are we focusing on? Except for 
SUBMITTER I don't see any other one.

Yakov

---

From: "Michael R. Brumm" <[email-masked]>
Date: Mon, 6 Sep 2004 21:54:12 -0600

>SUBMITTER I don't see any other one.

Wayne mistyped and meant RFC 2822 identities.

---

From: "Michael R. Brumm" <[email-masked]>
Date: Mon, 6 Sep 2004 22:22:00 -0600

> the more recent and accurate term that has attained 'common usage' is

 (
  "envelope sender" ==
  "envelope from" ==
  "bounce address" ==
  "2821 from" ==
  "821 from" ==
  "MAIL FROM"
 )

I suppose we could argue about semantics and further digress from the MARID
charter, but all of these terms mean the same and are pretty commonly used
("envelope sender" is certainly one of the more common ones and has been in
use for several decades). Search Google Groups if you disagree.

Michael R. Brumm

---

From: wayne <[email-masked]>
Date: Tue, 07 Sep 2004 00:10:43 -0500

> SUBMITTER I don't see any other one.

Well, SUBMITTER is the explanation that Andy gave me (via personal
email) as to why SenderID and the PRA are 2821 identities.  That
explanation seemed strange to me, but there ya go.

The co-chair ruling on focusing on 2821 identities was posted here:
http://www.imc.org/ietf-mxcomp/mail-archive/msg01161.html

I've brought this subject up a couple of times before, for example at:
http://www.imc.org/ietf-mxcomp/mail-archive/msg02598.html

-wayne

---

From: Graham Murray <[email-masked]>
Date: Tue, 07 Sep 2004 06:54:46 +0100

>    or free licensing to outweigh the potential cost of the licenses.

While IANAL, it could be argued that the Microsoft Sender-ID licence
is not non-discriminatory as it (according to many people here,
including lawyers) discriminates against open-source implementations.

---

From: Graham Murray <[email-masked]>
Date: Tue, 07 Sep 2004 07:08:19 +0100

> after that the regular "Sender" and "From" fields.

And by the same RFC, some of the situations which some discussion on
this last has suggested that Resent-* headers might be inserted (by
the MTA) are not valid usage of those fields. If the mail is
originally addressed to [email-masked] and is then forwarded to my
"real" address [email-masked], then it is valid for alumni.org to add
Resent-* headers. But if example.com sends mail via an ISP or MSP
isp.com then it is not valid (as some have suggested here to enable
the PRA to match) for isp.com to add Resent-* headers to all outgoing
mail from its customers.

---

From: "Michael R. Brumm" <[email-masked]>
Date: Tue, 7 Sep 2004 00:15:09 -0600

> explanation seemed strange to me, but there ya go.

Bah! If so, that's a pretty *interesting* interpretation; interesting as in
"I disagree".

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

Hmmm, I thought the ruling had been changed to use 2822 identities in order
to allow this wonderful collaboration that is SenderID... Thanks for the
background information.

Michael R. Brumm

---

From: David Woodhouse <[email-masked]>
Date: Tue, 07 Sep 2004 09:14:00 +0100

On Tue, 2004-09-07 at 07:08 +0100, Graham Murray wrote:
> Resent-* headers. 

Says §3.6.6 of RFC2822:

   "Resent fields SHOULD be added to any message that is reintroduced by
   a user into the transport system."

Note 'by a user'. This implies that it shouldn't be done when the
message is forwarded automatically. But there's no need for inference --
it's made quite explicit a couple of paragraphs further down:

   "Note: Reintroducing a message into the transport system and using
   resent fields is a different operation from "forwarding".
   "Forwarding" has two meanings: One sense of forwarding is...
             <...irrelevant to us right now ...>     
                               ...On the other hand, forwarding is also
   used to mean when a mail transport program gets a message and
   forwards it on to a different destination for final delivery.  Resent
   header fields are not intended for use with either type of
   forwarding."

It is _not_ valid for 'alumni.org' to add Resent-* headers when
forwarding mail to your current address.

-- 
dwmw2

---

From: Roy Badami <[email-masked]>
Date: Tue, 7 Sep 2004 12:20:20 +0100

>>>>> "Yakov" == Yakov Shafranovich <[email-masked]> writes:

    >> The above algorithm makes no sense to me.  The fact that
    >> someone has used it for something in the past is not a
    >> justification for using it here.
    >> 

    Yakov> I will agree with you that it will not sufficient for our
    Yakov> purposes where we care about the original party who put the
    Yakov> email into the email system, not the original author of the
    Yakov> message, but it might be good enough for prior art.

No.  I mean it simply makes no sense.  Since the from field in
mandatory, the algorithm will never proceed beyond step 2.  Steps 3 to
5 will only ever be reached if the message is malformed.

  -roy

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 7 Sep 2004 13:45:59 +0200

On Mon, Sep 06, 2004 at 09:32:39PM -0400,
 Yakov Shafranovich <[email-masked]> wrote 
 a message of 49 lines which said:

> Now if all of this is stated in the RFC directly, what exactly is
> the IPR that is being claimed here? This seems to me explicit in the
> RFC itself.

We all agree that the patent claim from Microsoft is almost certainly
obvious / frivolous / invalid. Almost all software patents
are. Microsoft is not known for interesting contributions to computer
science, only for massive patent filing (see
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=6,775,781.WKU.&OS=PN/6,775,781&RS=PN/6,775,781
which basically patents every program like sudo or calife).

But it does not solve the issue: should we take the risk? Should we
move to the standards track with such a threat, which will probably
deter many people?

An individual outside of the US (software patents are still illegal in
Europe, see http://swpat.ffii.org/) can do it (I did it in
http://www.imc.org/ietf-mxcomp/mail-archive/msg03656.html, a message
which certainly infringes Microsoft ridiculous IPR claims). But most
organizations will not.

---

From: Andrew Newton <[email-masked]>
Date: Tue, 7 Sep 2004 08:54:23 -0400

On Sep 6, 2004, at 10:43 PM, wayne wrote:

> are finished working on the current I-Ds.

Wayne,

Is your proposal a different algorithm for using the headers?  Or is it 
more than that?

-andy

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 07 Sep 2004 08:59:24 -0400

> move to the standards track with such a threat, which will probably

In the past there have been at least two cases where a WG moved ahead 
with the standard and disregarded the IPR claims as frivilious: IDN and 
Walid patent, and IPSec and UUNet's patent. Therefore, one optionl could 
be to consider the IPR claims as meanigless, especially in light of 
prior art, and move on.

Of course, that only works if deployment is not hindered. Based on the 
Apache and Debian statements, as well as others, it may be too late for 
that.

Yakov

---

From: wayne <[email-masked]>
Date: Tue, 07 Sep 2004 10:20:13 -0500

In <[email-masked]> Andrew Newton <[email-masked]> writes:

> Is your proposal a different algorithm for using the headers?  Or is
> it more than that?

It is a fair amount different than either the PRA or the fetchmail
algorithms.  I believe that protecting the From: header is *CRITICAL*
because it is the only thing that is usually shown by MUAs that are
out in the field today and that is what is needed to stop phishing.
As such, the only header that is checked is the From: header.

As has been pointed out many times, in a (vast?) majority of cases,
email is one hop, person to person, where the 2821.MAILFROM is the
same as the 2822.From:.  I such cases, there is no reason to check
anything other than that single email address and SenderID is already
the same as SPF-classic.

In the cases where the 2821.MAILFROM is not the same as the
2822.From:, most of it is due to some sort of forwarding/redirection
that the end user receiving the email has set up.  For example,
mailing lists and things like acm.org.  In almost all cases, it is
easy to identify something to whitelist on.  Many times, the end user
will not even need tell a spam filter/MUA about it, it can be
automatically determined.

My ideas about this stuff is actually heavily based on the way
SpamAssassin does its auto-whitelists.

There are cases that my method doesn't work very well on.  For
example, if a company outsources their email for things like customer
web orders and wants a different 2821.MAILFROM vs the 2821.From:, then
there is nothing to whitelist on.  I such cases, the company and ESP
will need to depend on an accreditation system.  Or, they could rework
how they are doing things so that the From: header will authenticate.

Also, stuff that is BCC'ed may need to fall back to far less reliable
things like the HELO domain.  The many different and ever-changing
list of valid HELO domains, however, can usually be collected via
normal traffic, so an automated system could detect such cases.

My hurriedly authored I-D can be found at:
http://www.ietf.org/internet-drafts/draft-schlitt-marid-spf-from-hdr-00.txt

(This was supposed to be part of the Unified-SPF collection of I-Ds,
but I didn't get word from Meng not to submit it until too late.)

-wayne

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 07 Sep 2004 18:24:49 -0400

Roy Badami wrote:

>     Yakov> Now if all of this is stated in the RFC directly, what
>     Yakov> exactly is the IPR that is being claimed here? This seems
>     Yakov> to me explicit in the RFC itself.
> 
> I believe that the PRA algorithm, at least in outline, is obvious to a
> practitioner skilled in the art.
> 
> I'm sure it's pretty much what everyone does mentally when they read
> the headers of a message (yeah, ok, I'm a geek, I assume that everyone
> understands the semantics of the headers :-)
> 

Then according to RFC 3668 we can safely ignore the IPR claims is 
irrelevant and frivilous like it has been done before with IDN and 
IPSec. Or can we?

Yakov

---

From: Roy Badami <[email-masked]>
Date: Tue, 7 Sep 2004 23:22:35 +0100

-roy

---

From: Dave Crocker <[email-masked]>
Date: Wed, 8 Sep 2004 08:49:09 +0900

Yakov,

YS> Then according to RFC 3668 we can safely ignore the IPR claims is 
YS> irrelevant and frivilous like it has been done before with IDN and
YS> IPSec. Or can we?

My own guidance about whether to to treat an IPR claim seriously --
particularly when it includes legal filings -- is to decide whether
the claimant has the means and the resolve to pursue them.

The costs of being in IPR litigation are awesome, no matter how
frivolous one might believe the claims to be.

d/

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 7 Sep 2004 19:17:47 -0400

----- Original Message -----
From: "Roy Badami" <[email-masked]>
To: "Yakov Shafranovich" <[email-masked]>
Cc: "Roy Badami" <[email-masked]>; "Dave Crocker"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, September 07, 2004 6:22 PM
Subject: Re: TECH: use fetchmail algorithm to select header address to
verify

> practitioner skilled in the art.

No doubt about that.  Hence the reason I am not at all concern about it.
However, the only way possible a stronger claim can be made if a new
"identity" is introduced that is outside standard or legacy practice.  If
this is the case,  it would have to be a IETF standardized "identity" before
I begin bothering with it but I won't support it if there is an IPR
associated with it.

> understands the semantics of the headers :-)

Its not so much the "process, method or logic" to get a particular state,
but the natural fact the information is natural available. This is a very
important aspect of the patent process.  It is akin to receiving a letter
with no return address or one that is not recognizable, and this claim is
attempting to protect the process of a) opening the letter and b) reading it
to search for something recognizable.

---
Hector Santos, CTO
WINSERVER "Wildcat! Interactive Net Server"
http://www.santronics.com

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 07 Sep 2004 20:43:04 -0400

> the claimant has the means and the resolve to pursue them.

There is definitely means here, but I am not sure about the resolve. 
Somehow I don't think they will make fools out of themselves, especially 
considering that the FAT patent is being challenged.

> frivolous one might believe the claims to be.

Considering what happened to the Eolas and FAT patents, challenging a 
patent is now an option as well and is much cheaper.

In any case, does this mean that anyone claiming IPR rights can stop the 
standards process? That's not the reading I get from the cases of IDN 
and IPSec.

Yakov

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 8 Sep 2004 11:05:59 +0200

On Tue, Sep 07, 2004 at 06:24:49PM -0400,
 Yakov Shafranovich <[email-masked]> wrote 

> irrelevant and frivilous like it has been done before with IDN and

Of course, nobody can be really sure.

IMHO, given the already existing statements by the Apache Foundation
or the Debian people, if we want these groups to deply SenderID, we
need a very clear statement for the IETF that the IETF regards this
patent claim as frivolous (because too trivial) and/or invalid
(because of prior art) and suggests they are ignored. Is there a
consensus in this WG to make such a statement?

Also, the big difference with IDN is not the validity of the patent
claim (they are both ridiculous) but the size of the company which
owns it. Despite what was being said here, we should not evaluate the
patent claim only on the basis of the licence terms. In the real
world, the size and the amount of rogueness already displayed by the
holder is much more important. I still believe the risk is too high.

---

From: Margaret Olson <[email-masked]>
Date: Wed, 8 Sep 2004 06:13:18 -0400

[I changed the tag and subject to match the topic of discussion]

On Sep 7, 2004, at 8:43 PM, Yakov Shafranovich wrote:

> Somehow I don't think they will make fools out of themselves, 
> especially considering that the FAT patent is being challenged.
>
> In any case, does this mean that anyone claiming IPR rights can stop 
> the standards process? That's not the reading I get from the cases of 
> IDN and IPSec.

My reading of the IPR situation is that the MS patent is defensive - it 
ensures that they (and we) can use the technology. Their license is 
positioned for maximum defensive value. I believe they (and we) would 
have been better off sacrificing some of the legal defense value for 
sub-licensing and more open source compatibility, but they obviously 
disagree. In fairness, I'll point out that they have effectively 
volunteered to pay for any patent defense that is necessary, and 
perhaps can not be blamed too much for a zealous approach to preventing 
litigation expense.

I suggest ignoring the patent. It's not in their interests to litigate 
this kind of defensive (read: bogus) patent if they can possibly help 
it - avoiding patent litigation is the entire point of defensive 
patents. We'll only see litigation if someone decides to file a 
competing patent claim and prevent MS (and the rest of us) from using 
Sender ID. In this scenario a patent holder with deep pockets is a 
desirable.

The idea that any email authentication algorithm that is not currently 
encumbered will remain so in the face of something as potent as spam 
prevention strikes me as a bit naive. Others have posted on the state 
of the USPTO office an software patents, so I won't repeat that here. A 
patent holder focused on milking the patent, rather than protecting 
large and profitable businesses, would produce far worse licensing 
terms. A patent holder acting on behalf of the open source community 
would presumably produce a more open source friendly license. But no 
patent claim is a temporary situation. We need to be realistic about 
this, and I suspect MS's position in many reflects painful experience 
with failing to patent things that the rest of us would call either 
obvious or long standing prior art. My experience has certainly been 
that it if it is useful, you need to patent it if you expect to 
continue to use it.

Margaret.

---

From: wayne <[email-masked]>
Date: Wed, 08 Sep 2004 12:04:48 -0500

In <[email-masked]> Margaret Olson <[email-masked]> writes:

>           In fairness, I'll point out that they have effectively
> perhaps can not be blamed too much for a zealous approach to
> preventing litigation expense.

No, MS has only volunteered to pay for any patent defense filed
against them.  Patent enforcement can be selective.  If Patent Trolls
Inc decides to start out small to strengthen their case, they could
start by suing sourceforge or me.  Nothing in the SenderID license says that
MS would come to sourceforge's or my aid.

> I suggest ignoring the patent. 

> irrelevant and frivilous like it has been done before with IDN and

Both Margaret and Yakov suggest that "we" can ignore the MS patent.
There is clearly a risk involved for those who do, but apparently both
feel that the risk is pretty small.

Would those of you who suggest ignoring the patent please also
volunteer to pay for any and all costs associated with a (potential)
lawsuit from MS for not using their license?

If the risks are really as small as you two suggest, surely this
wouldn't be a problem for you to do.  If you are not willing to pay
such costs, why are you suggesting that people like me who write and
distribute software that would violate the patent take that risk?

-wayne

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 08 Sep 2004 14:11:35 -0400

> feel that the risk is pretty small.

I specifically left it as an open question. I was purely speculating.

> distribute software that would violate the patent take that risk?

I was suggesting no such thing. Rather, as IETF's history has shown it 
has been done before without detriment, and I was simply asking whether 
it is a viable option. In any case, given the chairs' statement on 
consensus this is irrelevant. We will not be able to reach consensus 
with the IPR issues anyway.

Yakov

---

From: Max Kanat-Alexander <[email-masked]>
Date: Wed, 08 Sep 2004 11:38:31 -0700

> MS would come to sourceforge's or my aid.

	IANAL (but I was a Legal Studies major in college).

	However, I suspect that if anybody challenged Microsoft's patent
anywhere, by suing anybody, they would be concerned as it could create
precedent which invalidates their patent. Invalid patent then leaves the
Exchange group open to a lawsuit from Patent Trolls Inc.

	-Max
-- 
Maxwell Kanat-Alexander
2nd Level Tech Support Engineer, USA
Kerio Technologies, Inc.

---

From: Margaret Olson <[email-masked]>
Date: Wed, 8 Sep 2004 14:21:10 -0400

On Sep 8, 2004, at 1:04 PM, wayne wrote:

>
> In <[email-masked]> Margaret 
> Olson <[email-masked]> writes:
>
>

This is an issue exists regardless of the IPR holder and the licensing 
terms, so you run the risk of a patent troll in any scenario. Spam 
prevention has a history of frivolous patent claims.

> lawsuit from MS for not using their license?

I can't speak for Yakov, but I'm suggesting that this working group 
ignore the IPR issue as irrelevant. You may or may not choose to ignore 
it for yourself.

Margaret.

---

From: [email-masked]
Date: Wed, 8 Sep 2004 22:12:25 +0200

> distribute software that would violate the patent take that risk?

I, for one, am not prepared to ignore the patent claim. Doing so would 
be naive and irrational. It would be irrational to ignore microsoft's
past and go on like nothing ever happened. The patent claim is
potentially dangerous, and ignoring it will not make it any less so.

Koen Martens

-- 
K.F.J. Martens, Sonologic, http://www.sonologic.nl/
Networking, embedded systems, unix expertise, artificial intelligence.
Public PGP key: http://www.metro.cx/pubkey-gmc.asc
Wondering about the funny attachment your mail program
can't read? Visit http://www.openpgp.org/

---

From: Mark <[email-masked]>
Date: Thu, 09 Sep 2004 09:48:04 GMT

Margaret Olson wrote:

> ignore the IPR issue as irrelevant. You may or may not choose to
> ignore it for yourself.

I chose not to. The question, to me, is not whether Microsoft's IPR claims 
are valid, but whether I can afford to be wrong. Heck, with all the legal 
cost involved with a lawsuit, I cannot even afford to be right. :)

- Mark

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Sep 2004 15:07:26 +0200

On Wed, Sep 08, 2004 at 12:04:48PM -0500,
 wayne <[email-masked]> wrote 

> lawsuit from MS for not using their license?

This is asking too much! I suggest instead, for those who claim that
the risk for the patent is quite low, to ask the IESG or the ISOC to
issue a clear statement that the patent is ignorable, thus providing
no money for legal fees but a strong support for future infringers.

I know, it contradicts RFC 2026 "10.3.2. Standards Track Documents",
"[The IESG] will take no position on the validity or scope of any such
rights." but it is better than asking for money. (And I believe, like
the Apache Software Foundation, that the IETF should change its patent
policy.)

---

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 10 Sep 2004 10:21:16 -0400

> the Apache Software Foundation, that the IETF should change its patent

And RFC 3667, 3668 and 3669. Rules aren't going to change in such short 
time. As of now, the IETF cannot take a stand on the validity of any patent.

Yakov