Subject: consensus call on pra/mailfrom deployment and versioning/scope

From: Andrew Newton <[email-masked]>
Date: Wed, 8 Sep 2004 09:37:18 -0400

It is the opinion of the co-chairs at this time (before the end of last 
call) that the MARID working group has no consensus regarding the 
deployment of Sender ID.  This lack of consensus centers around the IPR 
associated with the PRA algorithm.  Since predicting deployment is a 
subjective matter and not strictly a technical concern, we would like 
to offer the working group a proposal for modifying Sender ID that 
would take the issue of deployment out of the hands of the IETF and 
place it in the hands of the ultimate decision-makers, the systems and 
network administrators of the Internet.  We feel that this is where 
decisions of deployment should really be made.

It is also the opinion of the co-chairs that many in the working group 
are willing to deploy MAIL FROM checking as specified in 
draft-mengwong-spf.  Therefore, we ask for consideration of the 
following proposal:

The ABNF in -protocol 3.4.1 is (mostly from a post by Wayne)

    version     = "spf2." ver-minor "/" ver-scope *( "," ver-scope )
    ver-minor   = 1*DIGIT
    ver-scope   = "pra" / "mailfrom" / name
    name        = alpha *( alpha / digit / "-" / "_" / "." )

And the following stipulations:

  1) "mailfrom" checking will be defined in a new draft
  2) multiple records are allowed
  3) a scope (e.g. "pra") can only appear in one record of one type for 
validity purposes

The question before the working group: assuming no technical errors 
with the above, is there anybody who vehemently objects with this 
proposal?

-andy

---

From: Tony Finch <[email-masked]>
Date: Wed, 8 Sep 2004 15:37:52 +0100

On Wed, 8 Sep 2004, Andrew Newton wrote:
>
> It is the opinion of the co-chairs at this time (before the end of last call)
> that the MARID working group has no consensus regarding the deployment of
> Sender ID.  This lack of consensus centers around the IPR associated with the
> PRA algorithm.

Isn't there also IPR associated with the -core document?

>    name        = alpha *( alpha / digit / "-" / "_" / "." )

Will there also be a helo scope?

We can't use either pra or mailfrom because they break forwarding.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
ST DAVIDS HEAD TO COLWYN BAY, INCLUDING ST GEORGES CHANNEL: EAST 3 OR 4,
OCCASIONALLY 5 LATER. FAIR. GOOD. SLIGHT.

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 08 Sep 2004 10:44:28 -0400

Andrew Newton wrote:
> The question before the working group: assuming no technical errors with 
> the above, is there anybody who vehemently objects with this proposal?
> 

I like it but what happens if I want to do both mailfrom and pra, would 
I publish two records?

Does this also increase a chance for collisions perhaps needing a prefix?

If the scope of a Sender-ID record could be used to signify many things, 
does that mean that beside mailfrom and pra, other extensions are 
possible in the future? Would that require an IANA registry?

Yakov

---

From: "Chris Haynes" <[email-masked]>
Date: Wed, 8 Sep 2004 16:04:05 +0100

> Isn't there also IPR associated with the -core document?

In anticipation of the opportunity to use marid-core on its own, i.e. not in
conjunction with marid-pra, I asked Harry a similar question, and got the reply:

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

Chris Haynes

---

From: "Mark C. Langston" <[email-masked]>
Date: Wed, 8 Sep 2004 08:12:42 -0700

> Isn't there also IPR associated with the -core document?

It's my understanding (based in part on a recent clarification by Mr.
Katz as requested by Yakov and others) that -core in isolation is
unencumbered.  

I suggested a few weeks ago that if the IPR was truly a show-stopper
that we may want to consider just going ahead without the document
embodying PRA; I'm still okay with that solution.  I'll need to think a
bit about Andrew's specific suggestion, but it looks fine on the face of
it.

-- 
Mark C. Langston            GOSSiP Project          Sr. Unix SysAdmin
[email-masked]   http://sufficiently-advanced.net    [email-masked]
Systems & Network Admin      Distributed               SETI Institute
http://bitshift.org       E-mail Reputation       http://www.seti.org

---

From: Rand Wacker <[email-masked]>
Date: Wed, 8 Sep 2004 08:13:20 -0700 (PDT)

> with the above, is there anybody who vehemently objects with this

While I am personally in favor of allowing multiple scopes in the same
record, I think that this proposal will cause more problems than it
seemingly might solve, specifically for forwarders.

In particular, there is nothing in the current drafts that explain how to
modify messages or envelopes to allow forwarding/mail list/mx backup
operation...and I'm really hoping you're not suggesting we simply bring
SRS in to the fold.

-Rand

---

From: "Guillaume Filion" <[email-masked]>
Date: Wed, 8 Sep 2004 11:18:40 -0400

> Isn't there also IPR associated with the -core document?

No, the IPR is associated with -core and -pra taken together. Harry Katz
from Microsoft confirmed it yesterday in:
http://www.imc.org/ietf-mxcomp/mail-archive/msg04413.html

----------------------
From: "Harry Katz" <[email-masked]>
Sent: Tuesday, September 07, 2004 12:34 PM
Subject: RE: Motion to abandon Sender ID

> If you were able to confirm that the Microsoft disclosure /
> IPR claims do not cover the marid-core spec. taken in
> isolation, that would be extremely helpful and could allay
> some people's concerns.
>
> Chris Haynes

Confirmed.
----------------------

Best,
GFK's
-- 
Guillaume Filion, ing. jr
Logidac Tech., Beaumont, Québec, Canada - http://logidac.com/
PGP Key and more: http://guillaume.filion.org/

---

From: Matt Sergeant <[email-masked]>
Date: Wed, 8 Sep 2004 16:15:48 +0100

> Isn't there also IPR associated with the -core document?

Not directly:

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

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

> Isn't there also IPR associated with the -core document?

Only when used in conjuction with PRA:

http://article.gmane.org/gmane.ietf.mxcomp/4590

Yakov

---

From: Andrew Newton <[email-masked]>
Date: Wed, 8 Sep 2004 11:36:52 -0400

On Sep 8, 2004, at 10:44 AM, Yakov Shafranovich wrote:

> I like it but what happens if I want to do both mailfrom and pra, 
> would I publish two records?

The intent of the syntax is to allow one record to specify both pra and 
mailfrom if they are the same.  If they are not the same, then a record 
for each is allowed.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Wed, 8 Sep 2004 11:40:00 -0400

> operation...and I'm really hoping you're not suggesting we simply bring

Are you talking about the MAIL FROM case or the PRA case?  Otherwise, I 
do not understand your objection.

-andy

---

From: Rand Wacker <[email-masked]>
Date: Wed, 8 Sep 2004 08:41:16 -0700 (PDT)

On Wed, 8 Sep 2004, Andrew Newton wrote:

> > In particular, there is nothing in the current drafts that explain how
> > to modify messages or envelopes to allow forwarding/mail list/mx
> > backup operation...and I'm really hoping you're not suggesting we
> > simply bring SRS in to the fold.
>

The envelope bounce address (MAIL FROM) case.  You're right, it wouldn't
make sense otherwise. ;)

-Rand

---

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

> mailfrom if they are the same.  If they are not the same, then a record 

Can you give an example of both?

---

From: [email-masked] (Wietse Venema)
Date: Wed, 8 Sep 2004 11:52:35 -0400 (EDT)

> with the above, is there anybody who vehemently objects with this 

draft-mengwong-spf ('mailfrom') changes the return-path, and would
need a companion document that fixes the sender notification problem.

	Wietse

---

From: Meng Weng Wong <[email-masked]>
Date: Wed, 8 Sep 2004 11:45:29 -0400

On Wed, Sep 08, 2004 at 08:13:20AM -0700, Rand Wacker wrote:
| 
| In particular, there is nothing in the current drafts that explain how to
| modify messages or envelopes to allow forwarding/mail list/mx backup
| operation...and I'm really hoping you're not suggesting we simply bring
| SRS in to the fold.
| 

If we specify that spf/HELO and spf/SUBMITTER always
override spf/MAIL-FROM, then there is no need for SRS.

For example, at the envelope level only, given Alice sending
mail to Bob who forwards to Robert,

Step 1:
  HELO alice.mta
  MAIL FROM:<alice>
  RCPT TO:<bob>
  DATA
    From: <alice>

Step 2:
  HELO bob.mta
  MAIL FROM:<alice> SUBMITTER=<bob>
  RCPT TO:<robert>
  DATA
    Resent-From: <bob>

