Subject: [ietf-dkim] SSP issues status

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Jan 2008 18:25:27 +0000

Hi All,

Sorry about the delay with this, Barry and I had problems syncing
up over the holiday and have only now gotten this done.

The attached contains our view on the current list of SSP issues [1]
except for those opened in the last week or so. (Sorry the
formatting's a bit crappy.)

Can you check that these seem ok, or comment where they don't?
Please comment in the original thread so we can more easily
track things.

The editors of the I-D have a new revision almost ready to post,
so what we'd suggest is that we let them watch the list traffic
over the next week or so, then have them post an I-D reflecting
where we are with these issues, and then we can schedule doing
the jabber/concall thing to progress if necesary.

Regards,
Stephen.

[1]
https://rt.psg.com/Search/Results.html?Order=ASC&Query=Queue%20%3D%20'dkim'%20AND%20(Status%20%3D%20'open'%20OR%20Status%20%3D%20'new')&Rows=50&OrderBy=id&Format=

1382	(SSP) New resource record type	new	dkim	Nobody	0 [email-masked]	1 years ago		1 years ago	0
		Proposal: ACCEPT(CLOSE), we seem to have WG consensus to use TXT only, and that's in the current I-D

1399	clarify i= vs. SSP	open	dkim	Nobody	0 [email-masked]	1 years ago		1 years ago	0
		Proposal: OPEN, Maybe merge this with a newer one? Probably 1519

1402	Applicability of SSP to subdomains	open	dkim	Nobody	0 [email-masked]	1 years ago		6 days ago	0
		Proposal: CLOSE, process this in the more recent issue #1534 

1512	ssp should not link "all" and third parties	new	dkim	Nobody	0 [email-masked]	6 weeks ago		6 weeks ago	0
		Proposal: OPEN, we seemed to reach consensus in this thread [1] but I'm not clear what the resulting 
		change to the spec should be. presumably we can close this with the next rev
		
		[1] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008275.html         

1513	the new handling tag	new	dkim	Nobody	0 [email-masked]	6 weeks ago		6 weeks ago	0
		Proposal: OPEN, needs more discussion

1519	SSP-01 Unnecessary constraint on i= when asserting "strict"	open	dkim	Nobody	0 [email-masked]	13 days ago		13 days ago	0
		Proposal: OPEN, needs more discussion, Doug proposed some changes that Jim didn't like in this thread [2]

		[2] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008248.html

1520	limiting SSP to statements that inform recipient about (potential) signer actions	new	dkim	Nobody	0 [email-masked]	9 days ago		8 days ago	0
		Proposal: OPEN, we seem to have about 3 for this and about 6 against, but more opinions are needed, thread is [3]

		[3] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008423.html

1521	Limit the application of SSP to unsigned messages	new	dkim	Nobody	0 [email-masked]	9 days ago		9 days ago	0
		Proposal: REJECT, but some wording changes may be needed for the next rev, thread is [4] I mainly saw opposition to the change suggested
		in the issue, and little support, but some text clarifying changes were suggested (e.g. [5]).

		[4] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008424.html
		[5] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008467.html 
		
1522	Discussion of query traffic overhead	new	dkim	Nobody	0 [email-masked]	9 days ago		9 days ago	0
		Proposal: ACCEPT(CHECK), thread is [6], 2 opinions that there's no problem, but some concern that the text 
		in the draft is incomplete wrt DNS lookups; should hopefully be closed with next rev, check again then

		[6] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008425.html

1523	Service Model summary	new	dkim	Nobody	0 [email-masked]	9 days ago		9 days ago	0
		Proposal: OPEN, thread is [7], no real discussion but hopefully clarified by next rev, check again then

		[7] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008426.html

1524	Signature semantics	new	dkim	Nobody	0 [email-masked]	9 days ago		9 days ago	0
		Proposal: OPEN, thread is [8], lots of discussion, no clear consensus, one possible actionable change [9]

		[8] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008427.html
		[9] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008603.html

1525	Restriction to posting by first Author breaks email semantics	new	dkim	Nobody	0 [email-masked]	9 days ago		9 days ago	0
		Proposal: REJECT, thread is [10], mailing list discussion has not unearthed support for a change.

		[10] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008428.html
		[11] http://tools.ietf.org/html/rfc5016#section-5.3

1526	SSP applies only to receive-side filtering engine and not end-users	new	dkim	Nobody	0 [email-masked]	9 days ago		9 days ago	0
		Proposal: ACCEPT(CHECK), thread is [12] there seemed to be consensus to make such changes, but no specific changes
		have been proposed, so we'll have to check the next rev

		[12] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008429.html

1527	SSP threats analysis needed	new	dkim	Nobody	0 [email-masked]	9 days ago		9 days ago	0
		Proposal: ACCEPT(CHECK), threads [13,14,15] general agreement that this is good, but no concrete text proposals
		for the I-D, nor has anyone stepped up to do concerted additional work on this, nor have any specific 
		new threats been discussed on the list, so we suggest letting the editors work on the security considerations
		section in the next I-D, and then people can raise any specific threats they see as not being covered
		in that rev (please send suggested text to the editors if you've got any)

		[13] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008430.html
		[14] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008701.html
		[15] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008512.html

1528	false negatives and false positives	new	dkim	Nobody	0 [email-masked]	9 days ago		9 days ago	0
		Proposal: OPEN, thread is [16] little discussion, might be a subset of issue 1527

		[16] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008431.html

1529	Change "originator" to "author"	new	dkim	Nobody	0 [email-masked]	9 days ago		9 days ago	0
		Proposal: ACCEPT(CHECK), thread is [17] we seem to have consensus on this one

		[17] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008432.html

1530	replace use of term "suspicious"	new	dkim	Nobody	0 [email-masked]	9 days ago		9 days ago	0
		Proposal: ACCEPT(CHECK), thread is [18] we seem to have conesnsus for a change, suggest letting the
		editors pick something and then go with that or raise a new issue

		[18] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008433.html

1531	"does not exist"	new	dkim	Nobody	0 [email-masked]	9 days ago		9 days ago	0
		Proposal: ACCEPT(CHECK), thread is [19], seems to call for some clarifying text and/or a better
		definition, suggest letting editor work that and check next rev

		[19] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008434.html

1532	revise list labeling	new	dkim	Nobody	0 [email-masked]	9 days ago		9 days ago	0
		Proposal: ACCEPT(CHECK), thread is [20], editor says he'll work it for next rev

		[20] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008435.html

1533	strict vs. integrated	new	dkim	Nobody	0 [email-masked]	9 days ago		9 days ago	0
		Proposal: OPEN, thread is [21] little discussion & no clear conclusion to act on so far

		[21] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008435.html

1534	Applying SSP to sub-domains does not work	new	dkim	Nobody	0 [email-masked]	9 days ago		9 days ago	0
		Proposal: OPEN, thread is [22] needs more discussion as to whether current I-D represents
		consensus or not (Note: this replaces issue 1402)

		[22] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008437.html

1535	Simplify SSP decision tree	new	dkim	Nobody	0 [email-masked]	9 days ago		9 days ago	0
		Proposal: ACCEPT(CHECK), thread is [23], some discussion but mostly about issue 1540 on t=testing,
		suggest letting editor make that and other changes and then see if this can be closed or if
		there's still an opinion that the state machine is over complex

		[23] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008670.html
		
1536	definition of action terms	new	dkim	Nobody	0 [email-masked]	9 days ago		9 days ago	0
		Proposal: ACCEPT(CHECK), thread is [24], little discussion but the terms aren't currently
		defined, so suggest letting editors add definitions and checking those in next rev (and
		do provide editors with input please)

		[24] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008439.html

1537	Reputation is out of scope or define it	new	dkim	Nobody	0 [email-masked]	8 days ago		8 days ago	0
		Proposal: REJECT, thread is [25] Eliot's response [26] seems to indicate that the I-D already
		satisfies the request in the isseu

		[25] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008472.html
		[26] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008660.html
 
1538	review and repair of normative vocabulary usage	new	dkim	Nobody	0 [email-masked]	8 days ago		8 days ago
		Proposal: ACCEPT(CHECK), thread is [27], no discussion, let's do that review on the next I-D

		[27] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008491.html

1540	deprecate t=testing
		Proposal: ACCEPT(CHECK), thread is [28] seems to have consensus

		[28] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008594.html

XXX1	remove [FWS]
		Proposal: OPEN, no discussion, thread is [29]
	
		[29] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008477.html

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 11 Jan 2008 06:40:52 +0100

> Can you check that these seem ok, or comment where they don't?

Do you have <http://article.gmane.org/gmane.ietf.dkim/8533/> ?

I don't see it, disussed deep within some monster-threads, 
but the report was fairly clear:

| Subject: NEW ISSUE: remove [FWS] (was: SSP Issues list)
| Date: Mon, 10 Dec 2007 16:25:24 +0100
[...]
| Message-ID: <[email-masked]>
| References: <[email-masked]>
[...]
| Stephen Farrell wrote:
|
| > If anyone else has any SSP issues they'd like to
| > raise, now would be a good time.
|
| [FWS] within DNS records is just wrong.
|
| Frank

---

From: Jim Fenton <[email-masked]>
Date: Thu, 10 Jan 2008 22:38:00 -0800

> | [FWS] within DNS records is just wrong.

It's the "folding" part that is the problem here, and we should be using
[WSP], right?

-Jim

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 11 Jan 2008 08:42:49 +0100

> It's the "folding" part that is the problem
> here, and we should be using [WSP], right?

Right, that solves *one* of *three* potential
problems.

The second problem might be WSP, on the general
list we just discuss this wrt John's net-utf8
draft (Last Call).  John argues that HTAB is
typically ambiguous and SHOULD be avoided. 

If you buy that you get [SP] instead of [WSP],
but I think what you really want is either *SP
or *WSP, zero or more spaces, not only zero or
one.  [FWS] without folding is *WSP, not [WSP]. 

If that's the case we hit the third potential
problem, record size.  Allowing to "waste space"
(pun intended) is not what you want in a DNS
record.  SPF allows 1*SP instead of limiting
itself to SP where a space is really needed to
separate terms.

But SSP introduces unnecessary [FWS], where it
is not required as separator, simplified:

| tag = "dkim" [FWS] "=" [FWS] ( "x" / "y" )

The "=" already separates name and value, you
could as well write:

| tag = "dkim=" ( "x" / "y" )

Conserving space might be irrelevant depending
on other issues, but the draft does not mention
UDP at all, unlike RFC 4408 3.1.4.

"Allow beautiful SSP records for human readers"
is a rather dubious design goal in RFC 5016.

 Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 11 Jan 2008 15:38:21 -0000

> | tag = "dkim=" ( "x" / "y" )

The world is full of protocols which ask you to write parameters of the  
form
    <name> "=" <value>
Some of them allow SP/WSP around the "=", some allow folding as well  
(maybe even comments), and some allow nothing. The biggest problem is for  
users to remember what they are/are not allowed to do in each case. Our  
first duty should be not to make that problem worse (supposing we can  
discern in which direction "worse" arises).

The nearest and best knwon precedent is MIME <parameter>s, which allow  
full CFWS around the "=" (though it requires rather careful reading of RFC  
822 to confirm that). Of course, nobody (FSVO "nobody") goes the whole hog  
by putting comments there, nor even spaces, but whitespace is quite  
common. Which suggests we should allow at least WSP*. I am happy to forget  
the full CFWS, and probably FWS too.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Fri, 11 Jan 2008 07:57:20 -0800

Charles Lindsey wrote:
> (maybe even comments), and some allow nothing. The biggest problem is 
> for users to remember what they are/are not allowed to do in each case. 
> Our first duty should be not to make that problem worse (supposing we 
> can discern in which direction "worse" arises).
> 
> full CFWS around the "=" (though it requires rather careful reading of 
> RFC 822 to confirm that). Of course, nobody (FSVO "nobody") goes the 
> whole hog by putting comments there, nor even spaces, but whitespace is 
> quite common. Which suggests we should allow at least WSP*. I am happy 
> to forget the full CFWS, and probably FWS too.

I think I'm mostly with Frank -- WSP between the tag=value seems pretty
dubious to me. DNS isn't the same as 2822 in that manglers are not going
to come in and arbitrarily add FWS. It would be nice to keep a SP/WSP
after tag=value; though for readability.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Jan 2008 09:22:16 -0800

Stephen Farrell wrote:
> The attached contains our view on the current list of SSP issues [1] except
> for those opened in the last week or so. (Sorry the formatting's a bit
> crappy.)
...
> Can you check that these seem ok, or comment where they don't?
...

> Proposal: REJECT, but some wording changes may be needed for the next rev,
> thread is [4] I mainly saw opposition to the change suggested in the issue,
> and little support, but some text clarifying changes were suggested (e.g.
> [5]).

Your reading of the archive shows rather more complete and definitive 
discussion than mine.

Would you please explain the basis for assessing that this topic got 
sufficient discussion and that there was rough consensus on it?

This is perhaps the most fundamental issue on the list, so it would be 
advisable that we be quite careful about its consideration and resolution.

Thanks.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Barry Leiba <[email-masked]>
Date: Mon, 14 Jan 2008 17:17:46 -0500

Stephen Farrell said...
> up over the holiday and have only now gotten this done.

Stephen is being too kind.  He had nothing to do with the delay; that's 
down to me.  And thanks, Stephen, for getting the list posted to the list.

Eliot has set us up for a conference call this Thursday, 17 Jan, as we'd 
originally scheduled back in December (actually, we'd planned to start 
on 10 Jan, but we didn't make that; see "delay" above).  It'll go along 
with a jabber meeting, for which we'll use the normal DKIM jabber chat 
room, < [email-masked] >.

The conference call will be at 16:00 UTC (11:00 US Eastern, 08:00 US 
Pacific, 17:00 in much of Europe), and is scheduled for an hour.  The 
call-in information is pasted below.

Barry

---------------------------------------------
Date/Time:               January 17, 2008 at 05:00PM Europe/Amsterdam
Length:                  60
Frequency:               once
Meeting ID:              312851247
Meeting Password:

Global Access Numbers:
http://cisco.com/en/US/about/doing_business/conferencing/index.html
(See list below.)

TO ATTEND A VOICE ONLY CONFERENCE
1. Dial into Cisco Unified MeetingPlace (view the Access Numbers or link 
above)
2. Press 1 to attend the meeting
3. Follow the prompts to enter the Meeting ID 312851247 and join the meeting

SUPPORT
Information about this Conference: Contact Eliot Lear, 41448787525
Cisco IT Support Center: Attend the Voice Conference and then press #0 
on your phone keypad

GLOBAL ACCESS NUMBERS

COUNTRY            LOCATION           LOCAL NUMBER            TOLL 
FREE-FREEFONE
Algeria            Algiers            +213.21.98.9047
Argentina          Buenos Aires       +54.11.4341.0101
Australia          Canberra           +61.2.6216.0643
                    Melbourne          +61.3.9659.4173
                    North Sydney       +61.2.8446.5260
Austria            Vienna             +43.12.4030.6022
Azerbaijan         Baku               +994.12.437.4829
Belgium            Brussels           +32.2.704.5072
Bosnia &
Herzegovina        Sarajevo           +387.33.56.2898
Brazil             Brasilia           +55.613.424.0220
                    Rio de Janeiro     +55.21.2483.6302
                    Sao Paulo          +55.11.5508.6311
Bulgaria           Sofia              +359.2.937.5938
Canada             Calgary            +1.403.514.2435
                    Edmonton           +1.780.441.3715
                    Halifax            +1.902.474.0214
                    Kanata             +1.613.254.0005
                    Markham            +1.905.470.4810
                    Montreal           +1.514.847.6875
                    Ottawa             +1.613.788.7250
                    Quebec             +1.418.634.5645
                    Regina             +1.306.566.6410
                    Toronto            +1.416.306.7230
                    Vancouver          +1.604.647.2350
                    Winnipeg           +1.204.336.6610
Chile              Santiago           +56.2.431.4936
China              Beijing            +86.10.8515.5666
                    Chengdu            +86.28.8696.1333
                    Guangzhou          +86.20.8519.3333
                    Shanghai           +86.21.2302.4333
Colombia           Bogota             +57.1.325.6065
Costa Rica         San Jose           +506.201.3617
Croatia            Zagreb             +385.1.462.8908
Czech Republic     Prague             +420.22.143.5100
Denmark            Aabyhoj            +45.8.939.7131
                    Copenhagen         +45.3.958.5010
Dominican Republic Santo Domingo      +45.8.939.7131
Egypt              Cairo              +20.22.488.5377
Estonia            Tallinn            +372.6.67.5998
Finland            Espoo              +358.204.70.6227
France             Paris              +33.15.804.3116
Germany            Eschborn           +49.619.6773.9002
                    Hallbergmoos       +49.811.554.3016
Greece             Athens             +30.210.638.1303
Hong Kong          Hong Kong          +852.3406.1000
Hungary            Budapest           +36.1.225.4621
India              Bangalore          +91.80.4103.3979
                    Chennai 
+1.800.102.3979
                    Mumbai IL & FS     +91.22.4043.4030
                    New Delhi          +91.11.4261.1088
Indonesia          Jakarta            +62.21.7854.7476
Ireland            Dublin             +353.1.819.2717
Israel             Netanya            +972.9.892.7026
Italy              Milan              +39.039.629.5068
                    Rome               +39.06.5164.4006
Japan              Tokyo Akasaka      +81.3.5763.9394         +0120.312271
Kazakhstan         Almaty             +7.327.244.2198
Korea              Seoul Asem         +82.2.3429.8102
Latvia                                Please see Finland
                                       Number
Lebanon            Beirut             +961.1.97.7011
Malaysia           Kuala Lumpur       +60.3.2081.1515
                    Penang             +60.4.631.5125
Mexico             Mexico City        +52.55.5267.1800
                    Monterrey          +52.81.8221.2462
                    Guadalajara        +52.33.3770.1206
Morocco            Casablanca         +212.2.242.4088
Netherlands        Amsterdam          +31.20.357.1487
New Zealand        Auckland           +64.9.355.1968
                    Wellington         +64.4.496.5554
Nigeria            Lagos              +234.1.462.1048
Norway             Oslo               +47.23.27.3647
Pakistan           Islamabad          +92.51.209.7994
Peru               Lima               +51.1.215.5101
Philippines        Makati (Manila)    +63.2.750.5886
Poland             Warsaw             +48.22.572.2615
Portugal           Lisbon             +351.21.446.8756
Puerto Rico        San Juan           +1.787.620.1865
Romania            Bucharest          +40.21.302.3511
Russia             Moscow             +7.495.230.5612
Saudi Arabia       Dhahran            +966.3.865.7998
                    Jeddah             +966.2.653.6555
                    Riyadh             +966.1.218.2666
Serbia             Belgrade           +381.11.209.2098
Singapore          Singapore Capital  +65.6317.7088
Slovakia           Bratislava         +421.2.5825.5309
Slovenia           Ljubljana          +386.1.582.3158
South Africa       Cape Town          +27.21.413.4502
                    Johannesburg       +27.11.267.1011
                    Pretoria           +27.12.844.7401
Spain              Barcelona          +34.93.393.4037
                    Madrid             +34.91.201.2149
Sweden             Gothenburg         +46.31.63.4409
                    Stockholm          +46.8.685.9035
Switzerland        Glattzentrum       +41.44.878.7335
Taiwan             Taipei             +886.2.8758.7088
Thailand           Bangkok            +66.2.263.7008
Turkey             Istanbul           +90.212.335.0208
Ukraine            Kiev               +380.44.391.3698
United Arab
Emirates(UAE)      Dubai              +971.4.390.7840
United Kingdom     Bedfont Lakes      +44.20.8824.0117
                    Edinburgh          +44.131.561.3643
                    London City        +44.20.7496.3743
United States      East               +1.919.392.3330        +1.866.349.3520
                    West               +1.408.525.6800 
+1.866.432.9903
Venezuela          Caracas            +58.212.902.0210
Vietnam            Ho Chi Minh        +84.8.823.3418
                    City (Saigon)
                    Hanoi              +84.4.974.6250
---------------------------------------------
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Jan 2008 22:42:10 -0800

> room, < [email-masked] >.

Actually, you originally said January 3.  Then we heard nothing about the 
matter for a month.  That was the last note I see posted on this matter from 
your or Steve, with no resolution as to schedule:

> Barry Leiba wrote:
>> Barry Leiba said:
>>> I should point out that we're off by ONE DAY on the 30-day notice issue.
>>> If you think we should toss out the 9 Jan session on that basis, OK, 
>>> we will.
...
>> Still, the rest of what I said stands:  If any participants, or the ADs, 
>> think that 23 days' notice isn't sufficient, or that 3 Jan is too close 
>> to the new year, we can lose that one and start on 10 Jan.

So effectively the issue has changed from whether 30 days notice really is 
required to whether what is really only 3 is somehow acceptable.  (RFC2418, 
Section 3.1

And no, this isn't about being a stickler about the rules.  It's about being 
inclusive.

Using the two "rejected" issues as metrics, it looks a lot as if we aren't 
really trying to resolve issues on the mailing list.  That's a mistake, since 
that is the most inclusive channel.

d/
-- 

   Dave Crocker

---

From: "J D Falk" <[email-masked]>
Date: Tue, 15 Jan 2008 12:15:57 -0500

Dave Crocker wrote:

> So effectively the issue has changed from whether 30 days notice
> really is required to whether what is really only 3 is somehow
> acceptable.  (RFC2418, Section 3.1
> 
> And no, this isn't about being a stickler about the rules.
> It's about being inclusive.

Yep...given the lack of further comment about the recurring phone calls,
I assumed they wouldn't be happening and will instead be unavailable
during that time.

That's just me, though, and I'm assuming there'll be both a transcript
and an opportunity for further comment afterwards -- right?

--
J.D. Falk
Receiver Products
Return Path

---

From: Steve Atkins <[email-masked]>
Date: Tue, 15 Jan 2008 09:52:37 -0800

> I assumed they wouldn't be happening and will instead be unavailable

+1

> and an opportunity for further comment afterwards -- right?

+1

Cheers,
   Steve

---

From: John Levine <[email-masked]>
Date: 15 Jan 2008 18:25:06 -0000

>> I assumed they wouldn't be happening and will instead be unavailable

Not a great time for me, either, givm the short notice.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Eliot Lear <[email-masked]>
Date: Tue, 15 Jan 2008 19:32:44 +0100

Dear Chairs & Dave,

>
> Actually, you originally said January 3.  Then we heard nothing about 
> the matter for a month.  That was the last note I see posted on this 
> matter from your or Steve, with no resolution as to schedule:

I tend to agree with Dave on this one.  To start with there was a lot of 
confusion about the dates.  First there was a January 3rd mixup, and 
then there was a mixup between January 9th and 10th.  I would suggest 
that erring toward the side of openness dictates a postponement for 
another few weeks.  In the meantime, we can continue to argue about open 
issues on the net.

Eliot

---

From: Jim Fenton <[email-masked]>
Date: Tue, 15 Jan 2008 14:22:33 -0800

Back on December 11, Stephen Farrell wrote:

> We're looking at scheduling 1 hour calls each Thursday
> in Jan (i.e. 3rd, 10th, 17th, 24th and 31st) at 1700 UTC.
>   

> acceptable.  (RFC2418, Section 3.1

I penciled in the meetings when they were originally proposed, not sure 
why this is a surprise to people.  January 3 and 10 got cancelled for 
various reasons (proximity to the holidays and lack of 30-day notice, I 
think) but the rest are still there.

-Jim

---

From: "J D Falk" <[email-masked]>
Date: Tue, 15 Jan 2008 18:04:56 -0500

Jim Fenton wrote:

> I penciled in the meetings when they were originally proposed, not
> sure why this is a surprise to people.  January
> 3 and 10 got cancelled for various reasons (proximity to the holidays
> and lack of 30-day notice, I

Could you recap the dates & times that weren't cancelled?

---

From: Jim Fenton <[email-masked]>
Date: Tue, 15 Jan 2008 16:24:05 -0800

> Could you recap the dates & times that weren't cancelled?

Isn't that in the part you cut out of my message:

> in Jan (i.e. 3rd, 10th, 17th, 24th and 31st) at 1700 UTC.

So that would be the 17th, 24th, and 31st, at 1700 UTC, assuming 
some/all of these aren't cancelled.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Tue, 15 Jan 2008 19:17:10 -0800

Jim Fenton wrote:
> why this is a surprise to people. 

Because there was no follow-through to confirm the dates, after the first date 
was questioned and because nothing happened for the first two dates.

>    January 3 and 10 got cancelled for 

They got canceled? Oh.

When did that happen? Pointer to the archive, please.

d/

-- 

   Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Jan 2008 14:34:01 +0000

Dave Crocker wrote:
>> except
>> 1521    Limit the application of SSP to unsigned messages    new    
>> dkim    Nobody    0
>> [email-masked]    9 days ago        9 days ago    0
> 

> sufficient discussion and that there was rough consensus on it?

See above "I mainly saw..."

> advisable that we be quite careful about its consideration and resolution.

Sure. It'd be fine if others also go back through the thread and
see what they think and/or continue the discussion if that's needed.

S.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 16 Jan 2008 06:52:19 -0800

> See above "I mainly saw..."

Qualifiers are nice, but pointing out that they were used does not provide an 
explanation for an assessment.

d/

-- 

   Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Jan 2008 15:23:02 +0000

Dave Crocker wrote:
> Qualifiers are nice, but pointing out that they were used does not 
> provide an explanation for an assessment.

Sorry Dave, but I don't see how I can provide a better explanation
than that. I really don't get what you find unclear there.

S.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 16 Jan 2008 07:46:40 -0800

> than that. I really don't get what you find unclear there.

Suppose I asserted that the pattern of your responses to me publicly was 
mainly hostile.  You then ask me to explain the basis for that assessment and 
I respond that I said "mainly".

Would you really find my response to be an "explanation"?

I suspect not.

To explain something is to discuss and justify the underlying criteria and 
perceived facts.

The archive is a body of data.  There was an analytic process that you and 
Barry used to assess it, to come to your conclusion. Presumably that process 
had objective substance, rather than just an intuitive leap.

By my reading of that archive, discussion was quite limited, participation in 
the discussion was quite limited, and, at best, there was no strongly 
dominant(*) view.  Given that my assessment differs from yours, the question 
is what details and patterns that you saw, that justified declaring the matter 
resolved.

d/

(*) The WG Guidelines document defines rough consensus in terms of "the 
dominant view of the working group" and notes that 51% is not enough. Over the 
years, something like 2/3 is more in the ball-park of what is expected, with 
the absence of a vigorous constituency against the view.  The premise behind 
this latter barrier is that strong resistance in the working group implies 
strong resistance to adoption, later.  I realize that such pragmatics are not 
all that in vogue right now, but that's the nature of the history. I'm 
pointing it out because, indeed, my reading of real-world assessments of the 
current SSP is that there is quite strong resistance among receive-side 
participants.
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Thu, 24 Jan 2008 08:18:32 -0800

Stephen Farrell wrote:
>>> 1521    Limit the application of SSP to unsigned messages    new dkim
>>> Nobody    0 [email-masked]    9 days ago        9 days ago    0
>> 
>>> Proposal: REJECT, but some wording changes may be needed for the next 
>>> rev, thread is [4] I mainly saw opposition to the change suggested in
>>> the issue, and little support, but some text clarifying changes were
>>> suggested (e.g. [5]). [4]
>>> http://mipassoc.org/pipermail/ietf-dkim/2007q4/008424.html [5]
>>> http://mipassoc.org/pipermail/ietf-dkim/2007q4/008467.html
> 

Summary of proposal:

> All text that causes SSP to be applied to an already-signed message 
> needs to be removed.

Folks,

I've reviewed the thread that took place on this topic.  Here are summary 
statistics:

    Total postings in thread:  46

    Number of different people posting:  14

    Apparent REJECT of proposal: 4

    Apparent ACCEPT of proposal: 5

I would like to ask folks with an opinion about this proposal to post an 
explicit note stating support or opposition.  Some of the existing posts were 
about substantive issues in the proposal, but did not clearly indicate support 
or opposition.

Given that this issue goes to the core of a significant fraction of the 
current specification's functionality and given that there is at least an 
implied requirement for the functionality in the SSP requirements RFC, I'll 
ask folks to do both a +1/-1 *and* to explain their reasons.

I also do not find a record in the archive of working group agreement to add 
the features in question.  So an assumption that the features should be 
retained unless there is a rough consensus *against* is problematic.  Citing 
the SSP requirements RFC is comforting, but questionable, absent any history 
of group discussion and clear rough consensus about the matter.

d/

-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 24 Jan 2008 16:33:05 -0000

>> All text that causes SSP to be applied to an already-signed message

Yeah.

There's certainly no consensus on what receivers should do in that case.

R's,
John

---

From: [email-masked] (Wietse Venema)
Date: Thu, 24 Jan 2008 11:37:12 -0500 (EST)

> > All text that causes SSP to be applied to an already-signed message 

I would take this further: remove all text that says when to apply
SSP.  Instead, provide text that states the contribution that SSP
can make under different conditions:  mail with valid first-party
signature, mail with valid third-party signature, and mail without
valid signature.

	Wietse

---

From: Steve Atkins <[email-masked]>
Date: Thu, 24 Jan 2008 08:49:36 -0800

On Jan 24, 2008, at 8:18 AM, Dave Crocker wrote:

>>>> dkim
>>>> Proposal: REJECT, but some wording changes may be needed for the  
>>>> next rev, thread is [4] I mainly saw opposition to the change  
>>>> suggested in
>>> Would you please explain the basis for assessing that this topic  
>>> got sufficient discussion and that there was rough consensus on it?

+1

It's not clear what a reasonable sender should expect a reasonable  
receiver to do there, which adds to the uncertainty about the whole  
process.

Long, complex multi-step resolution algorithms do not make for  
reliable interoperability nor wide deployment. Without a very  
compelling operational benefit, that complexity should go.

(And there's nothing that says SSP couldn't be extended to signed  
messages in version 2, once a simple, base protocol is deployed and  
well understood, should there be a clear operational goal that could  
be reached by doing so).

Cheers,
   Steve

---

From: Damon <[email-masked]>
Date: Thu, 24 Jan 2008 11:52:39 -0500

> of group discussion and clear rough consensus about the matter.
-1

Creating the ability for any bad domain to bypass policy of other
domains or worse, non-participating domains, IMO pokes a hole big
enough to drive a truck through.
 I have always frowned upon senders using MY email address as a From:
when the content was generated and delivered by THEM. Use my address
as a nice name or Sender: but not as the From:. I have worked hard to
remove this practice from the applications within the companies I have
worked for.

Regards,
Damon Sauer

---

From: <[email-masked]>
Date: Thu, 24 Jan 2008 11:56:36 -0500

+1 

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Wietse Venema
Sent: Thursday, January 24, 2008 11:37 AM
To: [email-masked]
Cc: ietf-dkim
Subject: Re: [ietf-dkim] Re: ISSUE 1521 -- Limit the application of SSP
tounsigned messages

dkim
> >>> Proposal: REJECT, but some wording changes may be needed for the
next 
> >> Would you please explain the basis for assessing that this topic
got 

	Wietse

---

From: Michael Thomas <[email-masked]>
Date: Thu, 24 Jan 2008 09:12:04 -0800

> enough to drive a truck through.

-1 also. I'd go farther and say that it would make the entire protocol
completely useless.

		Mike

---

From: Steve Atkins <[email-masked]>
Date: Thu, 24 Jan 2008 09:18:12 -0800

> signature, mail with valid third-party signature, and mail without

+1. Seems a reasonable compromise.

Cheers,
   Steve

---

From: Dave Crocker <[email-masked]>
Date: Thu, 24 Jan 2008 09:23:55 -0800

+1

d/

-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Thu, 24 Jan 2008 09:21:57 -0800

> I would like to ask folks with an opinion about this proposal to post 
> an explicit note stating support or opposition.  Some of the existing 
> posts were about substantive issues in the proposal, but did not 
> clearly indicate support or opposition.
>
> Given that this issue goes to the core of a significant fraction of 
> the current specification's functionality and given that there is at 
> least an implied requirement for the functionality in the SSP 
> requirements RFC, I'll ask folks to do both a +1/-1 *and* to explain 
> their reasons.
>

Before I answer this, I want to make sure that I'm clear on what the 
proposal is.

Please confirm that "already-signed message" means "message having a 
valid signature at the verifier".  In other words, please confirm that 
invalid signatures are not being considered here.

-Jim

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 24 Jan 2008 18:28:57 +0100

Dave Crocker wrote:

> I'll ask folks to do both a +1/-1 *and* to explain their reasons.

-1

John's scenario "after a good NY times signature I don't care about
any SSP from the author(s)" makes sense, but the opposite scenario
"I don't care about 3rd party signatures from unknown strangers" is
also okay.  Ditto a receiver policy "I don't bother to check DKIM
at all if there is no chance to reject the mail based on SSP".

 Frank

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 24 Jan 2008 12:24:58 -0500

On Thursday 24 January 2008 12:12, Michael Thomas wrote:
> >> I've reviewed the thread that took place on this topic.  Here are
> >> summary statistics:
> >>
> >> explicit note stating support or opposition.  Some of the existing posts
> >> were about substantive issues in the proposal, but did not clearly
> >> indicate support or opposition.
> >>
> >> current specification's functionality and given that there is at least
> >> an implied requirement for the functionality in the SSP requirements
> >> RFC, I'll ask folks to do both a +1/-1 *and* to explain their reasons.
> >>
> >> I also do not find a record in the archive of working group agreement to
> >> add the features in question.  So an assumption that the features should
> >> be retained unless there is a rough consensus *against* is problematic. 
> >> Citing the SSP requirements RFC is comforting, but questionable, absent
> >> any history of group discussion and clear rough consensus about the
> >> matter.
> >>
> >> d/
> >>
> >> --
> >
> > -1
> >

Isn't that what we are doing?

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Thu, 24 Jan 2008 09:29:59 -0800

> invalid signatures are not being considered here.

Your interpretation of my query is correct.

Since "invalid signature" is defined by DKIM to be equivalent to "unsigned" it 
didn't even occur to me to make the distinction.

d/
-- 

   Dave Crocker

---

From: "J D Falk" <[email-masked]>
Date: Thu, 24 Jan 2008 12:54:14 -0500

Wietse suggested:

> SSP.  Instead, provide text that states the contribution that SSP can
> make under different conditions:
> mail with valid first-party signature, mail with valid third-party
> signature, and mail without valid signature.

+1

---

From: <[email-masked]>
Date: Thu, 24 Jan 2008 17:57:19 +0000

> Date: Thu, 24 Jan 2008 08:18:32 -0800
> From: [email-masked]
> Subject: Re: [ietf-dkim] Re: ISSUE 1521 -- Limit the application of SSP to	unsigned messages
> 
> 
> 
> Stephen Farrell wrote:

-1 . I would like to see us remove any text that implies a decision about what a receiver should do with that information, and maybe some text making it clear that a receiver may decide on a message by message basis to completely skip SSP processing for  for reasons of local policy or because they have sufficient information to make a decision without checking SSP (though it seems a little odd for an RFC to say that when you are not doing X you don't need to worry about how to properly do X). But I think there are a sufficient number of cases where domain owners may want to make statements not just about mail that is not signed, but about mail that is not signed by them.

_________________________________________________________________
Shed those extra pounds with MSN and The Biggest Loser!
http://biggestloser.msn.com/

---

From: "Siegel, Ellen" <[email-masked]>
Date: Thu, 24 Jan 2008 13:24:50 -0500

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Dave Crocker
> Sent: Thursday, January 24, 2008 11:19 AM
> To: ietf-dkim
> Importance: High

+1 

-Ellen

> I've reviewed the thread that took place on this topic.  Here are
summary
> I would like to ask folks with an opinion about this proposal to post
an
> were
the
> current specification's functionality and given that there is at least
an
> add

---

From: "Siegel, Ellen" <[email-masked]>
Date: Thu, 24 Jan 2008 13:26:11 -0500

> [email-masked]] On Behalf Of Wietse Venema

+1 

-Ellen

---

From: Hector Santos <[email-masked]>
Date: Thu, 24 Jan 2008 13:31:48 -0500

[email-masked] wrote:

> But I think there are a sufficient number of cases where domain owners 
> may want to make statements not just about mail that is not signed, but 
> about mail that is not signed by them.

Are you kidding me?  I am willing to bet that given the opportunity to 
do so, they will immediately apply strong SIGNING requirements to their 
mail, IFF the receivers are going to HONOR the policies.

If we have such a relaxed mode of operation, bad guys just have to run 
in legacy mode.  No adaption required.

We are erroneously presuming everyone are going to depend on DKIM being 
tied to reputation services and my view, this is going to be the biggest 
mistake we make here.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 24 Jan 2008 13:55:35 -0500

Apologies for top posting if it offends anyone. 

-1  I OPPOSE this proposal for the following reasons. 

The D in DKIM refers to Domain, not user. If it cannot be used to
strongly protect the purported originating domain based on that domains
stated assertions and policy, then DKIM-SSP is of limited value. 

Without requiring a check (not saying what action the receiver must
take) of the From address, what we are saying is that bad guy signature
on evil nasty email is just as worthwhile of a signature as that of the
owner of the domain in the From address. 

Anyone care to argue that a signature from
randomrotating.randomrotating_evil.ru is a sufficient and trustworthy
signature for an email purporting to be from this list even though
mipassic.org isn't DKIM signing? BTW, isn't ironic that an organization
that is pushing DKIM isn't signing even with t=y?

Requiring a check of From does not dictate the decision the receiver
(MTA,MUA, person at keyboard, whatever) chooses to do with the results.
The folks in favor of removing the text are concerned about what
receivers will do based on such a check. Shouldn't that choice be left
to the individual? 

This is almost like arguing that a sign saying "DANGER, Shallow Water -
Do not Dive" should be removed because some people might want to ignore
the sign and dive in headfirst anyways. 

Feel free to ignore the from DKIM signature in your personal
implementation but please don't weaken the opportunity for the owner of
a domain to make an assertion through DKIM-SSP and expect that people
following the standard have at least checked their disclaimer. If a
domain owner chooses not to make an assertion or chooses to make a
weaker assertion, that is their perogative. 

Mike

>I would like to ask folks with an opinion about this proposal 
>to post an explicit note stating support or opposition.  Some 
>of the existing posts were about substantive issues in the 
>proposal, but did not clearly indicate support or opposition.
>
>Given that this issue goes to the core of a significant 
>fraction of the current specification's functionality and 
>given that there is at least an implied requirement for the 
>functionality in the SSP requirements RFC, I'll ask folks to 
>do both a +1/-1 *and* to explain their reasons.
>
>I also do not find a record in the archive of working group 
>agreement to add the features in question.  So an assumption 
>that the features should be retained unless there is a rough 
>consensus *against* is problematic.  Citing the SSP 
>requirements RFC is comforting, but questionable, absent any 
>history of group discussion and clear rough consensus about the matter.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 24 Jan 2008 14:05:54 -0500

Ok, now I'm confused......

Does -1 mean remove the text or does -1 mean oppose the proposal. My
intent is to oppose the proposal to remove text.

Mike

>[mailto:[email-masked]] On Behalf Of MH 
>Michael Hammer (5304)
>Sent: Thursday, January 24, 2008 1:56 PM
>To: [email-masked]; ietf-dkim
>Subject: RE: [ietf-dkim] Re: ISSUE 1521 -- Limit the 
>application of SSPtounsigned messages
>
>
>The D in DKIM refers to Domain, not user. If it cannot be used 
>to strongly protect the purported originating domain based on 
>that domains stated assertions and policy, then DKIM-SSP is of 
>limited value. 
>
>take) of the From address, what we are saying is that bad guy 
>signature on evil nasty email is just as worthwhile of a 
>signature as that of the owner of the domain in the From address. 
>
>randomrotating.randomrotating_evil.ru is a sufficient and 
>trustworthy signature for an email purporting to be from this 
>list even though mipassic.org isn't DKIM signing? BTW, isn't 
>ironic that an organization that is pushing DKIM isn't signing 
>even with t=y?
>
>Requiring a check of From does not dictate the decision the 
>receiver (MTA,MUA, person at keyboard, whatever) chooses to do 
>with the results.
>The folks in favor of removing the text are concerned about 
>what receivers will do based on such a check. Shouldn't that 
>choice be left to the individual? 
>
>This is almost like arguing that a sign saying "DANGER, 
>Shallow Water - Do not Dive" should be removed because some 
>people might want to ignore the sign and dive in headfirst anyways. 
>
>implementation but please don't weaken the opportunity for the 
>owner of a domain to make an assertion through DKIM-SSP and 
>expect that people following the standard have at least 
>checked their disclaimer. If a domain owner chooses not to 
>make an assertion or chooses to make a weaker assertion, that 
>is their perogative. 
>
>Mike
>
>
>
>
>
>>
>>
>>Summary of proposal:
>>
>fraction of the 
>>I also do not find a record in the archive of working group agreement 
>>to add the features in question.  So an assumption that the features 
>>should be retained unless there is a rough consensus *against* is 
>>problematic.  Citing the SSP requirements RFC is comforting, but 
>>questionable, absent any history of group discussion and clear rough 
>>consensus about the matter.
>
>

---

From: John Levine <[email-masked]>
Date: 24 Jan 2008 19:14:31 -0000

>owner of the domain in the From address. 

I supose that's often true, given that a signature from a random
unknown sender that matches the From: address is just as worthless as
a signature from a random unknown sender that doesn't match the From:
address.

But please stop misrepresenting other people's arguments.  Nobody has
ever claimed that a random signature gives mail a free pass.

R's,
John

---

From: John Levine <[email-masked]>
Date: 24 Jan 2008 19:15:56 -0000

>> signature, mail with valid third-party signature, and mail without

+1.  That's even better.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Thu, 24 Jan 2008 11:27:42 -0800

> signature, mail with valid third-party signature, and mail without

I mostly agree with Wietse's proposal.  Yes, I'm aware that diverges 
sharply from the current draft.

The original proposal in the issue, "All text that causes SSP to be 
applied to an already-signed message needs to be removed," could be 
interpreted as discouraging the use of SSP anytime there is any valid 
signature on a message.  I certainly read it that way at first, and from 
some of the responses I have seen, others are reading it that way too.

If there's a signature on a message that the verifier trusts 
sufficiently that they're going to treat the message as valid, then 
there isn't a lot of point in retrieving the SSP record.  Note that I 
say "trusts sufficiently" because trust isn't a black-and-white thing; a 
verifier might trust some signatures completely, and accept mail bearing 
those signatures regardless.  Other signatures, (e.g., from a mailing 
list) might be trusted enough to accept mail from some domains, but not 
from a domain that is used exclusively for transactional email.  The 
verifier also might use SSP to determine which domains fall into this 
transactional category.  But it's up to the verifier to decide when SSP 
adds value, and retrieve it then.

The current normative language in SSP was an attempt to:

(1) Define SSP in such a way that SSP, taken alone, produces a 
deterministic result, even though it was recognized that the SSP result 
would be combined with other things in determining the ultimate handling 
of the message

(2) Avoid placing a normative dependence on reputation, accreditation, 
and other things that are out of the scope of the WG.  The widely 
misunderstood term "verifier acceptable third-party signature" was a 
subtle nod to reputation, but it seems it was far too subtle.

-Jim

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 24 Jan 2008 14:38:05 -0500

>From: John Levine [mailto:[email-masked]] 
>Sent: Thursday, January 24, 2008 2:15 PM
>Cc: MH Michael Hammer (5304)
>Subject: Re: [ietf-dkim] Re: ISSUE 1521 -- Limit the 
>application of SSP tounsigned messages
>
>signature 
>I supose that's often true, given that a signature from a 
>random unknown sender that matches the From: address is just 
>as worthless as a signature from a random unknown sender that 
>doesn't match the From:
>address.
>
>But please stop misrepresenting other people's arguments.  
>Nobody has ever claimed that a random signature gives mail a free pass.
>

I'm not misrepresenting other peoples arguments at all. If the only
signature on the message is from a 3rd party and there is an opportunity
to check for the assertion of the purported From domain that is not
taken, that in fact is giving more weight (not even equal weight) to the
signature of the thrid party with respect to any potential assertions by
the owner of the purported From domain.

I have not stated nor have I even insinuated that anyone has claimed
"Nobody has ever claimed that a random signature gives mail a free
pass." 

You are arguing the case of "your trusted friend", the mailing list.
There are alternate ways for a mail list to function rather than present
the "from" address header from another domain. In a world where abuse is
rampant, that practice creates substantive problems and opens the door
to abuse. 

I am arguing the case of millions of compromised end-user machines due
to phishing/malware/trojans. If end users were allowed to vote on this
(after having the two positions presented) I think they would pretty
much prefer requiring checks of assertions (as part of the SSP standard)
and then having the right to choose (through their software or their
choice of service providers) whether to use systems that check DKIM or
what decision to make based on that required check if SSP is used in
their environment.

If, as a receiver you don't want to use SSP that is your perogative. If
you choose to trust the list (or any other signature) rather than (or
over) the SSP of the purported From domain, that is again your
perogative. If you make that choice and get phished/trojaned, whatever
and contact me as the operator of the purported from domain, I'm not
going to be particularly sympathetic when you tell me you trusted the
list (or over some random signature) over my SSP (that wasn't even
looked at) that gave fair warning.

Consider including the mandatory check in SSP as the opportunity to
evaluate something that might prevent pretty significant bad outcomes in
a significant amount of cases. You may choose to ignore the warning but
you can't claim that you were ignorant that the warning exists. As
others have pointed out, DKIM can be useful by itself without reputation
systems if given the chance.

Mike

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 24 Jan 2008 13:31:04 -0600

-1

Mike is entirely right.  SSP is dead-on-arrival and we've all completely 
wasted our time if this proposal is allowed to stand and here's why:

SSP is about providing the receiver with a means to check whether a 
required message characteristic is missing.  SSP settles on 4871 for the 
"characteristic" and a From: header domain check for the "required".  If 
we remove the "required" we're left only with the bare "characteristic" 
which tells us nothing useful except in cases where there's a 
preexisting trust.

Arvel

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 24 Jan 2008 13:50:44 -0600

> sharply from the current draft.

I could get behind Wietse's proposal also if it hadn't started with "I 
would take this further."  I'm concerned with the "this" he refers to 
which encourages avoiding SSP completely in the presence of a verifiable 
signature from just anybody whom-so-ever.  I view that notion as 
completely defeating SSP.

Arvel

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 24 Jan 2008 13:40:00 -0600

> signature on a message.

That is precisely what I understand this proposal to be advocating.  If 
I'm wrong I would love some clarification.

Arvel

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 24 Jan 2008 13:52:53 -0600

> If we remove the "required" we're left only with the bare
 > "characteristic" which tells us nothing useful except in cases where
 > there's a preexisting trust.

Well, "nothing useful" is not entirely true.  It's still better to know 
what a signature alone can tell you than to not have any information at 
all however in the context of SSP just any old signature doesn't say enough.

Arvel

---

From: Jim Fenton <[email-masked]>
Date: Thu, 24 Jan 2008 11:55:43 -0800

Arvel Hathcock wrote:
> which encourages avoiding SSP completely in the presence of a 
> verifiable signature from just anybody whom-so-ever.  I view that 
> notion as completely defeating SSP.

That's exactly what I was hoping wasn't being proposed.

-Jim

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 24 Jan 2008 15:00:46 -0500

>[mailto:[email-masked]] On Behalf Of Hector Santos
>Sent: Thursday, January 24, 2008 1:32 PM
>To: [email-masked]
>Cc: [email-masked]; ietf-dkim
>> may want to make statements not just about mail that is not signed, 
>> but about mail that is not signed by them.
>
>Are you kidding me?  I am willing to bet that given the 
>opportunity to do so, they will immediately apply strong 
>SIGNING requirements to their mail, IFF the receivers are 
>going to HONOR the policies.
>

+1 

My organization has recently started DKIM signing (millions and millions
of emails signed in the last 10 days) for 5 large scale mailing domains
plus making strong SPF assertions for those domains. The end game I want
to see for DKIM-SSP (Can't we make SSP broader? Please?) would be for me
to be able to make the assertion that ALL mail from these domains is
signed and ONLY comes from the IP addresses indicated in our SPF
records. 

Initial results working with receivers that are checking have been
excellent. This assertion, if honored by receiving domains, will provide
significant additional protection from phishing/trojan emails for huge
numbers of inboxes. There is a small volume of email that appears to
have broken signatures (a very few cases involving forwarding but it may
be related to specific edge cases with regard to the choice of signed
headers).  Then there are the unsigned emails purporting to be us and
not coming from our IP Address space.....phishing emails....trojan
emails...... 

I think receivers are going to implement DKIM checking so fast your head
will spin. I have a feeling that the default implementation - whether in
the standard or not - is going to be to automatically check the SSP of
the From anyways because there is real value in such a check. I think
you are going to find receivers placing significant weight on strong
assertions by domains. 

Why not codify something that has value and does not prevent someone
deciding what to do with that check? The MAAWG website indicates (2nd
Qtr 2007) that 86.7% of email is abusive email. Others report a higher
percentage. Don't think for a minute that the bad folks aren't going to
try to find ways to subvert DKIM in practice. Why make it weaker and
more subject to gaming when we can make it stronger and more resistant
to gaming?

The dkim.org website contains this statement in the first paragraph:
"Technically DKIM provides a method for validating a domain name
identity that is associated with a message through cryptographic
authentication." Which has the stronger association with a particular
message? A third party or the domain that is the purported originator of
the message?

>If we have such a relaxed mode of operation, bad guys just 
>have to run in legacy mode.  No adaption required.
>

+1

>We are erroneously presuming everyone are going to depend on 
>DKIM being tied to reputation services and my view, this is 
>going to be the biggest mistake we make here.
>

+1

Mike

---

From: Damon <[email-masked]>
Date: Thu, 24 Jan 2008 15:08:28 -0500

> completely defeating SSP.

A number of years ago a friend confided in me that a company he worked
for, whom have always been considered to be good SMTP citizens,
inadvertently popped a hole in their firewall that allowed some SMTP
traffic to leak unfettered to the internet. One of the desktops had a
bot that sent the worst type of spam. The globally wholesome image of
the company, had it gone too long without being discovered, would have
been tarnished as the incident would have certainly found its way to
the media. This company certainly could have and would have taken
advantage of STRICT or ALL if DKIM/SSP were available at the time. If
this was to happen to this company again, with the proposed language
removed, all the bot would have had to do is sign the message and
those that trusted the company for so long would be in for a nasty
little suprise.

Regards,
Damon

---

From: Steve Atkins <[email-masked]>
Date: Thu, 24 Jan 2008 12:21:57 -0800

> signed and ONLY comes from the IP addresses indicated in our SPF

Sounds like interesting operational data.

Could you expand on your choice to use ~all for ag.com - presumably
important corporate mail - while using -all for americangreetings.com -
presumably bulk/junk/e-card mail?

Also, were there any interesting delivery rate changes when you  
changed your
SPF practices?

Cheers,
   Steve

---

From: [email-masked] (Wietse Venema)
Date: Thu, 24 Jan 2008 15:25:31 -0500 (EST)

> completely defeating SSP.

I am not discouraging SSP.

> > All text that causes SSP to be applied to an already-signed message 

I propose that we remove not only this text but also other text
that says when to apply SSP.

	Wietse

---

From: Michael Thomas <[email-masked]>
Date: Thu, 24 Jan 2008 12:40:39 -0800

> completely defeating SSP.

I'm rather uncomfortable with this as the "contribution" is likely to
be rather subjective, and I've been burned before with the IESG thinking
that that kind of text amounted to so much salesmanship, and puked on
it.

		Mike

---

From: [email-masked] (Wietse Venema)
Date: Thu, 24 Jan 2008 15:44:47 -0500 (EST)

> That's exactly what I was hoping wasn't being proposed.

No worries. The proposed change is to focus the benefits that SSP
can provide in scenarios as outlined above, not to discourage the
deployment of SSP.

One can do SSP lookup in all three scenarios, but the benefits will
differ.

If mail has only a valid third-party signature, then the receiver
can use both the signer's reputation AND the statement in SSP (AND
any number of other data points) to arrive at a conclusion on how
to dispose of/label/whatever the message.

If mail has no valid signature, then obviously the originator SSP
is directly relevant (together with any number of other data points).
And if mail has a valid first-party signature, SSP is pretty much
redundant.

I hope this clarifies things a little better than my previous terse
statement.

	Wietse

---

From: John Levine <[email-masked]>
Date: 24 Jan 2008 20:51:59 -0000

>signature on the message is from a 3rd party and there is an
>opportunity to check for the assertion of the purported From domain
>that is not taken, that in fact is giving more weight ... to the
>signature of the third party ...

Right.  Let's look at the message you just sent, and imagine that the
list signed it with a mipassoc.org signature.  Since I know that Dave
runs his lists well, I'm done.  The "opportunity" to check something
else is irrelevant, as is the fact that the list would have broken
your signature.

> There are alternate ways for a mail list to function rather than
> present the "from" address header from another domain.

Now we get to the nub of the fallacy.

Mailing lists like this one have been around for a rather long time,
quite possibly since before you were born, and they're not going to go
away.  Lists are not and never have been a significant phishing
vector, but even if they were, there are plenty of ways to address
that without demanding that everyone in the world change their
software.  If that's what you expect, you're wasting your time.

R's,
John

---

From: John Levine <[email-masked]>
Date: 24 Jan 2008 20:53:44 -0000

>required message characteristic is missing.

Um, required by whom or what?  I require that my inbound mail not be
spam, but I don't require that the senders of non-spam follow some
third party's internal mail policy.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Thu, 24 Jan 2008 16:50:09 -0500

John Levine wrote:
> runs his lists well, I'm done.  

Patent it!!  All the world needs to do ASKJOHN.COM if Dave's Mailing
list runs well. JQ Public will be privy to John's advice.

Wonderful! It is surreal to believe that anyone would take this serious.

The fallacy is to believe reputation is standardize and provides an free 
pass regardless of the faults in a transaction. Never mind it smells, 
walks, talks like a duck (spam) - ASKJOHN.COM!!!  Its ok!

The truth is, you don't believe that at all.  In fact, your non-vetted 
VBR system requires a DKIM verified message.

Go figure.

-- 
Sincerely

Hector Santos, CTO

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 24 Jan 2008 16:59:55 -0500

I don't want to get too far afield with respect to SPF. This is after
all the DKIM list. I will submit a single post on this topic because I
believe it bears on the discussion at hand. Why a MUST check for From is
needed for the case of signed by 3rd party but not signed by From domain
- without requiring any particular action based on that check.

At some future point I'll provide SPF related information from our
implementation experience on the SPF-discuss list

>[mailto:[email-masked]] On Behalf Of Steve Atkins
>Sent: Thursday, January 24, 2008 3:22 PM
>To: ietf-dkim WG

Absolutely and at some future point I want to share what we are seeing
with a wider audience. It's still too early to get too detailed as we
are still looking at and working through the data.
>
>Could you expand on your choice to use ~all for ag.com - 
>presumably important corporate mail - while using -all for 
>americangreetings.com - presumably bulk/junk/e-card mail?
>

Absolutely. 

People primarily receive greeting card notification and confirmation
email from americangreetings.com (and other brand domains of ours).
While some people may have an axe to grind about online greetings, a lot
of senders and recipients consider them inportant. People use them for
birthdays, anniveraries, births, deaths and all sorts of other events.
This is why the bad folks abuse greetings for phishing/malware. People
want to be loved. It's pretty much hard wired. In that respect
protecting americangreetings.com and the people who receive email from
that domain is much more important than ag.com - the effort directly
impacts millions of people. 

In the past, like other social expressions sites, these domains have
been subject to heavy abuse through fraudulent emails. The general
solutions were reactive. Using -all provides an opportunity for
receivers to protect their users from fraudulent emails by checking the
Mail From against our SPF records. For those domains we know that emails
should be originating from somewhere else. We had weaker assertions for
quite some time. We were changing our internal processes to take
advantage of -all. We are now in a position to do so with some level of
confidence. I hope that as we are able to share our experience it will
build confidence in others that the rewards far outweigh the risks and
justify the effort to architect or re-architect implementations that
support strong assertions for both path based and message based
authentication.

Similar issue for DKIM signing. We don't consider it a strong enough
practice to sign just some of the email from the website domains. It is
important to provide a clear statement to both receivers and end users.
We want to be able to tell people that all email for
americangreetings.com is signed. No waffling, no I'm not sure or maybe.
By indicating uncertainty one invites abuse. This is why I'm passionate
about requiring checks for the From field. It protects people in
significant use cases.

The reason that ag.com uses ~all is simply that it involves a more
complex use case. There are actual real users and user accounts instead
of role accounts. People travel. We have acquisitions. I have a high
confidence that we could move to strong assertions with few problems. I
just have to find the cycles to prepare for and deal with those few
problems (that may take a lot of time to address for non-technical
reasons) once we throw the switch. 

It's not as easy for me to work with receivers on mail from ag.com
because it isn't high volume and it is not a general abuse situation for
their constituencies. Feedback is mighty useful in moving forward on
this stuff. This isn't a complaint, simply a recognition of reality.

It simply isn't as easy to take the stronger stance for the corporate
domain and be comfortable that there aren't negative impacts. There are
more factors for the corporate domain that I need to build consensus and
buy in for. 

It took a lot of work for us to reach the point of strong assertions for
the website domains without these sorts of issues. I do want to point
out that the steps that PayPal took with Yahoo! and the information they
presented on the low rate of false positives built a lot of confidence
on our part. Our experience with implementing strong assertions for the
website domains should build confidence for implementation for ag.com.

I'm looking forward to the day we can assert -all for ag.com and every
single domain that we control. 

With respect to DKIM, there is one use case where use of strong SPF
appears to be very advantageous. If you wish to determine that all your
outbound email for a domain is truly signed with DKIM, having a strong
SPF assertion and receivers that can give you feedback will allow you to
identify if you have any "leaking" email that is not signed. We know
where we are signing. We had one small case of leakage that was quickly
identified and resolved. This gave us a very simple equation. 

known signing points within our IP Address range VS other IP addresses
in our IP Address range VS hosts not within out IP address range.

I would recommend using t=y for your signing as you try to get to the
point that you are sure that you are signing everything. 

>Also, were there any interesting delivery rate changes when 
>you changed your SPF practices?
>

We generally have always had good delivery. That isn't why we are taking
the steps we are taking. The general answer to your question is that we
have not seen negative impacts on delivery rates from making a strong
assertion. More detailed than that I'm going to have to hold off until a
later point. I think this outcome is specific to our case and may not
predict outcomes for other implementations. If a sender is perceived by
receivers as a problem, strong authentication makes it easier for the
receiver to block or drop their messaging. And that is as it should be.

Mike

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 24 Jan 2008 16:00:15 -0600

> Um, required by whom or what?  

In the case of SSP as currently written the answer is: the domain from 
whom the message itself claims to originate.

Note though that the question of "required by whom or what" is separate 
from the assertion that SSP needn't check anywhere for any requirement 
whatsoever.  In fact, we must first agree that SSP is about checking for 
such a requirement before we can discuss from whom or what.  It is this 
fundamental characteristic of SSP that issue 1521 calls into question.

Arvel

---

From: <[email-masked]>
Date: Thu, 24 Jan 2008 22:03:13 +0000

> Date: Thu, 24 Jan 2008 13:31:48 -0500
> From: [email-masked]
> CC: [email-masked]; [email-masked]

I could be wrong, but I think we agree here. What I meant was, many domain owners will want their policies to apply to all mail not signed by them (which includes both unsigned mail and mail signed by third parties).

Where we may disagree is in the other part of my stgatement, which isn't quoted here. I think limiting the SSP spec to a description of how to retrieve the data, and under what situations it is applicable is sufficient. I don't think we need to say explicitly what to do when you encounter a specific policy. I think most domain owners who want a strict policy will create one if they think it will help prevent problems with ANY receiver who is significant to them.

_________________________________________________________________
Need to know the score, the latest news, or you need your Hotmail®-get your "fix".
http://www.msnmobilefix.com/Default.aspx

---

From: Dave Crocker <[email-masked]>
Date: Thu, 24 Jan 2008 14:20:49 -0800

> intent is to oppose the proposal to remove text.

The proposal is to remove a portion of the existing draft.

So,

    +1 is in favor of removal and

    -1 is against removal.

d/
-- 

   Dave Crocker

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 24 Jan 2008 16:27:16 -0600

> can provide in scenarios as outlined above, not to discourage the

Could there be broader agreement on an SSP specification that lays out
how to do an SSP lookup but doesn't rigidly mandate where to look or
when to look?  Instead, the spec would lay out several scenarios as
examples; chief amongst those being when signatures do not match the
From: domain?

Arvel

---

From: Dave Crocker <[email-masked]>
Date: Thu, 24 Jan 2008 14:32:58 -0800

John Levine wrote:
> away.  

I don't remember the precise details, but thought it worth using the above as 
an excuse to review that ancient history:

The earliest Arpanet mailing lists were hand-managed.  The DEC PDP-10 Tenex 
SNDMSG program could take a list of addressees, but there was no queuing, so 
the sender had to sit and watch for issues with the remote FTP/mail server in 
real time.

I think that the first mailing list was either MsgGroup or Header-People. 
Circa 1973.  Might have been 74. Don't believe it was as late as 75.

Yes, both were about email, with the former being concepts, usage, and the 
like, while the latter was techncal.  I think MsgGroup was the first.  It is 
discussed in Katie Hafner's "Where Wizards Stay Up Late".  Anyone seriously 
interested in email and online group collaboration issues would benefit from 
seeing what sorts of things were raised back then.

RFC availability announcements were the other mailing list that I recall from 
the very early days.  I think Postel said it took the better part of a day to 
ship an announcement to an entire list of 100, or so, recipients.

(For reference, the 1972 gasoline crisis prompted creation of the first online 
group "teleconferencing" system, which ran as a centralized, dial-in facility. 
It was deemed a huge success, and essential to the proper management of the 
crisis process.)

d/
-- 

   Dave Crocker

---

From: [email-masked] (Wietse Venema)
Date: Thu, 24 Jan 2008 18:04:24 -0500 (EST)

> examples; chief amongst those being when signatures do not match the

I have been thinking along those lines for the past week or so,
recognizing that DKIM and SSP results will likely be used together
with other data points that may get a higher or lower weight
depending on receiver preferences.

As you recognize, the easiest scenarios are the ones with "valid
first-hand signature" and "no valid signature". In the former case,
the DKIM signature provides a data point, in the latter the case, SSP.

The scenario with "valid third-party signature" provides two data
points, one from the DKIM signature and one from SSP. Which of the
two gets more authority is something that IMHO only the receiver
can decide; just like the receiver decides on their weight relative
to any other data points.

This does not change fundamentally when there are more than one
author. One reasonable approach seems to iterate over the list, up
to some sane upper bound.

	Wietse

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 24 Jan 2008 18:25:09 -0500

>Sent: Thursday, January 24, 2008 3:52 PM
>Subject: Re: [ietf-dkim] Re: the entire world will change 
>their mail systems so that SSP sort of works
>
>Right.  Let's look at the message you just sent, and imagine 
>that the list signed it with a mipassoc.org signature.  Since 
>I know that Dave runs his lists well, I'm done.  The 
>"opportunity" to check something else is irrelevant, as is the 
>fact that the list would have broken your signature.
>

You are picking a particular case structured by yourself to say "See,
this check is irrelevent". You ignore any other use cases regardless of
outcome. To construct a standard on a single constructed case (I trust
Dave!) is a mighty interesting approach. DKIM provides a standard
approach to signing. It allows anyone that handles a message to sign it.
But what to check? What if you have 10 signatures? What if the email
isn't from a list run by Dave? I haven't heard anyone suggest that you
MUST send the message under consideration to /dev/null if not signed by
>From and SSP is checked. Do what you want. Why does doing the check feel
so onerous from your perspective? It helps in a number of cases and
doesn't require you as a receiver to do anything based on the check if
you choose not to. When Doug goes after SPF because of his perception
that checks may impose significant resource overhead I can understand
his concerns even if I don't agree with him about the risks. Where is
the problem with requiring the check in specific circumstances?

The fact that the list (may have) broke my signature exists whether I
publish SSP or not. Receivers will start to make decisions about broken
signatures as they gain more experience. Perhaps broken signatures will
make signers more cautious about what they put in SSP. Perhaps not. The
potential for a broken signature exists regardless. Are you concerned
about my broken signature because you fear you will miss my wit and
insight because your sofware will reject my message? Then have your
software send my messages to a special place and check for it. Tell your
software to ignore my broken signature. Requiring a check as part of the
standard simply ensures a standard hook for whatever the receiver
chooses to do. One is not forced to implement SSP.

>Mailing lists like this one have been around for a rather long 
>time, quite possibly since before you were born, and they're 
>not going to go away.  Lists are not and never have been a 
>significant phishing vector, but even if they were, there are 
>plenty of ways to address that without demanding that everyone 
>in the world change their software.  If that's what you 
>expect, you're wasting your time.
>

No fallacy. Change or don't change. Accept or don't accept. Use or don't
use SSP. Lists may not be and may not have been a significant phishing
vector. And my question would be, what is your point? Lists have been
subject to other types of abuse. DKIM and SSP may or not be pertinent.
Don't think of it as domains wishing to make strong assertions breaking
mailing lists. Think of it as domains making strong assertions
voluntarily excluding themselves. They value security more than the
pleasure of your company on a list that does not respect their assertion
with regard to their domain. They wish to be master of their domain. If
they wish to have the pleasure of your company they will either have to
change their assertion/practice or participate using another account at
a more flexible domain.

You mean you didn't notice my grey beard when you were speaking with me
in person (DC MAAWG)? During the timeframe (first mail lists) you refer
to I was playing with S-100 buss stuff (altair) and IMSAIs on a personal
level. At school I was using card decks on an IBM mainframe running
HASP. You are right. Change is bad and we should go back to the day
where if you wanted a keyboard on a "personal" computer you could rewire
a teletype terminal if you so desired. Roll back 2821 and 2822. 821 and
822 are all we need. We don't need no stinking ESMTP! Let's all go back
to CP/M for an OS. I used to help run a BBS. We had forums where people
had communities. Along came the intartubes and BBS left the mainstream.
Now we have forums and blogging. 

I'm not demanding that everyone in the world change their software, far
from it. 

People sometimes do change the way they do things. Sometimes fast and
sometimes slow. Sometimes one subset chooses to change and another
subset chooses not to change. In most cases I believe in people making
choices. The right to make choices (which I consider fundamental)
includes the right to make poor choices. Given the importance of this
issue I hope that more than 10 people step up to the plate and chime
in....regardless of which way the decision goes. 

Mike

---

From: Dave Crocker <[email-masked]>
Date: Thu, 24 Jan 2008 15:33:37 -0800

MH Michael Hammer (5304) wrote:
> outcome. 

Mike,

I think the biggest challenge in discusses this area of standards is to deal 
with just this: particular cases. Email is used is so many different ways, 
what works for one scenario well might not work for another.

The issue is not that one is right and another wrong, but that doing something 
to affect one needs to worry quite a bit about how it affects another.

At a minimum, this is why I've become fond of emphasizing the need to make 
explicit statements about the scenarios for which something is applicable.

If the final version of SSP is useful for only a limited set of scenarios -- 
and I believe most of us expect that -- that's fine, as long as this is clear.

So far, scenarios to which SSP will not work seem to be what has been ignored, 
IMO.

d/
-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Thu, 24 Jan 2008 16:00:12 -0800

On Jan 24, 2008, at 3:33 PM, Dave Crocker wrote:

>> You are picking a particular case structured by yourself to say  
>> "See, this check is irrelevent". You ignore any other use cases  
>> regardless of outcome.
>
> Mike,
>
> I think the biggest challenge in discusses this area of standards is  
> to deal with just this: particular cases. Email is used is so many  
> different ways, what works for one scenario well might not work for  
> another.
>
> The issue is not that one is right and another wrong, but that doing  
> something to affect one needs to worry quite a bit about how it  
> affects another.
>
> At a minimum, this is why I've become fond of emphasizing the need  
> to make explicit statements about the scenarios for which something  
> is applicable.
>
> If the final version of SSP is useful for only a limited set of  
> scenarios -- and I believe most of us expect that -- that's fine, as  
> long as this is clear.
>
> So far, scenarios to which SSP will not work seem to be what has  
> been ignored, IMO.

Well said.

-Doug

---

From: [email-masked] (Wietse Venema)
Date: Thu, 24 Jan 2008 19:20:11 -0500 (EST)

For the record, one minor correction for sloppy language.

	Wietse

> The scenario with "valid third-party signature" provides two data

This should be: "valid third-party signature only"

---

From: Mark Delany <[email-masked]>
Date: Thu, 24 Jan 2008 17:12:08 -0800

+1

If for no other reason than the obvious fact that SSP is not making  
progress as it stands. We need some sort of reset if we hope to proceed.

Mark.

---

From: Hector Santos <[email-masked]>
Date: Thu, 24 Jan 2008 21:14:26 -0500

> progress as it stands. We need some sort of reset if we hope to proceed.

Its unfortunate that it has nothing to do with technical reasons but the 
  powers that are pushing reputations instead. The fact is, Dave's never 
cared for SSP and its spelled out in his deployment guide, and the other 
guy pushing his reputation service has no room for SSP because SSP 
threatens that service business.

It is would be one thing to kill SSP for its technical merits, but no 
one has SHOWN it is flawed system. NO one.

Purely based on self interest, and unfortunately we have a few cogs who 
are masters of getting things KILLED if they want it to DIE.

It is a very SAD that not enough the technical developers are here to 
mandate the direction.

It is really a sad. Too bad.  Such a GOOD system is going thrown away 
because of the self-interest reputations pushers.

-- 
Sincerely

Hector Santos, CTO

---

From: Steve Atkins <[email-masked]>
Date: Thu, 24 Jan 2008 19:17:21 -0800

On Jan 24, 2008, at 6:14 PM, Hector Santos wrote:

> Its unfortunate that it has nothing to do with technical reasons but  
> the  powers that are pushing reputations instead. The fact is,  
> Dave's never cared for SSP and its spelled out in his deployment  
> guide, and the other guy pushing his reputation service has no room  
> for SSP because SSP threatens that service business.
>
> It is would be one thing to kill SSP for its technical merits, but  
> no one has SHOWN it is flawed system. NO one.

Sure they have. Numerous times. Anyone who doesn't recognize that it
has flaws is, honestly, not technically knowledgeable enough to be able
to offer anything useful to the spec development.

That SSP has some serious flaws isn't, in itself, a reason not to  
develop
it and deploy it. But if the people who are developing the specification
are not capable of recognizing that there are flaws, we have a problem.

>
>
> Purely based on self interest, and unfortunately we have a few cogs  
> who are masters of getting things KILLED if they want it to DIE.
>
> It is a very SAD that not enough the technical developers are here  
> to mandate the direction.

On the contrary. It's those with most technical experience who see the
flaws in it, generally.

Cheers,
   Steve

---

From: <[email-masked]>
Date: Fri, 25 Jan 2008 03:19:21 +0000

> Date: Thu, 24 Jan 2008 20:51:59 +0000> From: [email-masked]> To: [email-masked]> Subject: Re: [ietf-dkim] Re: the entire world will change their mail systems so that SSP sort of works> CC: [email-masked]> > >I'm not misrepresenting other peoples arguments at all. If the only> >signature on the message is from a 3rd party and there is an> >opportunity to check for the assertion of the purported From domain> >that is not taken, that in fact is giving more weight ... to the> >signature of the third party ...> > Right. Let's look at the message you just sent, and imagine that the> list signed it with a mipassoc.org signature. Since I know that Dave> runs his lists well, I'm done. The "opportunity" to check something> else is irrelevant, as is the fact that the list would have broken> your signature.> 
So you've picked an example where you don't need to bother with SSP at all since you already have an existing trust relationship in place, and your existing systems give you what you would consider to be a valid answer given just DKIM and no policy or practices statements whatever.
If your answer is, that given this example you are not going to use SSP (and as an engineer I would probably recommend not mucking with any cases where your systems already do exactly what you want them to) that is fine. But given that, how does this have any bearing on what people should be doing in cases where they decide they do want to use SSP?
 
Let's modify the example a bit. Imagine that the message had been sent to you rather than through the mipassoc.org mailing list, but through some entity you knew nothing about, and that that entity had signed the message. 
 
Does the draft need to explain all the cases or reasons why someone might not bother to look up a policy at all?

 
Robert

---

From: Douglas Otis <[email-masked]>
Date: Thu, 24 Jan 2008 19:34:17 -0800

On Jan 24, 2008, at 6:14 PM, Hector Santos wrote:

> the powers that are pushing reputations instead. The fact is, Dave's  
> never cared for SSP and its spelled out in his deployment guide, and  
> the other guy pushing his reputation service has no room for SSP  
> because SSP threatens that service business.
>
> It is really a sad. Too bad.  Such a GOOD system is going thrown  
> away because of the self-interest reputations pushers.

Hector,

To avoid unwarranted disruption, SSP should be defined in a manner  
that permits RFC 4871 to be used as expected when making SSP  
assertions like "all" or "strict".

SSP will not impact reputation services.  It is hard to imagine how  
your conclusion was reached.  Spammers have proven themselves able to  
adjust to these types of mechanisms.  Nevertheless, DKIM deployment is  
important for many reasons well beyond reputation and self-published  
policy enforcement.

As SSP is currently defined, normal use of RFC 4871 is not possible.   
The self inflicted problems will diminish DKIM's deployment.

You have often described an ability to reject email based upon self  
published policy as a significant benefit that will be provided by  
DKIM.  (The batteries.)  However, the extent of this benefit may be  
less than you have imagined.  In addition, having DKIM deployed  
provides significant benefits you are likely overlooking.

IMHO, the motivations behind the SSP discussion is to ensure this  
policy extension does not become problematic for the more important  
DKIM base deployment.

SSP will happen.  The goal is to have SSP offer more benefits than  
problems.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Thu, 24 Jan 2008 23:06:16 -0500

> to offer anything useful to the spec development.

I disagree.

All the concerns are directly attributed to SSP threatening reputation 
services.  Case in point, Dave's Deployment Drafts has no SSP 
consideration, never had any consideration for it and it is 100% tied to 
reputation. The deployment guide specifically states:

    Unless a scheme can correlate the DKIM signature with
    accreditation or reputation data, the presence of a DKIM
    signature SHOULD be ignored.

And that implies even a VALID signature. So the DEPLOYMENT draft changes 
the semantics of DKIM-BASE itself to one where DKIM-BASE is now deemed 
useless unless a reputation system is in place.  Go figure.

SSP lowers the need to reputation services and everyone with a good 
engineering, product development and marketing sense can see that.

SSP is a 100% perfectly viable and top notch engineers, good people, 
like Eric, Jim, including myself,  Arvel and many others contributed 
greatly to the specs and believe it has value WITH and WITHOUT 
signatures.   To suggest we are all WRONG is offensive.  The fact is, we 
were not wrong.

> That SSP has some serious flaws isn't, in itself, a reason not to develop
> it and deploy it. 

Can you outline the serious TECHNICAL flaws?  I have a feeling you will 
not be able to.

> But if the people who are developing the specification

No, we have a problem with the self-interest promotions of direct 
marketing related people here who want their cake and eat it too, at the 
expense at all others.

The bottom line, truth be told, SSP threatens the adoption rate of any 
reputation service.   It needs to be stated because all this has gotten 
out of hand.   You have to question why Dave had endorsed 5016 only to 
come back later acting like he knew nothing about it.  Wasted everyone's 
time.

> On the contrary. It's those with most technical experience who see the

And generally that is true, but that hasn't happen here, and quite 
frankly, you are in no position to question anyone's technical experience.

Since day one, John and Dave never had any sincere interest in seeing 
SSP get developed or allow for it to get develop by others.  None of 
them have any interest in it - period.  It didn't serve their purpose. 
In fact, it hampered the push for reputation services.

Since day one all these issues were on the table, the multiple 
co-authors and the 3rd party issues, so there is nothing new here.

Now, not even the watered down STRICT/ALL policies are good enough and 
now we have a marketing campaign and Deployment Draft that is 100% 
designed around reputation, NO SSP consideration whatsoever, not even 
for NONE signatures.  In fact, not even a valid signature is good enough 
unless its tied to reputation.

That is not a technical issue.  That was a strategic business design 
decision to promote reputation services.

So lets get it out because the bottom line, there was never any sincere 
technically driven group effort to squeeze out all the issues *without* 
a REPUTATION concept clouding the issues.

-- 
Sincerely

Hector Santos, CTO

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 25 Jan 2008 10:36:49 +0100

Hector Santos wrote:

> The deployment guide specifically states:

> And that implies even a VALID signature. So the DEPLOYMENT
> draft changes the semantics of DKIM-BASE itself

Of course a PASS from an "unknown stranger" cannot directly 
help you.  It is relatively simple for spammers to get a PASS,
no matter if it is DKIM or SPF.  With an SPF PASS receivers
can bounce later, and in both PASS cases they could black- or 
whitelist the sender / signer.

After they black- or whitelist it is no "unknown stranger".

The "accredidation or reputation data" is marketing speech
for "black- or whitelist", and of course receivers can buy
that as service from a third party, our use a free source
from a third party, or roll their own.

That's no evil scheme redefining DKIM, that is just at it is,
a PASS from an "unknown stranger" does *NOT* mean "no spam".

> SSP lowers the need to reputation services and everyone
> with a good engineering, product development and marketing
> sense can see that.

SSP helps you to figure out which mails might be "suspicious"
from the POV of the sender (or rather authors), remotely in
the same direction as SPF FAIL.

SSP does *NOT* help you to create black and white lists for
a 1st or 3rd party DKIM PASS, let alone for SPF or PRA PASS.

How you create your white or black lists, roll your own, or
find free or commercial services, is your decision, and if
all you want is to reject SSP and SPF FAIL you need no list
at all (well, maybe you need "trusted forwarders" for SPF).

> To suggest we are all WRONG is offensive.  The fact is, we 
> were not wrong.

The fact is that domain owners trying to control where their
domain names appear in e-mail author addresses is an unheard
of twist of the mail architecture, and in comparison PRA was
"a modest proposal".

On my dead box I have a few old mails From: you.  Under mail
rules since RFC 822 I am entitled to resend them to say Eric,
maybe in a discussion about the merits of SMTP HEAD vs. SREJ.

That you (as domain owner) can suddenly try to decree that I
cannot resend your old unsigned mail to Eric is preposterous
and a design issue in SSP.

> Can you outline the serious TECHNICAL flaws?

See above.  And that's only one of numerous examples where 
"domain owner controls all author addresses everywhere" is
utter dubious.

 Frank
-- 
(don't worry, I don't use "resend", I don't like this feature)

---

From: Mark Delany <[email-masked]>
Date: Fri, 25 Jan 2008 05:23:12 -0800

On Jan 24, 2008, at 6:14 PM, Hector Santos wrote:

>> If for no other reason than the obvious fact that SSP is not  
>> making progress as it stands. We need some sort of reset if we  
>> hope to proceed.
>
> Its unfortunate that it has nothing to do with technical reasons  
> but the  powers that are pushing reputations instead. The fact is,  
> Dave's never cared for SSP

It's the IETF, everyone has a say regardless of whether they are  
qualified. You, me, Dave, everyone here.

But to disagree with you, I voted +1 precisely for technical reasons.  
I want a simple solution that non-WG-specialists can grok.  I don't  
think we have that today.

Mark.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 25 Jan 2008 15:18:17 -0000

> indicate support or opposition.

-1 - mainly because the proposal is meaningless.

SSP is applied by verifiers close to the final recipient. We expect  
messages to be "already-signed" at the point, so you essentially seem to  
be saying "SSP is NEVER to be applied".

Even if "already-signed" is taken to mean "already-validly-signed", that  
still leaves open the question "has it been signed by the right people?",  
and answering that question is the whole point of SSP.

Even if all the From addresses have SSP policies "all" (in which case any  
valid signature is good enough) you still need to do the SSP lookup in  
order to establish that fact.

Because, if one of them has SSP=strict, and you fail to lookup the SSP,  
then you will let through messages that the strict-domain wanted to you  
reject.

So the proposal is tantamount to abolishing the 'strict' category  
entirely. Either that, or it is meaningless.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 25 Jan 2008 15:26:02 -0000

> and a design issue in SSP.

Actually, it is a design issue in DKIM. If Hector wants to prevent you  
resending his messages to Eric, all he has to do is to include the  
relevant "Resent-*" headers within the scope off his signature (which  
amounts to a declaration that there are none). So if you then resend them  
to Eric, Eric will find that Hector's signature no longer works (and, of  
course, Hector's SSP=strict :-( ).

---

From: <[email-masked]>
Date: Fri, 25 Jan 2008 12:08:20 -0500

Charles,
Are you not making the assumption that implementaors may check SSP before checking dkim? A quick SSP lookup first returning a strict against a third party dkim signed mail may be processed differently than a SSP relaxed
Thanks,

Bill Oxley
Messaging Engineer
Cox Communications

---

From: Damon <[email-masked]>
Date: Fri, 25 Jan 2008 12:28:44 -0500

> Are you not making the assumption that implementaors may check SSP before checking dkim? A quick SSP lookup first returning a strict against a third party dkim signed mail may be processed differen…

Are we assuming that multiple from's are going to fall in the same
catagory as a 3rd party signed message? This is opening a can o'
worms.

Regards,
Damon Sauer

---

From: Hector Santos <[email-masked]>
Date: Fri, 25 Jan 2008 12:32:23 -0500

> But to disagree with you, I voted +1 precisely for technical reasons. I 
> want a simple solution that non-WG-specialists can grok.  I don't think 
> we have that today.

Well Mark, I'm surprise if you really mean that.  If you are saying this 
from a managerial standpoint just to get this effort rubber stamp, then 
  I suggest to get an engineer on top of this.  If you are saying this 
from an engineering standpoint, then I have to believe you have it in 
your vains to see how issue 1521 is going to negatively impact the 
general wide adoption of DKIM/SSP.

In short, if we accept 1521, then receivers can only implement DKIM/SSP 
with a "batteries required" concept - 3rd party reputation services.

Here is a synopsis of the situation:

In 5016 requirement #9, we have:

    9.  SSP MUST NOT be required to be invoked if a valid first party
        signature is found.

We got it to this point where everyone compromise based on the secured 
idea that forging a 1st party key would need to be done with internal 
theft in order to exploit it.

Now with the new text, the desire is that SSP doesn't apply even for 
valid 3rd party signatures.

So the "new requirement #9" based on ISSUE 1521, we would have to change 
it to:

    9.  SSP MUST NOT be required to be invoked if any valid
       (first or third party signature) is found.

Well, we been through this exercise before and it was proven that this 
can be a major exploit.   We shown over and over again during the DKIM 
Threat Analysis.

Today, as shown by the deployment guide, the only way to honor this is 
to implement reputation services when there is a VALID signature.  And 
please note very strongly, the guide also says that no 
accreditation/reputation scheme, not even the valid signature is good.

I see this "strategic" as a major technical design mistake.

We do have implementation issues with ESP.  But there are not ones that 
are not solvable and no one is suggestion that reputation services are 
not valuable.  But to require a non-standard procedure (batteries) as 
part as RFC standard IMV is going to raise the barrier of wide adoption.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Fri, 25 Jan 2008 12:40:04 -0500

> and a design issue in SSP.

By why would be resending my original DKIM-signatures in your 2822 headers?

> "domain owner controls all author addresses everywhere" is

Again, I ask, where is SSP flawed?

What you are saying the multiple co-authors allowance was flawed to 
begin with.

The fact is, in most x822/non-x822 gateway systems, it is incompatible 
as MOST online electronic mail systems has only a 1 single author 
concept.  Anyone who say there were wrong for PRE-EXISTING as such for 
many years is not correct.

But thats besides the point.

If you very this from a protocol consistency standpoint, in terms of 
DKIM signatures and the expectations, where is the applicability of SSP 
against the co-author list flawed?

If you wish to say there are "implementation" and "feasibility" 
concerns, that is entirely different issue.  But issue 1521 can not be 
views as solving that problem, because it makes things worst.  Not better.

We been thru all this before.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Fri, 25 Jan 2008 12:54:32 -0500

> By why would be resending my original DKIM-signatures in

Oh I see, you are "redirecting" the original mail to someone else as if 
it was "new."

You are not using the FORWARDING features of the MUA.

Well, I think I would prefer the protection here because even though you 
are a GOOD GUY, if we allow this loophole, the bad guy will exploit it.

The end result is that if you see my messages are "special", then you 
know that you can't "resend" it as "me."

Your MUA should tell ya

      "Sorry, you can't do this. This message is Special."

We can't have it both ways.  The same way of doing things and expect to 
get the security we are seeking.

Something has to give and this one is perfectly acceptable to me because 
it helps secured my domains as I intended it to be secured with a 
DKIM=STRICT.

-- 
Sincerely

Hector Santos, CTO

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 25 Jan 2008 13:16:15 -0500

> Hector Santos wrote:
>Sent: Friday, January 25, 2008 12:55 PM
>To: Frank Ellermann
>Cc: [email-masked]
>Subject: Re: [ietf-dkim] SSP vs. reputation
>
>Oh I see, you are "redirecting" the original mail to someone 
>else as if it was "new."
>
>Well, I think I would prefer the protection here because even 
>though you are a GOOD GUY, if we allow this loophole, the bad 
>guy will exploit it.
>

Absolutely true.

>The end result is that if you see my messages are "special", 
>then you know that you can't "resend" it as "me."
>

All your messages are special!

>      "Sorry, you can't do this. This message is Special."

I agree that a well behaved MUA would do this. BAD MUA! BAD!

>We can't have it both ways.  The same way of doing things and 
>expect to get the security we are seeking.
>

+1 

Found this interesting article which is germane even if I don't agree
with the authors conclusion and desire to pull an "Al Hague".  
E-mail and its security discontents
Why Microsoft, Cisco, IBM and others need to step up to protect SMTP
http://www.arnnet.com.au/index.php/id;1603491549

>Something has to give and this one is perfectly acceptable to 
>me because it helps secured my domains as I intended it to be 
>secured with a DKIM=STRICT.
>

And this desire for protection grows as we all run in circles. The other
day I was going through some boxes that had been sitting in my basement
for a (long) while. Found a box filled with internet industry magazines
from the mid-to-late 1990s. With only a few tweaks the articles and
letters to the editor related to abusive email would be applicable
today.

Food for thought.

---

From: Hector Santos <[email-masked]>
Date: Fri, 25 Jan 2008 13:51:46 -0500

> All your messages are special!

If you wrote it, its special. Period. :-)

> I agree that a well behaved MUA would do this. BAD MUA! BAD!

Not checking it offhand, I wonder how current MUA PGP or currently 
supported mail integrity technology handle the "resending" of digitally 
signed mail.  Does it make a point of popping up?

      "Resending this message as new MAY break the integrity"

In any case, this would be item in the checkoff list for new DKIM/SSP 
ready MUA designs.

>> expect to get the security we are seeking.

"Who moved my cheese?" (http://www.whomovedmycheese.com) is my 
recommended book to those afraid of change.

> http://www.arnnet.com.au/index.php/id;1603491549

I bookmarked this to read it later on today.

> letters to the editor related to abusive email would be applicable

I honestly think everyone wants the same goals. I respect Mr. Crocker 
mantra for incremental changes.  Thats conservative and necessary.  But 
then you see the conflicts of self-interest reputation service marketing 
campaign that is basically nullifying all logic.

If you have not seen my DSAP IETF I-D (Now expired),

     http://tools.ietf.org/html/draft-santos-dkim-dsap-00

it was based on the simple premise of making sure the DKIM-BASE protocol 
is consistent with the domain's signing or non-signing expectations. It 
was designed to look for the FAULTS in a transaction.

It asked the following questions:

    o  Does the domain ever distribute mail?
    o  Do you expect the mail to be unsigned?
    o  Do you expect to sign all mail?
    o  Is your domain the exclusive signer?
    o  Are 3rd party signers or signatures allowed?
    o  Are 3rd party signers allowed to strip your original signatures?

There fault questions can be answered *without* reputation services in a 
standard general case, wide adoption basis.

-- 
Sincerely

Hector Santos, CTO

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 25 Jan 2008 19:55:50 +0100

> Oh I see, you are "redirecting" the original mail to someone

Whatever results in a From: you, Resent-From: me, as mentioned 
I don't use / like / have this feature, but it's in (2)822(upd).

> You are not using the FORWARDING features of the MUA.

If you mean a MIME Content-Type: message/rfc822 containing your
mail - it's still your old unsigned mail in conflict with your
new "strict signing" policy.  In this hypothetical example I'm
just using 2822upd and MIME as designed, I and my MUA have no
idea what DKIM and SSP are, and you plus SSP try to change the
rules "forgetting" that old unsigned mails from you exist.

So far for "voluntary" and "SSP" :-| 
 
> even though you are a GOOD GUY, if we allow this loophole,
> the bad guy will exploit it.

I see your point, but as this "breaks" various aspects of the
"e-mail architecture" as we know it, I want to watch it when
it hits the IAB (no "1F" from me, Resent-* fans might differ.)

> Your MUA should tell ya

My MUA is stupid, I downgraded it from "mozilla 3" to MS OE :-(

If SSP has ambitions what "resending" MUAs are supposed to do
I missed that chapter in the draft.

> secured with a DKIM=STRICT.

The d*mned old From addresses are not more "your domain" when I
find them in an 2006 mbox file, in a sense that's now "my mail".

Bad style if I "resend" mail from you to third parties without
your permission, sure.  But if it was an old mail sent to the
folks invited to discuss SMTP HEAD, and one of them asks me to
"resend" it there's no netiquette issue, only the potential SSP
problem.  Okay, the person could "whitelist" Resent-From: me to
bypass your SSP strict rule, yet another undocumented effect.

You are forcing SSP on folks NOT volunteering to participate -
not nice, putting it mildly, maybe it should be "experimental".

 Frank

---

From: Hector Santos <[email-masked]>
Date: Fri, 25 Jan 2008 14:28:00 -0500

Frank,

The point is that in a new level of DKIM/SSP operations, these things 
would be a natural part of the "checking" Frank.

It may not jive with some aspects of the current relaxed nature of 
internet email, but that is why we have such a high rate of fraud too, 
the unverified relaxed nature of x821/x822 allows for such a high rate 
of exploitation.

Also, no one ever said that SSP or even DKIM is for everyone. Some 
people simply will not be able to use it, and that includes legacy 
Mailing List systems.

So SSP/DKIM is really only going to be useful for those who WANT it and 
do not expect to be using their domains in ways they promote breaking 
their own policies.

It will not make sense for me to add DKIM=STRICT for santronics.com and 
then go to some greeting card service and use my santronics.com address 
for their services.  It doesn't make sense.

But I will use a DKIM=STRICT with the intention of stopping others from 
forging my domains at this legacy ESP systems which is such a BIG 
problem today across the board.

The fact is, I will venture very strongly millions of people and 
companies with their own domains will begin using STRONG policies if 
given the change to do so and will not sweat a tear if it breaks Frank's 
way of doing mail or any other ESP mail system or the bad guy forging or 
facsimile of such exploitation is high - TODAY.

But again, if a domain sees that as a problem then he doesn't have to 
use a SSP strong policy.

Thats been debated over and over and over again. and its no different 
than any other security related augmented technology that removes or 
affects the current exploitable relaxed way of doing things.

That includes Reputation Services which you have just shown would be an 
exploit as well by resending mail A.K.A replaying mail unchanged.

-- 
Sincerely

Hector Santos, CTO

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 25 Jan 2008 14:40:50 -0500

>Sent: Friday, January 25, 2008 2:28 PM
>To: Frank Ellermann
>Subject: Re: [ietf-dkim] Re: SSP vs. reputation
>
>Frank,
>

<snip>

>
>It will not make sense for me to add DKIM=STRICT for 
>santronics.com and then go to some greeting card service and 
>use my santronics.com address for their services.  It doesn't 
>make sense.
>

Actually Hector, you can feel perfectly comfortable using your
santronics.com email address with our greetingcard sites AND uasing
DKIM=STRICT. Try it, you'll like it <G>. 

Over the course of the past year we re-architected our processes for
precisely the types of reasons that this discussion is happening. When
we send a greeting card we are using our email address - for example
[email-masked] - so that we are taking responsibility for
the email we send. We expose your name and email address to the
recipient in the subject line and body of the email. 

It makes perfect sense. I'm hoping that other social expressions sites
pick up on the fact that they can no longer (by this I mean that it is a
risky behavior and promotes abuse) use "your" email address as the Mail
>From and From when they send a notification.

There are other pieces, parts and considerations besides DKIM in how we
re-architected to improve security. We aren't where we want to be but
are moving down the path as fast as we can. Sometimes it feels like I'm
turning an oil tanker.

Mike

DKIM=DKNY for geeks (Sorry, couldn't resist)

---

From: "J D Falk" <[email-masked]>
Date: Fri, 25 Jan 2008 20:59:24 -0500

Hector lamented:

>   powers that are pushing reputations instead. The fact is, Dave's

Not sure which "other guy" you're thinking of, but...I've been working
on reputation systems since before that term was invented, at both of
the biggest mail systems in the world -- and I can tell you with quite a
bit of certainty that SSP will not hinder that work.  (It won't help
much, either.)

We need reputation calculations now, without SSP.  We'll need to do it
with SSP.  Some of the inputs may change, some of the algorithms may
change, but that's mostly orthogonal.

> It is a very SAD that not enough the technical developers are here to

I agree that we have the wrong set of voices here, but I don't think
anyone here is trying to scuttle SSP for their own benefit.  We're all
just trying to make sure it'll actually be useful, so that we don't have
to go through this whole process again in another year or three.

--
J.D. Falk
Receiver Products
Return Path

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 29 Jan 2008 11:15:07 -0500

+1

-- 
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781-372-1922 | f: 781-863-8118
:: www.e-dialog.com