At step 2, the receiver can apply spf/HELO tests (or SPF
Lite or CSV or even IP based whitelisting) to bob.mta, and
approve the forwarder based on that.

The receiver can also apply spf/SUBMITTER tests to <bob>,
and approve the forwarder based on that.

Whether the receiver trusts the forwarder through a global
mechanism such as trusted-forwarder.org, or through a local
whitelist of known forwarders, or simply wishes to apply an
open-by-default policy or a closed-by-default policy, can be
up to them.

I predict that commercial forwarding services will do SRS
anyway.

---

From: David Woodhouse <[email-masked]>
Date: Wed, 08 Sep 2004 17:06:52 +0100

> We can't use either pra or mailfrom because they break forwarding.

A HELO scope would be useful. I could publish records for that, whereas
I could not publish records for either pra or mailfrom for much the same
reasons as Tony has already described.

-- 
dwmw2

---

From: Tripp Cox <[email-masked]>
Date: Wed, 8 Sep 2004 12:54:16 -0400

>    name        = alpha *( alpha / digit / "-" / "_" / "." )

I agree with decoupling scope from the base record format.  If we're 
going to modify -protocol, I suggest we further decouple the version 
string from the base record format.  To wit:

    version		= "spf/" ver-major "." ver-minor "/" ver-scope *( "," 
ver-scope )
    ver-major	= 1*DIGIT
    ver-minor	= 1*DIGIT
    ver-scope	= "pra" / "mailfrom" / name
    name		= alpha *( alpha / digit / "-" / "_" / "." )

Doing this would help further delineate the static and variable parts 
of the version string.  I also recommend that the RR type defined for 
-protocol be modified to drop the superfluous "2".

Sample applied use:

example.com.	IN SPF	"spf/2.0/pra,mailfrom  mx a:smtp.example.com 
a:smtp.marketingco.com ?all"
			IN SPF	"spf/2.0/mta mx a:smtp.example.com -a:192.0.2.0/24 ?all"
			IN TXT	"spf/2.0/pra,mailfrom  mx a:smtp.example.com 
a:smtp.marketingco.com ?all"
			IN TXT	"spf/2.0/mta mx a:smtp.example.com -a:192.0.2.0/24 ?all"

In future versions, perhaps:

example.com	IN SPF	"spf/2.1/xmlstr <spf 
xmlns='http://domain.com/1'><pra><m><mx/></m></pra></spf>"
example.com	IN SPF	"spf/2.2/xmldoc http://example.com/spf/policy.xml"

> with the above, is there anybody who vehemently objects with this 

I see no harm in taking this opportunity to allow for future versions 
of Sender-ID with additional scopes and different record formats.

Tripp

---

From: Ryan Ordway <[email-masked]>
Date: Wed, 08 Sep 2004 09:56:09 -0700

> with the above, is there anybody who vehemently objects with this 

	I fully support the extraction of the patent encumbered
PRA. I do have concerns about forwarding and compatibility with
existing records, so I will reserve my judgement until the new
drafts have been published.

	Ryan

-- 
HELO, my name is root... you have SIGKILLed my father... prepare to vi!

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 08 Sep 2004 12:54:22 -0400

> reasons as Tony has already described.

I think that Andy's proposal would make Sender-ID extensible enough to 
allow for all kinds of scopes.

Yakov

---

From: Tony Finch <[email-masked]>
Date: Wed, 8 Sep 2004 18:17:39 +0100

Another thing: the macro language should have a letter for interpolating
the scope.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SOUTH UTSIRE: VARIABLE 3 OR 4. MAINLY FAIR. MODERATE OR GOOD.

---

From: Peter Koch <[email-masked]>
Date: Wed, 08 Sep 2004 19:13:37 +0200

>     ver-scope   = "pra" / "mailfrom" / name

[...]

>   3) a scope (e.g. "pra") can only appear in one record of one type for 

does this mean the mail receiver queries for the RR(s) and selects from what
is there if that fits its own supported set of scopes or should at the time
of the DNS query the receiving MTA already have made its choice?

-Peter

---

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

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

> It is the opinion of the co-chairs at this time (before the end of
> last call) that the MARID working group has no consensus regarding the
> deployment of Sender ID.

Sadly, I agree with this assessment.   :-<

>                                         Since predicting deployment is
> a subjective matter and not strictly a technical concern, we would
> like to offer the working group a proposal for modifying Sender ID
> that would take the issue of deployment out of the hands of the IETF
> and place it in the hands of the ultimate decision-makers, the systems
> and network administrators of the Internet. 

Are you saying that, by adding the mailfrom scope, you think that the
marid-pra I-D can/should advance?   If so, I strongly disagree with
this position.

> draft-mengwong-spf.  

Several comments:

1) I really doubt that we will be able to gain any sort of consensus
   on the support of 2821.MAILFROM in the time remaining in the
   current last call.

2) As others have pointed out, SPF-classic required 2821.HELO checking
   in some cases and allowed 2821.HELO checking in all cases.
   Therefore, I think that at least a 2821.HELO scope needs to be
   added.

3) I think that it is critical to also add the %{e} scope macro
   variable, as mentioned several times on this list.  

> with the above, is there anybody who vehemently objects with this

I support work along this line.

-wayne

---

From: Douglas Otis <[email-masked]>
Date: Wed, 08 Sep 2004 10:20:21 -0700

> with the above, is there anybody who vehemently objects with this 

Checking RFC2821 MAIL FROM offers more value than did checking the PRA. 
The PRA allows spoofing the RFC2822 From anyway.  The network overhead
of this script is still a concern, especially as this draft allows
extensions outside the standards process.  Merging two mechanism will
increase this overhead.

There is also an issue when the list of the MTA addresses is marked as
not comprehensive, which could cause this record to be exploited.  This
is related to the forwarding issue, also not properly addressed either. 
This is also where Jim Lyon expressed his opinion that anyone that
employs this non-comprehensive option, perhaps in an effort to allow
forwarding, will find themselves blacklisted.

Both of these fundamental and serious shortcomings can be addressed by
making a structural change.

The mailbox domain obtained from either MAIL FROM or the PRA assumes the
unverifiable integrity of the mail channel and thus are not suitable as
a basis for a reputation assessment.  The number of DNS lookups required
to resolve the MTA to mailbox domain relationship can be confined to a
single DNS lookup, if a name for the MTA is first authenticated.  This
resolves the network overhead issue and the problem of a
non-comprehensive MTA to mailbox domain relationship, as the
relationship and the MTA authentication become independent functions. 
An authenticated MTA name is suitable for reputation assessment, and
removes the danger expressed by Jim Lyon.

Those that wish to employ a restrictive relationship with their MTA and
mailbox domains can easily do so without the need for the PRA
algorithm.  For some situations, such as for financial transactions,
there may not be a desire to have messages forwarded or sent through a
list server, when the message is restricted by either or both the MAIL
FROM or From fields.  There are also alternatives to SRS as well.

Beyond the IPR, there are pressing technical issues that can be
adequately rectified using this different two-step structural approach. 

The MTA and mailbox domain should normally be treated as a nominal
relationship useful for coloring mail, where most of the compatibility
issues then vanish.  By declaring the MTA name as the only identity
suitable for reputation assessment, this allows a lightweight scheme
that can help combat Trojan proxies, and protect users from being
falsely blacklisted.  It also forms the basis for a simplistic means of
expressing an MTA to mailbox domain relationship.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Wed, 08 Sep 2004 09:50:29 -0700

>and approve the forwarder based on that.

Wouldn't this require a PRA check to verify that SUBMITTER is consistent with the message headers, and wouldn't that be encumbered?

-Jim

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 08 Sep 2004 13:45:20 -0400

Tripp Cox wrote:
> I see no harm in taking this opportunity to allow for future versions of 
> Sender-ID with additional scopes and different record formats.
> 

I agree.

Yakov

P.S. Lets not forget an IANA registry for scope names.

---

From: Koen Martens <[email-masked]>
Date: Wed, 8 Sep 2004 20:18:22 +0200

> operation...and I'm really hoping you're not suggesting we simply bring

What is wrong with SRS? I think it's an ingenious solution that works.
Ok, it mangles the MAIL FROM adresses, but these are not for users
anyway but for the MTA. Furthermore, if as an administrator you can take
the trouble to go through the headers and all, you can most certainly
also 'unmangle' the srs address.

Anyway, I've been doing srs for a while now, and I haven't got any
complaints about it from those whom I forward to. Neither have I had any
problems with it.

Koen

-- 
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: Yakov Shafranovich <[email-masked]>
Date: Wed, 08 Sep 2004 14:19:53 -0400

Jim Fenton wrote:

>> Step 2: HELO bob.mta MAIL FROM:<alice> SUBMITTER=<bob> RCPT
>> TO:<robert> DATA Resent-From: <bob>
>> 
>> At step 2, the receiver can apply spf/HELO tests (or SPF Lite or
>> CSV or even IP based whitelisting) to bob.mta, and approve the
>> forwarder based on that.
>> 
>> The receiver can also apply spf/SUBMITTER tests to <bob>, and
> Wouldn't this require a PRA check to verify that SUBMITTER is
> consistent with the message headers, and wouldn't that be encumbered?
> 

No, SUBMITTER would be compared against the Sender-ID records directly 
without touching the headers.

Ykaov

---

From: Andrew Newton <[email-masked]>
Date: Wed, 8 Sep 2004 15:12:34 -0400

On Sep 8, 2004, at 12:06 PM, David Woodhouse wrote:

> A HELO scope would be useful.

That is already being covered by the CSV proposals.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Wed, 8 Sep 2004 15:20:04 -0400

> of the DNS query the receiving MTA already have made its choice?

If I understand your question, the intent is the former.  Or to put it 
another way, there is one SPF/TXT query and not a scope targeted query.

-andy

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 08 Sep 2004 15:20:53 -0400

Douglas Otis wrote:

> On Wed, 2004-09-08 at 11:19, Yakov Shafranovich wrote:
> 
>>Jim Fenton wrote:
>>
> This means there would be no record which identity was used to permit
> the message.  What an ideal way to spoof.
> 

Let me rephrase that: SUBMITTER would be compared against the Sender-ID 
records directly without *examining* the headers.

You can still record the result of that and the parameter in some header.

Yakov

---

From: Douglas Otis <[email-masked]>
Date: Wed, 08 Sep 2004 12:15:23 -0700

-Doug

---

From: Andrew Newton <[email-masked]>
Date: Wed, 8 Sep 2004 15:24:55 -0400

> marid-pra I-D can/should advance?   If so, I strongly disagree with

Yes.  And I'm confused as to why you would disagree, even if you do not 
intend to do PRA checking.  There is no IPR issue with publishing both 
a PRA and MAIL FROM scope, just checking the PRA scope.  So even though 
you have no intention to do it, why would you insist that other should 
not?

-andy

---

From: Douglas Otis <[email-masked]>
Date: Wed, 08 Sep 2004 12:52:52 -0700

> You can still record the result of that and the parameter in some header.

This undefined header will also be spoofed.  Are you suggesting removal
of this header, if present, and insertion of a "X-Assumed PRA" header
depending upon whether the check has been made and whether the PRA
selection was assumed valid?

This becomes irrelevant should the MTA/Mailbox domain relationships be
viewed as nominal assertions against MAIL FROM and From mailbox domains
and the MTA authentication is an independent operation.  Where PRA plays
a role is equally accommodated by the EHLO name anyway.

-Doug

---

From: Matt Sergeant <[email-masked]>
Date: Wed, 8 Sep 2004 20:51:12 +0100 (BST)

> That is already being covered by the CSV proposals.

Right, but with a different syntax and storage. If we could move forwards 
now with a unified syntax and storage that would be useful.

Matt.x

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 8 Sep 2004 22:01:56 +0200

On Wed, Sep 08, 2004 at 03:37:52PM +0100,
 Tony Finch <[email-masked]> wrote 

> We can't use either pra or mailfrom because they break forwarding.

Forwarding can be "repaired" with things like SUBMITTER or SRS (I
prefer SUBMITTER). SPF-classic breaks forwarding but SenderID may be
changed to repair it.

---

From: Andrew Newton <[email-masked]>
Date: Wed, 8 Sep 2004 16:02:37 -0400

> now with a unified syntax and storage that would be useful.

This working group has already been through this and concluded that CSV 
was sufficiently different enough in its intentions and tact that it 
should not share the same DNS mechanism.

-andy

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 08 Sep 2004 16:00:56 -0400

> a role is equally accommodated by the EHLO name anyway.

Hmm. The original intent of all of these before phishing and 2822 
headers got thrown in was to verify the parameters of the SMTP 
transaction. With the variant scopes we can still do that with ability 
to check MAIL FROM via mailfrom scope, and EHLO if CSV is intergrated 
into the main record format.

As for PRA, I think I finally understand your point. The PRA and 
SUBMITTER invent a new identity, that of the original agent that 
submitted the message, akin to the "Sender" header in 2822. I think what 
you are trying to say is that there is no need to resort to those 
methods, which are less reliable, when 2821 information is available. Is 
that correct?

If so, does that mean that this entire set of proposals is not useful 
for stopping phishing in any way?

Yakov

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 8 Sep 2004 22:04:14 +0200

On Wed, Sep 08, 2004 at 03:12:34PM -0400,
 Andrew Newton <[email-masked]> wrote 

> That is already being covered by the CSV proposals.

The CSV proposal is a completely separated one, with a different set
of concepts and a different vocabulary. I would accept HELO checking
if it were done in the same framework ("Unified SPF") and with the
same record format so I support the idea of adding one more scope.

--
Three identities to check for
One record format to bind them all

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 8 Sep 2004 22:00:38 +0200

On Wed, Sep 08, 2004 at 09:37:18AM -0400,
 Andrew Newton <[email-masked]> wrote 

>    ver-scope   = "pra" / "mailfrom" / name
...
> with the above, is there anybody who vehemently objects with this 

Basically, you suggest to move to "Unified SPF" where the same record
format is used for testing the various identities. I fully agree, and
it pushes asides the IPR problem since PRA would become optional. But:

1) It cannot be done by a small patch in the drafts. It changes seveal
things in -submitter and in -core. To me, your proposal (which I find
perfect) requires dropping the current drafts and starting again with
new drafts.

2) There are other scopes than mailfrom and pra (helo is an obvious
one) and we should either mention them or allow for additional scopes.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 8 Sep 2004 22:08:24 +0200

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

> marid-pra I-D can/should advance?   If so, I strongly disagree with

It can advance at a different pace. For instance, -core, -protocol and
-mailfrom may be published on the Standards Track while -pra is
published as Experimental and may be "upgraded" later if the frivolous
Microsoft patent is invalidated.

As long as it is reasonably easy to drop -pra support, I agree with
the proposal. Crypto software use a similar technique when some
algorithms are patented. They can even be implemented in a separate
shared library, may be published in a different archive ("non-free"
for Debian).

>    on the support of 2821.MAILFROM in the time remaining in the

I agree. We should restart the process.

---

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

> That is already being covered by the CSV proposals.

I'm confident that Doug Otis and/or Dave Crocker will be quite willing
to explain in elaborate detail how CSV differs from SPF/HELO.  I do
not see any reason not to support both and let the market decide.

-wayne

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 8 Sep 2004 16:30:38 -0400

Hi,

If I understand all this, I would agree this is the right approach.   This
will allow for the separation, breakdown, usage and implementation of one or
more EPV (End Point Validation) techniques open, patented or otherwise.

I would recommend the following to help faciliate your proposal:

1) Refine RFC 2821 to eliminate conflicts and ambiguities.

1a) What are required and enforcable entities?

2) Refine RFC 2822 to eliminate conflicts and ambiguities.

1a) What are required and enforceable entities?

More so with #1,  I don't believe good progress will be made until RFC 2821
is
cleaned up.  This could be in the same vain as it was done with RFC2476 for
SMTP of applying a more strict transaction process , but it need not go that
far.

With #2, clearing up the ambiguities, like with the Resent-To, etc.
However, I don't see this a major part since it is not an established
requirement unlike the issues in 2821 with HELO and MAIL FROM.

In short, the new draft need to improves upon the hosting requirements and
once this is done, I believe MARID will become more stronger as a plausible
technology to implement.  It will also open the door for new possibilities
as well.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 08 Sep 2004 16:55:37 -0400

> one) and we should either mention them or allow for additional scopes.

Sounds like the last call might have to be extended or canceled.

Yakov

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 8 Sep 2004 23:00:48 +0200

On Wed, Sep 08, 2004 at 04:55:37PM -0400,
 Yakov Shafranovich <[email-masked]> wrote 

> Sounds like the last call might have to be extended or canceled.

Certainly yes. Work for IETF 61 in Washington. Moving to an unified
model also allows to reexamine previous decisions (such as the one
against CSV, which could be reintegrated with a HELO scope).

---

From: wayne <[email-masked]>
Date: Wed, 08 Sep 2004 16:06:56 -0500

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

> Yes.  And I'm confused as to why you would disagree, even if you do
> not intend to do PRA checking.  There is no IPR issue with publishing
> both a PRA and MAIL FROM scope, just checking the PRA scope.  So even
> though you have no intention to do it, why would you insist that other
> should not?

Publishing SPF records with PRA information has never been a problem
for me (and I think for most others).

The problem is the PRA can not be implemented in most F/OSS MTAs and
spam filters.  The PRA is an 2822 identity, which does not cover the
same problem space as the 2821.MAILFROM.  The suggestion of using
2821.MAILFROM to get around the SenderID patent mess is like
suggesting using DES to get around the RSA patent mess.  Yeah, they
vaguely cover the same general area, but really, they are quite
different.

If you could come up with a proposal that has broad consensus that
covers the 2822 identities, I could see letting both that proposal and
the PRA going forward.  However, I don't see any such proposal.

The only two proposals besides the PRA in the area of 2822 that I can
recall are the fetchmail algorithm and and my
marid-schlitt-spf-fromhdr.  The fetchmail algorithm use the
Return-Path: header as its primary choice, so it really isn't any more
of a 2822 identity than the PRA is a 2821 identity due to SUBMITTER.
The SPF/FROMHDR proposal has not been discussed much at all, due
largely to respect the wishes of the co-chairs not to muddle the
current set of I-Ds.

I can see advancing marid-core and marid-protocol.  I can also see
continuing work on the 2821 identities.   I can even see taking
another stab at the 2822 identities.  I can't see advancing marid-pra.

-wayne

---

From: Matt Sergeant <[email-masked]>
Date: Wed, 8 Sep 2004 22:10:09 +0100 (BST)

> for stopping phishing in any way?

None of these proposals will "stop" phishing in any way. No more so than
"Are you sure you want to open executables" dialog boxes will stop
viruses. And yes, I include the future time when we have working
"reputation" services.

Though I can say, if you want to reduce phishing, don't try and base it on 
updated MUAs. Focus on the MTA.

Matt.

---

From: Matt Sergeant <[email-masked]>
Date: Wed, 8 Sep 2004 22:12:31 +0100 (BST)

> perfect) requires dropping the current drafts and starting again with

I hope you're kidding. We can change the current drafts without scrapping
how far we've come.

Matt.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 8 Sep 2004 23:22:01 +0200

On Wed, Sep 08, 2004 at 10:12:31PM +0100,
 Matt Sergeant <[email-masked]> wrote 
 a message of 17 lines which said:

> I hope you're kidding. 

No.

> We can change the current drafts without scrapping how far we've
> come.

I did not suggest to start from zero. I just said that the new scheme
cannot be considered a minor patch so we have to cancel the last call,
to write new drafts (try to edit everything about PRA from -submitter,
it is not as obvious as it may seems) and to discuss them, all of this
before Washington.

---

From: Mark Lentczner <[email-masked]>
Date: Wed, 8 Sep 2004 14:25:29 -0700

Several items:

-= 1 =-
Someone asked for an example of a single record that works for both 
scopes:
	spf2.0/pra,mailfrom +mx -all

-= 2 =-
Yes, scopes would need an IANA registry.  I would suggest that it needs 
to be limited in the greatest possible way (like amended only by a 
working group draft - anyone know language for this?  an existing 
example of such a registry? -- e-mail me off-list.)

-= 3 =-
Please note that the Classic SPF's use of the HELO/EHLO domain when the 
reverse-path is null does not constitute a check of the HELO scope 
(such as done by SPF/HELO or CSV.)  It is constructing what the return 
path should be even though the sending MTA has omitted it ("Mail From 
<>") to break possible mail loops.  It is still checking the envelope 
concept of "Mail From".  It is not making any assertions about the 
HELO/EHLO domain as used by a SMTP client.

-= 4 =-
I would not support a HELO scope for the same reasons mentioned by 
others.  In particular, 1) CSV is this group's next agenda item, 2) The 
full syntax of SPF records is totally unwarranted for HELO checks (you 
only need "+a -all" and "-all".)  3) One generally never publishes 
records about HELO at the same domain name as MAIL FROM or PRA.  Hence 
they'd never share a record.

-= 5 =-
As per my discussion in prior messages, the scope macro doesn't buy 
much.  I am not in favor of it, though not strongly.

	- Mark

Mark Lentczner
http://www.ozonehouse.com/mark/
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Thu, 9 Sep 2004 05:44:04 +0900

Tony,

TF> Will there also be a helo scope?
TF> We can't use either pra or mailfrom because they break forwarding.

  Taking andrew's proposal as an effort to process SPF "classic"
  through the IETF, I suggest not trying to expand the scope or
  redirect it.

  The issue of forwarding for author-based path registration schemes,
  like SPF and Sender-ID, has been discussed at length.  At a minimum,
  we need to document these impacts on usage.

  However there is already a deployed base of some size, for SPF, so
  we know that there are usage scenarios that the community find
  helpful.

  I suggest we make sure we document all this, rather than
  re-targeting the technical focus.

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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 08 Sep 2004 15:55:18 -0700

> into the main record format.

There are a few advantages this seems to miss.  By using CSV as a first
step, the format for describing any mailbox-domain relationship with
sending MTAs requires little more than a name list.

Something like:
_spf._mailfrom.my-domain.com. PTR my-isp.com.
_spf._mailfrom.my-domain.com. PTR my-other-isp.com.
_spf._mailfrom.my-domain.com. PTR my-support.com.

-or-
_spf._from.my-domain.com.      PTR my-isp.com.
_spf._from.my-domain.com.      PTR my-other-isp.com.
_spf._from.my-domain.com.      PTR my-support.com.

I had proposed: 
_mp._smtp.my-domain.com.       PTR my-isp.com.
_mp._smtp.my-domain.com.       PTR my-other-isp.com.
_mp._smtp.my-domain.com.       PTR my-support.com.

Where an A record flags whether the list is "comprehensive" for either
the MAIL FROM or the From fields.  If the associated flag is not set,
then the list becomes nominal information to color mail.  PTR should
allow name compression and fit within a single DNS lookup.  This would
not require any subsequent lookups to resolve whether
mx001.soup.my-isp.com was a nominal source for my-domain.com as
example.                          

> methods, which are less reliable, when 2821 information is available. Is 

The EHLO name offers virtually the same information obtained by roving
through RFC2822 headers using the PRA algorithm where the From is being
over-ridden, but the certainty of this EHLO name is suitable for
asserting reputation.  Reputation services are not without risk and
being asked to trust the integrity of the mail channel is untenable for
this purpose.  Having an authenticated name lowers the cost establishing
a history of use, but neither SPF nor Sender-ID offers a reasonable
level of assurance for the domain identified.

> for stopping phishing in any way?

Sender-ID does not stop phishing any better than simply asserting the
nominal source of mail and making the authenticated EHLO name visible. 
This two step process would obtain better consumer protections with less
information exchanged by DNS and less risk with respect to compliance. 
CSV does not add to the SMTP overhead, nor would a name list require
subsequent lookups.  A sequence of lookups could comprise a sizable
burden for the receiving SMTP server needed with the collapsed functions
of Sender-ID and SPF, and simply invoking a timeout is not a suitable
solution.

A nominal mailbox-domain sending MTA list is a lightweight approach that
quickly brings results closer to the goal without breaking SMTP.  Don't
underestimate the importance of authenticating a name suitable
reputation assertions or the role EHLO can play in this effort.

-Doug

---

From: Daniel Quinlan <[email-masked]>
Date: 08 Sep 2004 16:28:47 -0700

> with the above, is there anybody who vehemently objects with this 

If patent-encumbered stuff (PRA) is any part of the specification (and I
see it mentioned in your proposal), then the ASF (including the
SpamAssassin and JAMES projects) vehemently objects.

Given that there is a lack of consensus on PRA, it seems like the best
course is drop PRA entirely and allow the specification authors to
revise things a bit more freely again.

Daniel Quinlan
V.P., Apache SpamAssassin

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/

---

From: Dave Crocker <[email-masked]>
Date: Thu, 9 Sep 2004 05:52:54 +0900

Andrew,

AN> The question before the working group: assuming no technical errors
AN> with the above, is there anybody who vehemently objects with this 
AN> proposal?

     once upon a time, it was suggested that proposals need to have
     security and operations review.  all of the proposals under
     discussion for this space have very significant ties and
     sensitivities to both security and OA&M.

     we really do need to get those reviews, before any proposal
     should reasonably be run through any sort of working group last
     call. and the broader IETF discussions on cross-area review have
     stressed the need for getting such reviews long before that.

d/

---

From: <[email-masked]>
Date: Wed, 8 Sep 2004 20:45:49 -0400

As a frequent joe job and virus victim, I would be very pleased to see
a proposal go forward that would allow mail-from checking.  However, I
have two concerns.

First, it would need to be clear how multiple checks should interact
when receiving sites perform multiple checks.  In particular, it must
be the case that a site checking both mailfrom and pra should always
reject mail when mailfrom fails (even if pra passes).  This might be
as simple as saying if any test fails, the message is considered to
have failed.

Second, if we just go forward and do this with the minimum amount of
change necessary to the documents, I fear we may lose an opportunity
to do something better.  In particular, if the idea is that sites may
wish to do multiple kinds of checking, it would probably be very
useful to have access to the envelope sender from within the PRA
check.

For example, bank.com may wish to say that if the PRA is bank.com, the
envelope sender should be bank.com or outsource.com (which could then
be enforced with mailfrom).

This would require a new macro for the mailfrom domain (%{m}?), and
would also benefit greatly from some kind of string comparison
mechanism--maybe eq:string1:string2.  You'd want to be able to say
something like:

    +eq:%{d}:%{m} +eq:outsource.com:%{m}

in your /pra record.  It's possible to achieve something similar with
the exists: mechanism, but it requires more DNS traffic.

That said, since since both technical and legal concerns make the PRA
not useful to me, I guess I don't really care very much about this. 
I'm basically happy with SPF-classic, and view your proposal as a way
to continue using SPF-classic while just changing "v=spf1" to
"spf2.0/mailfrom".

Perhaps the point is I'd be sympathetic to anyone who asked for a
little more time to explore the possibility of cross-scope mechanisms.

David

---

From: Andrew Newton <[email-masked]>
Date: Wed, 8 Sep 2004 21:34:52 -0400

On Sep 8, 2004, at 5:06 PM, wayne wrote:

> spam filters.

Is this a double standard?  You do not wish to be restricted by the 
encumbrances of another's license yet you wish to restrict others to 
the encumbrances of your software license.

This compromise gives those unwilling to accept the license for PRA the 
ability to check MAIL FROM while allowing those willing to accept the 
license for PRA the ability to check the PRA.  However, everybody can 
publish both.

> The PRA is an 2822 identity, which does not cover the

Just because an identity appears in the same RFC does not mean it has 
any better relationship for sender authentication.  Certainly 
2821.MAILFROM and 2822.From are more closely correlated than 2822.From 
and 2822.Cc.

> the PRA going forward.  However, I don't see any such proposal.

The syntax does account for future scopes.  However, if we cannot 
advance the two scopes the people on this list have said they would be 
willing to deploy and instead wait around for the definition of a third 
scope then where do we stop, on the tenth defined scope?

-andy

---

From: Chuck Mead <[email-masked]>
Date: Wed, 08 Sep 2004 21:54:55 -0400

Daniel Quinlan wrote:
| Andrew Newton <[email-masked]> writes:
|
|
|>[...]
|>    ver-scope   = "pra" / "mailfrom" / name
|>[...]
|>The question before the working group: assuming no technical errors
|>with the above, is there anybody who vehemently objects with this
|>proposal?
|
|
| If patent-encumbered stuff (PRA) is any part of the specification (and I
| see it mentioned in your proposal), then the ASF (including the
| SpamAssassin and JAMES projects) vehemently objects.
|
| Given that there is a lack of consensus on PRA, it seems like the best
| course is drop PRA entirely and allow the specification authors to
| revise things a bit more freely again.
|
| Daniel Quinlan
| V.P., Apache SpamAssassin

Dan,
~        Did you see the message linked below from Stephane Bortzmeyer?
It appears to me that he is suggesting that we effectively "un-link" the
encumbered PRA and move ahead with -core, -protocol and -mailfrom
leaving PRA in an experimental state. As Andy has made a suggestion
about where we should focus since we cannot agree to use the PRA for
deployment reasons it seems to me that this might be considered a
reasonable suggestion. What would ASF say to this?

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

- --
[email-masked], head geek
http://moongroup.com

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 8 Sep 2004 19:21:37 -0700 (PDT)

> it is not as obvious as it may seems) and to discuss them, all of this

I entirely agree. As soon as last call is over, I'll post the proposal
(which will include modified version of some of current draft documents)
that does exactly that - consistant with ideas of callerid but does
not base it on requirement to use PRA algorithm and instead focuses
on Submitter as appropriate identity all by itself. 

I'd have posted all this already but group chair is of the opinion that
such proposal would distract us and parallel the proposal itself would
also not receive appopriate review because of distraction of last call
on other documents.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: wayne <[email-masked]>
Date: Wed, 08 Sep 2004 22:03:06 -0500

> the encumbrances of your software license.

I'm sorry Andy, but for the life of me, I can't figure out where this
line of reasoning comes from.  You made similar comments in your last
point of you "on the topic of IPR" post:

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

I was going to reply/rebut this line of reasoning, but I saw that
several people said basically what I was going to say.

Yakov Shafranovich's reply:
http://www.imc.org/ietf-mxcomp/mail-archive/msg03759.html

Paul Iadonisi's reply:
http://www.imc.org/ietf-mxcomp/mail-archive/msg03773.html

I think we have a failure to communicate here. ;-)

Even back in my original "Obstacles between us and the finish line"
post ( http://www.imc.org/ietf-mxcomp/mail-archive/msg02476.html )
I said:

: 4) IP licensing:  I'm not dogmatic about the GPL or commercial
: licenses, but there are significant MTAs and mail filters that fall
: under both kinds of licenses, and several others to boot.  I think
: that any proposal that has incompatible IP licensing needs to be
: dropped.

If there was a patent holder who covered some part of the SenderID
proposal and their patent license required using the GPL, I would be
just as bothered.

The issue isn't what individual implementers choose to license their
code under, the issue is whether we should advance a standard that is
incompatible with a very large percentage of current the email
infrastructure.  The patent license on the standard covers everyone.

(For what it is worth, the vast majority of software I have written is
under commercial/proprietary licenses far more restrictive than any
F/OSS licence that I know of.)

> 2821.MAILFROM and 2822.From are more closely correlated than 2822.From

Yes, true, I'm being far to vague when I say "2822 identities".  For
the most part, what people discussed as identities back in April(?)
were the HELO domain, the 2821.MAILFROM, the 2822.From:, and the PTR
identity (MTAmark, SS, etc.).  The PRA was presented as protecting
"what users see", e.g., the 2822.From:.  It was correctly pointed out
that users generally don't see the 2821.MAILFROM.

I think there are valid reasons to consider all four of those
identities because I think they all address different parts of an
overall forgery problem.

> willing to deploy and instead wait around for the definition of a
> third scope then where do we stop, on the tenth defined scope?

Well, I haven't seen many people suggest more than four
identities/scopes.  I've seen people advance different proposals for
most of these identities.  I think we can reasonably stop at one good
standard for each identity.

That doesn't mean that I think that the 2821.MAILFROM identity is a
good subsitute for the 2822.From: identity, or vice versa.

-wayne

---

From: Chuck Mead <[email-masked]>
Date: Thu, 09 Sep 2004 00:02:52 -0400

wayne wrote:

| If there was a patent holder who covered some part of the SenderID
| proposal and their patent license required using the GPL, I would be
| just as bothered.
|
| The issue isn't what individual implementers choose to license their
| code under, the issue is whether we should advance a standard that is
| incompatible with a very large percentage of current the email
| infrastructure.  The patent license on the standard covers everyone.

This is exactly why I asked Dan Quinlan about the ASF position on this.

- --

---

From: "Michel Bouissou" <[email-masked]>
Date: Thu, 9 Sep 2004 07:56:09 +0200 (CEST)

> I agree. We should restart the process.

Agreed. The remaining timeframe is much too short to figure out all these
proposed changes, discuss it and reach consensus.

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

---

From: AccuSpam <[email-masked]>
Date: Thu, 09 Sep 2004 14:40:16 +0800

>the encumbrances of your software license.

I fail to see what crucial information is needed in the DNS record to implement PRA that is also not needed by SPF check?

Thus I fail to see why the DNS record has to specify the algorithm that will be used on the approved mail servers specified in the DNS?  Do we think by inserting "pra" or "spf" we will really control what all receivers do?

The main point is that the standard of what goes into the DNS record should not be supporting a proprietary standard.

>license for PRA the ability to check the PRA.  However, everybody can 

The compromise adds fuel to fire fragmented syntax for DNS records.  In future, I envision large corporate senders only specifying "pra", because they do not have time to test with "spf", just as the situation we have now with many writing web sites for IE and not for other browsers.

>2821.MAILFROM and 2822.From are more closely correlated than 2822.From 

The only thing we are doing is specifying the approved mail servers.  Everything else is our attempt to pick a winning technology for interpreting the data of approved mail servers.

>The syntax does account for future scopes.

Inherently.  No need to limit the scope, since you can not limit it.  Once you publish the data of approved mail servers, it is open game to use the data.  There will be many competing technologies and implementations, just as there are now in anti-spam, unless possibly if we hand a "silver bullet" to a monopoly to stifle that experimentation.  I realize you do not want speculation on the future, and only on the merits as of today.  So I will state as fact that no one can prove today that any of the methods for interpreting the approved mail servers will be better than the other.

-Shelby Moore
http://AccuSpam.com

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 9 Sep 2004 00:58:49 -0700 (PDT)

On Wed, 8 Sep 2004, Andrew Newton wrote:

> associated with the PRA algorithm.  

I'm not surprised you draw this conclusion, considering posts on the list 
for last couple weeks.... (in fact I would have been very surprised if
it was not the conclusion).

> Since predicting deployment is a subjective matter and not strictly a 
> technical concern, we would like  to offer the working group a proposal 
> for modifying Sender ID that  would take the issue of deployment out of 
> the hands of the IETF 

IETF had real problem is that it did not wish to deal with how their
protocols would be deployed. This is the main reason of failures of number
of protocols that have been created and why others are less used then
they could be. Certain conclusion must (and have) been drawn out of this
and it would be unfortunete if we choose to go the same road again.

> and  place it in the hands of the ultimate decision-makers, the systems and 

The same people are also looking for IETF for guidence. There is a reasson
why we have a BCP series and why exactly is it that we have entire section 
of IETF is listed as "Operations and Management Area"?

While I think that if the drafts are to be published as EXPERIMENTAL
your statements that it would be up to the administrative to try it out, 
(as an experiment to see if it works and later come to IETF and tell how
it is going and if more work is needed to make it standard), my understanding
is that this WG is expecting to publish documents in STANDARD track. But
it would not be a "Standard" if we don't expect entire worldwide community
to be able to implement it.

> are willing to deploy MAIL FROM checking as specified in 

This is not unexpected conclusion either. However, I note that MAIL FROM
is different identity which is used entirely inside SMTP stream and not
usually seen by end-users. The problem here is not as much "phishing" as
it is a DoS that happens when your domain is used without your permission
and you get all the bounces. 

This group should to solve both problems, but we should not say that you 
are going to be able to solve either one problem or the other depending
on if you're part of the open-source community or commercial product 
developer willing to get a supposedely "free" license.

>  Therefore, we ask for consideration of the following proposal:

>   3) a scope (e.g. "pra") can only appear in one record of one type for 

I'm going to comment in separate post on the scoping since issue now 
officially came up.

> with the above, is there anybody who vehemently objects with this 

Yes, I do.

Not on technical reasons that doing scoping is bad - I would have expected
scoping to be worked out by the group sooner or later anyway. 

But as I indicated above, I'm concerned that the IPR issue with SenderID/PRA
are still unresolved and if we standartize PRA as chair is suggesting, only
some be able to do this type of verification and on the other hand only 
some would do mail-from checking, etc. This separatism is a dangerous road 
to take for IETF work, we want to have one unified internet-wide standard 
not a standard for you and standard for me!

I think we should decide on SenderID/PRA all by itself. Either we find
an acceptable solution that will allow everybody to implement it or
we find a replacement for it or we drop the entire concept all together
and work on different identities and scopes, including envelope mail-from
as is done with classic SPF.

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

---

From: AccuSpam <[email-masked]>
Date: Thu, 09 Sep 2004 16:16:37 +0800

>and it would be unfortunete if we choose to go the same road again.

IMHO, the largest deployment hurdle will be to get 63 million of domain owners (growing at 1.5 million per month) to publish and maintain a DNS record.  (See my post at spf-discuss for source).

Presenting these non-technical people with the complexity of choosing which scope their approved mail servers will be used and other complex options we might provide them, seems to run counter to the 80/20 rule for deployment.

I simply do not see why we need scope in order to get people to publish which mail servers they approve for sending email?

>and you get all the bounces. 

Disagree.  There are many possible ways verifiers might use the spf data and specification.  You can not preordain those uses unless you have a crystal ball.

>This group should to solve both problems,

I do not think this group will solve "these problems".  I think this group will define a standard for publishing the approved mail servers and then let the internet and marketplace work towards solving "these problems" and other related problems (e.g. spam).

> but we should not say that you 

Agreed.  And I think the most efficient way to reach that concensus and to not inhibit the use of the standard, is to not try to specify the scope of the algorithm (since it can be ignored any way).

>not a standard for you and standard for me!

Agreed.

>I think we should decide on SenderID/PRA all by itself.

Agreed, but I would prefer to find a "win-win" common denominator approach.

> Either we find
>an acceptable solution that will allow everybody to implement it

Publishing the approved mail servers is something everybody can agree to do I think?

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 9 Sep 2004 01:30:14 -0700 (PDT)

> should not share the same DNS mechanism.

This working group has not made such a conclusion. The working group made 
a conclusion that the HELO identity is different and should be pursued 
separately from work being done on "from" identities represented by 
CallerID and SPF, RMX and other proposals and it was decised that mechanics
offered by SPF offer best choice for futher standartization. We have 
not made any conclusion about DNS mechanism that should be used for HELO
identity but agreed to let Dave Crocker and Douglas Otis work further on 
their promising proposal and evaluate it in detail after SenderID work is 
dealt with.

If the above is incorrect understanding about conclusions from interim
meeting in May and list discussions prior to that, then please correct me
and show at which point in the WG dicussions did we reach consensus 
on dns mechanisms for HELO identity checking.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 9 Sep 2004 02:19:45 -0700 (PDT)

> Sounds like the last call might have to be extended or canceled.

The idea that WG would come to consensus and produce complete set of 
documents within 4 months of its beginning was unrealistic to begin with.
(and many have said that in the beginning). 

The last call is appropriate for documents that have undergone serious
review and all major problems have been eliminated. It is not a way to 
find all the problems in the documents that need fixing (did you notice
how many real  tech-errors, doc-bugs, etc have been reported?) - this
should have been done as part of normal process of this WG's work. Even
if we did not have such serious IPR issues, I would be surprised if
documents in their current form were able to progress further - a new 
revision and new review of all the drafts are needed. It is however 
unfortunete that this WG did not seriously gone through each document in 
such a detail until we were formally called upon with this last-call,
I however attribute this to the rush put with our initial schedule.

I do not think its realistic to be able to progress to standard before 
next meeting. In fact it might be unrealistic that we're able to progress 
even at that time, but hopefully we'll be more ready and somewhere by the 
end of the year we really can do this. And even if it happens this way, 
the WG that has done its work in less then one year, would still probably 
be the shortest successfull WG of IETF.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Margaret Olson <[email-masked]>
Date: Thu, 9 Sep 2004 05:32:12 -0400

On Sep 9, 2004, at 4:16 AM, AccuSpam wrote:

> IMHO, the largest deployment hurdle will be to get 63 million of 
> domain owners (growing at 1.5 million per month) to publish and 
> maintain a DNS record.  (See my post at spf-discuss for source).
>
> Presenting these non-technical people with the complexity of choosing 
> which scope their approved mail servers will be used and other complex 
> options we might provide them, seems to run counter to the 80/20 rule 
> for deployment.

A very small minority of those domains will do the actual publishing 
themselves. They will rely on their vendors to publish for them and to 
exchange the necessary information.

The average domain owner does not know what DNS is and if they do, they 
have no idea who manages DNS for them. The record update problem is 
serious and needs to be addressed within the industry, but the end user 
education needs to take the form of telling people that (a) this exists 
and (b) who to call.

Small business domains, of which there are literally millions, 
generally outsource everything. If they are business to consumer they 
may have an outsourced online shopping cart sending transaction 
notices. They almost certainly have an ISP for business person to 
person mail. And any email marketing will be a third provider.

The assumption that small domains all have simple configurations is 
just not valid. It's probably true for small personal domains, and 
small technical domains, but those are not the majority.

Failure to scope will make it harder, not easier, for small domains, if 
for no other reason than figuring out what a rational receiver is 
likely to do with the record will be that much harder for whoever is 
doing the domain administration.  This is currently a very low cost 
service - do we want to make it expensive?

Margaret.

---

From: Tony Finch <[email-masked]>
Date: Thu, 9 Sep 2004 11:07:45 +0100

>   we need to document these impacts on usage.

Perhaps my DEPLOY submission will serve as a starting point. I can
generalise it into an "Interoperability Considerations" section that
covers both /pra and /mailfrom if you think this would be useful.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
MULL OF KINTYRE TO ARDNAMURCHAN POINT: SOUTHEAST 4 OR 5, OCCASIONALLY 3 LATER.
FAIR. GOOD. SLIGHT.

---

From: Tony Finch <[email-masked]>
Date: Thu, 9 Sep 2004 13:14:30 +0100

> prefer SUBMITTER). SPF-classic breaks forwarding but SenderID may be

SUBMITTER is just an optimisation: it has no effect on semantics and it
does nothing to fix the interoperability problems. Most of the problems
arise in a mixed environment with some sites that implement Sender-ID and
some that do not. They are a result of trying to authenticate a message
with respect to an MTA, which is the fundamental error of all designated
sender schemes.

See http://www.imc.org/ietf-mxcomp/mail-archive/msg04462.html for a more
thorough analysis of problems caused by Sender-ID.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST ICELAND: WEST OR SOUTHWEST 4 OR 5, OCCASIONALLY 6 AT FIRST, BECOMING
VARIABLE 3 OR 4. RAIN DYING OUT. MODERATE OR POOR BECOMING GOOD &NBSP;.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 9 Sep 2004 15:21:12 +0200

On Wed, Sep 08, 2004 at 04:28:47PM -0700,
 Daniel Quinlan <[email-masked]> wrote 
 a message of 23 lines which said:

> If patent-encumbered stuff (PRA) is any part of the specification
> (and I see it mentioned in your proposal), then the ASF (including
> the SpamAssassin and JAMES projects) vehemently objects.

Even if, while mentioned in the specification, it is optional and can
be ommitted at will?

> Given that there is a lack of consensus on PRA, it seems like the
> best course is drop PRA entirely and allow the specification authors
> to revise things a bit more freely again.

Crypto-related standards (a field crippled with patents) often use the
very same method to allow interesting (but potentially infringing)
algorithms. See RFC 2246 for instance. You do not object against it
because it mentions the patented IDEA?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 9 Sep 2004 15:16:21 +0200

On Wed, Sep 08, 2004 at 02:25:29PM -0700,
 Mark Lentczner <[email-masked]> wrote 
 a message of 41 lines which said:

> Yes, scopes would need an IANA registry. 

Unless we decide to hardwire the list of possible scopes in the RFC, I
presume? 

> 3) One generally never publishes records about HELO at the same
> domain name as MAIL FROM or PRA.  Hence they'd never share a record.

That's strange. If you publish a SPF record for example.com, surely
mail.example.com (the name you announce in HELO) has a SPF record,
too? (Otherwise, it is trivial to defeat your SPF record, the method
is left as an exercice.)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 9 Sep 2004 15:37:43 +0200

On Thu, Sep 09, 2004 at 04:16:37PM +0800,
 AccuSpam <[email-masked]> wrote 
 a message of 63 lines which said:

> Presenting these non-technical people with the complexity of
> choosing which scope their approved mail servers will be used and
> other complex options we might provide them, seems to run counter to
> the 80/20 rule for deployment.

In most cases, all the scopes (or at least PRA and 2821 MAIL FROM) are
the same. So, the default scope will probably be fine for them.

"Unified SPF" (http://spf.pobox.com/unified/1-unified.txt) discusses
this issue. See 2.2.1 and 2.2.2.

---

From: David Woodhouse <[email-masked]>
Date: Thu, 09 Sep 2004 14:56:33 +0100

On Thu, 2004-09-09 at 15:16 +0200, Stephane Bortzmeyer wrote:
> Mark Lentczner <[email-masked]> wrote:
> too? 

strcmp("example.com", "mail.example.com");

As Mark said, they don't _share_ a record. They each have their own.

-- 
dwmw2

---

From: Andrew Newton <[email-masked]>
Date: Thu, 9 Sep 2004 10:20:34 -0400

> on dns mechanisms for HELO identity checking.

The conclusion was that CSV semantics should not put into Sender ID, 
which uses a particular syntax known as SPF syntax and the TXT & SPF 
records.

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

-andy

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 9 Sep 2004 08:34:04 -0700 (PDT)

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

There appears to be problems with above statement. The problem has to do 
with interpretation of how names "SenderID" and "CSV" are used. It appears 
based on yesterday's statement that you imply that you were using both in 
more general sense and assuming SenderID to mean anything that working 
group comes up with that is using SPF syntax and CSV to mean HELO 
identity checking in general.

But that is not how I or many others understand this. For me SenderID is 
particular proposal made when attempting to merge SPF with CallerID and 
that means its particular to the PRA identity (that is why until now 
SenderID was always distinguished from SPF classic and it was understood 
that SenderID does not include SPF classic but that MARID may at later 
time standarding SPF classic envelope mail-from checks on its own after 
conclusion of SenderID identity work. Similarly CSV is also particular 
proposal made by Dave Crocker on the HELO identity checking.

In that sense merging these two completely different and particular 
proposals or even discussing it would not have been productive for the 
group so I agree with what you said in that post. I understood it to mean 
that we should focus on SenderID identity at the time and discuss other 
identities and specific CSV proposal later.

I do not see the above to imply that we agreed (or disagreed) that we can 
not include checking other identities by means of SPF syntax, again it
was understood that discussions of that will take place later on. And
since we agreed not discuss CSV or HELO identity checking until SenderID
is worked on, it means there was no discussion and thus no consensus about 
what dns symantics should be used with that identity...

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Daniel Quinlan <[email-masked]>
Date: Thu, 9 Sep 2004 11:38:02 -0700

> Even if, while mentioned in the specification, it is optional and can

Yes, I think so.  I understand the fine distinction you are trying to
make with this proposal, but it appears to be a back door (and I don't
think you are trying to be deliberately harmful to open source) for the
IETF to standardize a patent-encumbered technology in order to push
Sender ID out the door as soon as possible.  In the end, it would become
a de-facto requirement as the proposal stands.  Also, it is not certain
that the patent will be invalidated or that anyone will have the
resources to invalidate it, so relying on that strategy as part of the
reasoning for this proposal is not a valid argument.  Still, it's
possible the license will be fixed and this will become a moot point.
(I still would like to see the scope become modular as I noted in one of
my earlier technical last call comments.)

We want some method to parse RFC 2822 headers to be part of the
standard.  However, PRA is off limits to us due to how the license is
currently designed.  An unencumbered method to authenticate RFC 2822
messages that is permitted and encouraged is needed.  I believe that the
"experimental" PRA standard will end up an effective requirement,
especially given the intense campaign of the last few weeks to get
companies behind the encumbered standard.

> algorithms.

If the field of crypto is crippled with patents, are you keen on doing
the same to email?

> See RFC 2246 for instance. You do not object against it because it
> mentions the patented IDEA?

False analogy.  There are many alternatives to IDEA that do basically
the same thing and a bunch of them are mentioned in RFC 2246.  In
addition, nobody needs IDEA to authenticate email as best possible.  If
PRA is implicitly the way you connect RFC 2822 with Sender ID, then
email systems will be required to support it:

 - at send time, to conform with systems that use PRA at receive time
   (even when not desired)
 - at receive time, to conform with sites that only send with the PRA
   scope

It seems likely it will become a requirement by virtue of how it is used
and because there is no alternative being pursued by the IETF.  I think
we can find a way to resolve this (either replacing PRA with an
unencumbered alternative or an open license on the PRA patent(s)), but
relying on the patent going away is wishful thinking.

Daniel

---

From: "John Glube" <[email-masked]>
Date: Thu, 9 Sep 2004 15:29:37 -0400

Andy,

You asked:

The question before the working group: assuming no
technical errors with the above, is there anybody who
vehemently objects with this proposal?

My comment is not a vehement objection, but rather a strong
suggestion.

Having strongly supported Dave Crocker's earlier suggestion
of a security and operations review of Sender-ID by
graybeards, I second Dave's suggestion, adopt his reasoning
and strongly support the request that the co-chairs have a
security and operations review carried out by graybeards on
any proposal for pra/mailfrom checks before the draft
specifications go through last call.

As a secondary matter, I simply note the draft patent
license contains the following restriction:

Microsoft ... hereby grant You a perpetual ...worldwide
license under Microsoft’s Necessary Claims to use ...
object code versions of Licensed Implementations only as
incorporated into Licensed Products and solely for the
purpose of conforming with the Sender ID Specification.

(See section 2.1 of the draft Patent License.)

My read of the last restriction ... "and solely for the
purpose of conforming with the Sender ID Specification"
precludes "object code versions of Licensed Implementations
only as incorporated into Licensed Products" being used for
any other purpose except to "conform with the Sender ID
Specification."

(The Sender ID Specification being defined as the
combination of draft-marid-pra with draft-marid-core.)

I presume a proposal which includes both pra and mailfrom
checks would involve elements of draft-marid-pra and
draft-marid-core, so giving rise to Microsoft's IPR claim
and the draft patent license with the noted restriction.

As such, the restriction contained in the draft patent
Sender-ID license would preclude network administrators
from incorporating both mailfrom and pra checks without
obtaining separate permission from Microsoft.

On this point, please note the following Q & A from
Microsoft's FAQ:

Q8: What if I want to use the Sender ID technology in some
other context, still related to email but perhaps not
related to Sender ID? Will Microsoft sue me? 

A8: Microsoft is committed to working with companies in a
collaborative way to license our Intellectual Property (see
http://www.microsoft.com/mscorp/ip/). If Microsoft is
granted patent rights that cover the Sender ID
specification (currently pending) it will make those rights
available at no cost for anyone to implement and use the
Sender ID specification. Microsoft will need to see what
patent rights are granted by the US Patent and Trademark
Office to even know for sure what rights it has to offer.
Since it is impossible to contemplate every possible use of
it Sender ID patent rights we cannot make a commitment up
front to specific license terms. We invite anyone
interested in using Microsoft’s IP to innovate and compete
in the marketplace to come talk to us.

In the circumstances, should the WG wish to proceed with a
protocol which incorporates both pra/mailfrom checking
based on one version with multiple scopes, I urge the WG
co-chairs to seek clarification from Microsoft on this
point.

Why? Because if my understanding is correct, it means
software developers cannot access the Microsoft Necessary
Claims under the draft Sender-ID patent license to develop
object code which allows for pra/mailfrom checking without
getting a further license from Microsoft, which may or may
not be forthcoming. 

In turn as matters now stand, without clarification from
Microsoft, this would seem to be a further impediment to
widespread implementation of this proposal.

John

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.752 / Virus Database: 503 - Release Date: 03/09/2004

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 9 Sep 2004 22:44:19 +0200

On Thu, Sep 09, 2004 at 02:56:33PM +0100,
 David Woodhouse <[email-masked]> wrote 

> As Mark said, they don't _share_ a record. They each have their own.

Well apparently, my english was not good enough to make me clear.

1) When you publish a SPF (I said SPF, not SenderID) record for
example.com, if your mail server is mail.example.com, you *also*
publish a SPF record for mail.example.com. Always. Otherwise, there is
a trivial way of spoofing you.

2) Since you already have a SPF record for both names, adding the HELO
check in SenderID changes nothing. You already had the two records.

---

From: David Woodhouse <[email-masked]>
Date: Thu, 09 Sep 2004 22:30:47 +0100

> check in SenderID changes nothing. You already had the two records.

I suspect we're in agreement. The point is they should be separate. SPF
'classic' didn't get this right. Recipients should not infer anything
about HELO from the RFC2821 record, and vice versa.

The latter being the more important to me -- I'm happy enough to publish
records stating who may HELO with my hostnames but until/unless the
whole world (including those who haven't even discovered ESMTP yet)
upgrades to the Brave New World neither the RFC2821 nor RFC2822 records
are workable.

-- 
dwmw2

---

From: AccuSpam <[email-masked]>
Date: Fri, 10 Sep 2004 07:53:17 +0800

>exchange the necessary information.

Yes and no.

Agreed for the majority of domains that do publish, and this is precisely what worries me.  Then you have 3rd parties (not the ones sending the e-mail) making decisions and assumptions for the actual users, and thus:

1. More likelihood of a war on scope where some camps refuse to declare "mailfrom" or "spf", because they have a vested interest to declare only "pra" or vice versa.

2. More likelihood that the actual users voilate the rules in the DNS record, because the user has no concept they exist or what they mean.

3. Thus because of the two scenarios above and because recipients could care less about the sender's woes, you will have adhoc algorithms sprouting about to deal with the fragmented reality that results.

And no, disagree, that the majority of domains will publish records, especially if there is no concensus, much complexity and confusion about scoping, useage, confusing press statements (lack of concensus and simplicity), etc..  

>education needs to take the form of telling people that (a) this exists 

What exists?  How do we explain it to them if the underlying standard is confused and fragmented?  We are already seeing confusing press statements about SPF that say spammers are using it.

We are much better off to get a simple concensus, than a complex fragmented mess.  In the latter scenario, Microsoft will "save the day" by being the unified, de facto choice.  Just observe history.

[...]
>small technical domains, but those are not the majority.

What is your point of saying this?  You mean we can not provide a simple way to specify the approved mail servers?  You mean that we can never make it simple enough to explain to users?

>doing the domain administration.

Can you tell me today the differences between the way AccuSpam, SpamAssassin, CloudMark, and a zillion other anti-spam are going to interpret the SPF or SenderID DNS record??

I assert that specifying scope is nothing more than a hopeful hint.  In reality, the only the scope is specified by what data you are actually exposing.

>  This is currently a very low cost 

How does not specifying scope make it more expensive?

I think specifying scope and having multiple records is going to make it much more expensive for both maintainers, receivers (verifiers), and also in terms of fragmentation and proprietary wars.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Sep 2004 14:59:59 +0200

On Wed, Sep 08, 2004 at 08:45:49PM -0400,
 [email-masked] <[email-masked]> wrote 
 a message of 43 lines which said:

> when receiving sites perform multiple checks.

Please read http://spf.pobox.com/unified/2-best.txt for a start.

> In particular, it must be the case that a site checking both
> mailfrom and pra should always reject mail when mailfrom fails (even
> if pra passes).  This might be as simple as saying if any test
> fails, the message is considered to have failed.

I'm not sure this should be mandated. We should standardize protocols,
not policies. It is important that pass(SPF_record,identity) always
return the same value, whoever the tester is, but not so important to
decide what to do when it fails or succeeds.

> mechanism--maybe eq:string1:string2.  You'd want to be able to say

Nice but it would mean a non-trivial change to SPF implementations
(which, at the present time, are almost ready to implement -protocol).

---

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

On Thu, Sep 09, 2004 at 11:38:02AM -0700,
 Daniel Quinlan <[email-masked]> wrote 
 a message of 68 lines which said:

> messages that is permitted and encouraged is needed.  

OK, I agree with the idea of having two more scopes:

1) "from", pure and simple plain old 2822 From

2) "fetchmail", meaning the algorithm explained in
http://www.imc.org/ietf-mxcomp/mail-archive/msg04356.html

Note that I take no position on the usefulness of these scopes. I
simply believe that, given the current state of the art about email
identities, it is better to have choice.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 11 Sep 2004 00:52:52 +0200

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

Not very different from spf2.0/mailfrom if I got this right.
The conclusion in RfC 3834 (4) is:

| The Return-Path address is really the only one from the
| message header that can be expected, as a matter of protocol,
| to be suitable for automatic responses that were not
| anticipated by the sender.

> I simply believe that, given the current state of the art
> about email identities, it is better to have choice.

Yes.  For an unmodified PRA to work RfC 2476 could be updated
(8.1 MAY insert Sender => MUST insert Sender), but actually it
would be simpler to fix the algorithm (pretend that a Sender
matching the Return-Path is there if necessary).

                         Bye, Frank