Subject: [ietf-dkim] ISSUE 1525 -- Restriction to posting by first Author breaks email semantics

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

> 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

Your reading of the archive shows rather more complete and definitive 
discussion than mine. In fact I read the archive as tending in the direction 
of changing the specification to use Sender: rather than From.

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

Since this specification modifies RFC2822 that fact needs explicit justification.

The current SSP language modifies RFC2822, and so there should be considerable 
clarity about the need, the benefit, and the impact.

d/
-- 

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 15 Jan 2008 04:35:49 +0100

Dave Crocker wrote:

> The current SSP language modifies RFC2822, and so there should be
> considerable clarity about the need, the benefit, and the impact.

+1

---

From: Douglas Otis <[email-masked]>
Date: Mon, 14 Jan 2008 20:41:48 -0800

+1

This issue also covers ISSUE 1519.

When a domain indicates all messages are signed via SSP "dkim=all",  
the normal use of RFC 4871 permits signatures to be on-behalf-of any  
header.  While the SSP domain is determined by the "first author"  
domain, the signature might be applied by the "first author" domain,  
but not on-behalf-of the "first author" as determined by the DKIM- 
Signature header's i= parameter.

There are a couple of choices to resolve the resulting conflicts  
created by the current SSP definitions where:

a) restricted keys signed on-behalf-of other than the "first author"  
are SSP policy of "all" compliant

b) unrestricted keys signed on-behalf-of other than the "first author"  
are not SSP policy of "strict" compliant

Both a and b conditions represent a possible problem.  Unrestricted  
keys MUST BE used by trustworthy systems where the choice of which  
header to sign on-behalf-of MUST BE in compliance with the domain's  
signing policy.

-- It is ludicrous to define SSP in a manner that negates a signature  
where the signing domain can be used for the "first author" and the  
where the key used is unrestricted by the g= parameter.  

-- It is questionable to define SSP in a manner where a signature not  
used for the "first author" and where the key is restricted by the g=  
parameter. 

By changing a and b to:

A) restricted keys signed on-behalf-of other than the "first author"  
are not SSP policy "all" compliant

B) unrestricted keys signed on-behalf-of other than the "first author"  
are SSP policy "strict" compliant

Then allows the following generalization:

1) restricted keys signed on-behalf-of other than the "first author"  
are not "all" or "strict" compliant and are to be treated as "invalid".

This solves the concern Jim raised regarding a process that normally  
only notes whether a key selector provided a valid result.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 15 Jan 2008 12:01:34 -0000

> discussion than mine. In fact I read the archive as tending in the  
> direction of changing the specification to use Sender: rather than From.
>

Indeed. I don't like that "1st author" bit.

If there are multiple authors, then whichever one is also the Sender  
should be the one that the signature should relate to.

If the Sender is none of them (the secretary sent it on behalf of them  
all), then there is a problem. In that case I might be happy for the  
Sender to match the signature, or even to go back to a "first author",  
though I don't really see what is wrong with an "at least one author".

It the Sender is absent with multiple authors, then the message if not RFC  
2822 compliant, and all bets are off.

And if the signature is "restricted" (by g= or whatever), then the rules  
might be different.

-- 
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: Douglas Otis <[email-masked]>
Date: Tue, 15 Jan 2008 09:52:28 -0800

>> Your reading of the archive shows rather more complete and  
>> definitive discussion than mine. In fact I read the archive as  
>> tending in the direction of changing the specification to use  
>> Sender: rather than From.
>>
>> Would you please explain the basis for assessing that this topic  
>> got sufficient discussion and that there was rough consensus on it?
>>

At least this limits the expected number of transactions for obtaining  
the SSP policy. : )

> should be the one that the signature should relate to.

Agreed.  The signature should accurately reflect which entity the  
signature is on-behalf-of.

> If the Sender is none of them (the secretary sent it on behalf of  
> them all), then there is a problem. In that case I might be happy  
> for the Sender to match the signature, or even to go back to a  
> "first author", though I don't really see what is wrong with an "at  
> least one author".

There is not a problem when signatures are permitted to be on-behalf- 
of any header or entity with a proviso that the signature's domain  
would have been valid when used for the "first author".  The only case  
where this might be a problem would be when g= restricted keys are  
used to sign on-behalf-of entities that are not "first authors".  The  
easiest solution would be to declare signatures not on-behalf-of  
"first authors" having restricted keys to be considered "invalid" for  
the purpose of SSP compliance evaluation.

> It the Sender is absent with multiple authors, then the message if  
> not RFC 2822 compliant, and all bets are off.

Dave was right to suggest only considering the domain of the  
signature.  This problem is greatly simplified by only considering the  
domain of the signature to be significant.

> And if the signature is "restricted" (by g= or whatever), then the  
> rules might be different.

Agreed.  A restricted key is the _only_ case where a domain's signing  
policy might not have permitted restricted key's use for entities that  
are not "first authors".

-Doug

---

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

Dear Chairs & Dave,

In the interests of moving forward, I'd like to raise four concerns 
about the message below with an eye toward how we (a) keep issues closed 
and (b) close open issues.

First, you have referenced RFC 5016 as the logic for the inclusion of 
the text that Dave objects to.  Dave has requested that consensus be 
formed FOR the change when there was consensus for the text found in 
[11] below.  I believe the onus is on Dave to show a change in 
consensus, and not the other way around.  This group, like many others, 
could run around in circles were it otherwise the case.

Second, even were it otherwise the case, Dave claims that we are 
asserting a change to RFC2822.  That assertion requires support, and I 
see none.  Nobody is forbidding multiple addresses on the 2822.From 
line.  Furthermore, SSP would work precisely as one would expect if both 
addresses come from the same domain.  We enter a world of ambiguities if 
those addresses are different, of course, and so something needs to be 
said, and something is said.

Third, the case in question is a corner case, and handling it as such in 
a way that is safe allows us to better handle the general case.

Finally, even were we to reject all of the above logic, if we review the 
text of Issue 1525 ([10] below), we do not see proposed textual 
changes.  I'd ask that for any issue to either remain open or for any 
issue to be ACCEPTed that there be at least SOME proposal for a textual 
change, even if it is as simple as "remove Section 2.3 and rework step 4 
in Section 4.4 to use any signature."  We don't even have that much.

Eliot

> considerable clarity about the need, the benefit, and the impact.

First, You've asserted that this specification modified RFC2822.  Can 
you please justify that assertion?

More importantly, I do not see an alternative proposed in your issue, 
and in many of your issues, for that matter.  It's important to state 
what you want done.  Here you haven't done that.

---

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

>> considerable clarity about the need, the benefit, and the impact.
I'd like to explain the basis for what's currently in the draft.  The 
text in question is at the beginning of section 2.3, with supporting 
non-normative rationale (which I will disagree slightly with here).

The goal of SSP is to determine the practices of the (alleged) author of 
the message.  The practices of the (alleged) agent responsible for the 
transmission of the message aren't relevant; the agent could be the 
author's secretary, or for that matter the author's (or authors') 
attorney or PR firm.

According to RFC 2822 section 3.6.2, the Sender header field MUST appear 
whenever the From field contains more than one mailbox specification, 
and SHOULD appear whenever the message is transmitted by other than the 
author.  However, even when the From field contains more than one 
mailbox specification, the Sender field still represents the 
transmitting agent, not the author.  Use of the Sender field would 
therefore apply SSP incorrectly.

We then are left with the dilemma of what to do when there is more than 
one author.  One option would be to look up the practices of all of the 
authors and combine them.  An attacker could then potentially make up 
messages with many alleged authors as a make-work attack on SSP.  
Instead, by looking at the first From address only, we force an attacker 
who wants to weaken SSP by inserting an extra address to put the bogus 
address first, causing the message, most likely, to look like it came 
from someone else entirely.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Tue, 15 Jan 2008 16:33:45 -0800

On Jan 15, 2008, at 2:54 PM, Jim Fenton wrote:
>
> The goal of SSP is to determine the practices of the (alleged)  
> author of the message.

SSP asserts the signing policy of the _domain_, and not that of the  
"first author".  SSP assertions are referenced from the domain of the  
"first author" as the entity protected by SSP.  When a domain signs  
with an unrestricted key on-behalf-of entity other than the "first  
author", and happens to include a 'first-author" address that is  
within their domain, it MUST BE assumed to be compliant with the  
domain's signing policy.  In this case, there is no need to check  
against the SSP assertions.  In other words, the Sender or the third  
 From email-address could be signed on-behalf-of and yet be compliant  
when the domains match that of the "first author".

> The practices of the (alleged) agent responsible for the  

Only practices of the signing domain are relevant.  A corner case is  
with respect to a message signed on-behalf-of the office administrator  
that includes a "first author" within the same domain.  Such a message  
is compliant with an assertion that all messages from the domain are  
signed, as in "dkim=all".

When the entity's address within the Sender's header being signed is  
within a different domain from that of the "first author", the message  
would not be complaint with "dkim=all".  SSP policy is about _domains_  
and not about _entities_.  DKIM's charter excludes signatures being  
about _entities_.  DKIM is about _domains_.

> According to RFC 2822 section 3.6.2, the Sender header field MUST  
> appear whenever the From field contains more than one mailbox  
> specification, and SHOULD appear whenever the message is transmitted  
> by other than the author.  However, even when the From field  
> contains more than one mailbox specification, the Sender field still  
> represents the transmitting agent, not the author.  Use of the  
> Sender field would therefore apply SSP incorrectly.

When the entity's address contained within the Sender header is being  
signed, and the signature is within the same domain as that of the  
"first author", then SSP policies apply to both the Sender and "first  
author".

> We then are left with the dilemma of what to do when there is more  
> than one author.

No.  By definition, SSP policy is determined by the "first author"  
domain.  A requirement should be added for a signature using a g=  
restricted key.  For a restricted key, the signature is valid with  
respect to policy compliance when on-behalf-of the "first author".

> One option would be to look up the practices of all of the authors  
> and combine them.

No. This would result in more transactions and highly dubious results,  
as an indication of a signature being valid means what?  Which domain  
is making the assurance?  Policy assertions should stem from the  
"first author", but signatures should be on-behalf-of the entity  
responsible for their introduction.

> An attacker could then potentially make up messages with many  
> alleged authors as a make-work attack on SSP.

It would be doubtful anyone could offer an understandable way of  
conveying who did what as well.  The recipient should only need to  
look at the _domain_ of the "first author" to understand which  
_domain_ originated the message when this domain's policies are either  
"all" or "strict" and the message is marked as DKIM signed.   DKIM is  
not required to indicate _who_ sent the message.

When a large ISP signs all messages, they may wish to include an  
opaque i= parameter within their signatures and use an SSP of  
"dkim=all".  This changed definition would allow their customers to  
place their desired email-address as "first author" (perhaps even the  
email-address offered by the provider) without the message being  
deemed non-compliant.  The opaque i= parameter thereby protects their  
customer's privacy, while also offering a means for providers to curb  
abuse.

> Instead, by looking at the first From address only, we force an  
> attacker who wants to weaken SSP by inserting an extra address to  
> put the bogus address first, causing the message, most likely, to  
> look like it came from someone else entirely.

Only look to the "first author" for locating the _domain's_ policy.   
Keep in mind that DKIM is not about identifying individuals, as you  
appear to be implying.   Ironically, by not restricting which entity a  
signature can be on-behalf-of, enables domains to clarify who sent the  
message.  As SSP is currently defined, domains might be forced to  
falsely identify who sent the message or make who sent the message  
ambiguous.  Placing unnecessary restrictions on the use of the i=  
parameter is counter productive and is highly problematic.

-Doug

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 16 Jan 2008 09:07:18 +0100

Jim Fenton wrote:
 
> I'd like to explain the basis for what's currently in the draft.
[...]

Thanks.  I try to explain my issues with this approach:  When
the former MARID WG tried to "unify" SPF and "CallerID" (an
XML-over-DNS predecessor of SenderID/PRA) some folks strongly
objected, because a non-empty envelope sender address isn't
guaranteed to be the same as the PRA.

E.g. not all MSAs implement option 8.1 in RFC 4409, and even
if they do it's far from clear if they get it right for mails
with Resent-* header fields.  There are other corner cases,
simple implementations of moderated newsgroups etc., where a
PRA cannot work as expected.

Nevertheless PRA is the best best possible solution after the
dubious decision to ignore the envelope sender address.  In
years of discussions on the "SPF discuss" list all attempts
to outsmart PRA with other ideas failed miserably, and of
course "2822-From" was one of those ideas.

Likewise all attempts to remove Resent-* from the picture in
2822upd on the rfc822 list failed miserably.  In other words
we are either stuck with PRA, or we try Dave's proposal to
ignore Resent-* anyway (arguably in line with 4409 8.1), and
ignoring Resent-* means "take 'sender' as defined in 2822upd".

A clarification of "sender" in 2822upd is currently discussed
on the rfc822 list.  NOW would be a good time to chime in for
folks having their own ideas (not limited to "first author").

What that's about is simply that ordinary users consider one
or more of the From-addresses they use as "their" address.

These users won't let domain owners overrule this slightly
erroneous view.  It was already tough to convince stubborn
users (among others) that there is no such thing as "their"
envelope sender address, to be used whereever they like it.

If "SSP strict" is bound to the "first author" it's DOA. :-(

I fail to see why we should create an RFC only working for
PayPal & Co. - especially while they are still too timid to
use FAIL in their SPF or PRA policies.  SSP "first author"
would be far more restrictive than anything SPF or PRA do.

 Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 16 Jan 2008 11:08:45 -0000

On Tue, 15 Jan 2008 22:54:17 -0000, Jim Fenton <[email-masked]> wrote:

> authors and combine them.

That seems like a good argument for choosing whichever of the From  
addresses has the same domain as given by the signature. Essentially, "at  
least one of the From addresses" should be un-suspicious. I might add that  
iff the Sender was different from that one From domain the rule might be  
different.

The one certain piece of information you start from is the domain that  
signed it. So that is the domain you should be looking up.

---

From: "J D Falk" <[email-masked]>
Date: Wed, 16 Jan 2008 12:24:37 -0500

> I fail to see why we should create an RFC only working for PayPal &
> Co. - especially while they are still too timid to use FAIL in their
> SPF or PRA policies.  SSP "first author"

It's very interesting that while PayPal may be "too timid to use FAIL in
their SPF or PRA policies," they /have/ -- with much public fanfare --
made deals with Yahoo! and other ISPs to reject any messages that can't
be verified with DomainKeys or DKIM.

There'll surely be more of these 1:1 agreements, while we wait for SSP
to become useful.  If we wait long enough, SSP won't even be necessary
for the big, high-value signers & verifiers.

--
J.D. Falk
Receiver Products
Return Path

---

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

Jim,

Please read the following carefully and assume, just as a hypothetical, that I 
might actually have a legitimate basis for the assessment being offered and 
that there is a chance that your views are not automatically correct:

Jim Fenton wrote:
> the message. 

That certainly describes the engineering focus that has been taken for the 
current draft.  It does not necessarily represent the precise goal of SSP:

RFC 5016:
>           While a DKIM signed message
>    speaks for itself, there is ambiguity if a message doesn't have a
>    valid first party signature (i.e., on behalf of the [RFC2822].From
>    address): is this to be expected or not? 

This requirements statement is actually self-contradictory, since the words 
"speaks for itself" rather explicitly means that any signature is sufficient, 
while the rest of the sentence seems to mean that the wishes of the purported 
author dominate.

In any event, "on behalf of" is key wording that permits more flexibility than 
you seem to be acknowledging.  Note, for example, that the agent specified in 
the Sender field is acting "on behalf of" the author.

Whereas SSP began as a simple idea as a means of deciding whether an unsigned 
message should have been signed, it has morphed into an effort to validate the 
 From field.  That is a very, very different goal.

While DKIM has the goal of assigning *any* identity to a message, so that that 
identity can be assessed, the current work on SSP is attempting to instead 
validate authorship.

For the purposes of ensuring the presence of any valid identity, using the 
Sender: field is just as acceptable as From:.  It also has the appeal of being 
far simpler and, by the way, supporting a wider range of legitimate usage 
scenarios.

Rather than deal with the problems caused by rigidly insisting on using the 
author string, you seem intent on ignoring the feedback about those problems 
and the remarkably simple and useful suggestion to switch to the Sender: field.

But, then, this focus on using author information goes back to a belief that 
SSP can somehow be useful directly to end-users, in spite of there being no 
empirical basis for believing this and plenty of empirical basis for knowing 
that it will be trivial for bad actors to bypass this bit of "protection".

Let's pay some attention to likely efficacy, please.

d/
-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Wed, 16 Jan 2008 09:57:54 -0800

> If "SSP strict" is bound to the "first author" it's DOA. :-(

DOA. It might be helpful to get a sense of proportion here as this
issue is so many angels on a pinhead in the real world. The real
world doesn't have multiple from addresses regardless of what unearthed
arcana somebody found in rfc2822.

Not to mention that this doesn't break rfc2822 in any way shape or
form. You are still completely at liberty to send with multiple From
addresses. Nor are you prevented on performing an SSP check on any
address that you choose to.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 16 Jan 2008 10:13:05 -0800

Dave Crocker wrote:
> Jim,
> 
> Please read the following carefully and assume, just as a hypothetical, 
> that I might actually have a legitimate basis for the assessment being 
> offered and that there is a chance that your views are not automatically 
> correct:
> 
> 
> Jim Fenton wrote:
>> The goal of SSP is to determine the practices of the (alleged) author 
>> of the message. 
> 
> That certainly describes the engineering focus that has been taken for 
> the current draft.  It does not necessarily represent the precise goal 
> of SSP:
> 
> RFC 5016:
> This requirements statement is actually self-contradictory, since the 
> words "speaks for itself" rather explicitly means that any signature is 
> sufficient, while the rest of the sentence seems to mean that the wishes 
> of the purported author dominate.

No it isn't. A signed message is a signed message. It doesn't say about
any relationship to any outside address. It speaks for itself. SSP is
about the subset of signatures that have a relationship with the From
address. Any signature is not sufficient by definition.

> Whereas SSP began as a simple idea as a means of deciding whether an 
> unsigned message should have been signed, it has morphed into an effort 
> to validate the From field.  That is a very, very different goal.

This is revisionist history. I've pointed to both of the historical
documents of IIM and DK which directly contradict you.

		Mike

---

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

> arcana somebody found in rfc2822.

Wasn't aware that you operated with such a definitive experience base to 
permit making that assertion.

While it doesn't have it very often, no, but it does occur in the wild.

In any event, the view that features can be ignored just because they don't 
occur very often is quite a dangerous design approach for a global standards 
effort.

d/
-- 

   Dave Crocker

---

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

Michael Thomas wrote:
>> words "speaks for itself" rather explicitly means that any signature 
>> is sufficient, while the rest of the sentence seems to mean that the 
>> wishes of the purported author dominate.
> 

You are ignoring the "While... there is ambiguity" language, which ties these 
two issues together.

>> unsigned message should have been signed, it has morphed into an 
>> effort to validate the From field.  That is a very, very different goal.
> 

Evidently you missed the massive number of discussions both in the working 
group and elsewhere that agreed that SSP was about unsigned messages.  And, 
just for the heck of it, note that you missed the "error" about this in the 
DKIM Overview draft that has been circulating for quite a few months.

Given how little serious discussion has taken place in this working group, and 
how little effort there has been to summarize discussions, it is not 
surprising that you are quite convinced that you know exactly what the right 
perspective is. You haven't been pressed to consider that the views you prefer 
are seriously challenged.

Such certitude as greatly facilitated by strong language that persistently 
dismisses contrary views, as has been the pattern for this working group.

d/
-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Wed, 16 Jan 2008 10:36:24 -0800

Dave Crocker wrote:
> Evidently you missed the massive number of discussions both in the 
> working group and elsewhere that agreed that SSP was about unsigned 
> messages.  And, just for the heck of it, note that you missed the 
> "error" about this in the DKIM Overview draft that has been circulating 
> for quite a few months.

You specifically said "began". That is completely historically
inaccurate going back many, many years. In fact from the very
beginning.

> Given how little serious discussion has taken place in this working 
> group, and how little effort there has been to summarize discussions, it 
> is not surprising that you are quite convinced that you know exactly 
> what the right perspective is. You haven't been pressed to consider that 
> the views you prefer are seriously challenged.

You made a categorical statement that the goals have "morphed". This
is completely false, and will remain false regardless of how many times
you repeat it.

		Mike

---

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

Michael Thomas wrote:
>> "error" about this in the DKIM Overview draft that has been 
>> circulating for quite a few months.
> 

Gosh, Michael.  I thought I was part of those initial discussions, too, and I 
am quite sure that my memory is just as strong about this as yours.

In fact, I remember pressing this concern from the start.

>> group, and how little effort there has been to summarize discussions, 
>> it is not surprising that you are quite convinced that you know 
>> exactly what the right perspective is. You haven't been pressed to 
>> consider that the views you prefer are seriously challenged.
> 

Yeah.  Those of us who disagree with you have entirely messed up memories 
while those who agree have perfect memories.  No chance your assessment might 
even possibly be off the mark.  Better to just dismiss any concerns that are 
expressed.

d/
-- 

   Dave Crocker

---

From: "J D Falk" <[email-masked]>
Date: Wed, 16 Jan 2008 13:56:35 -0500

Michael Thomas wrote:

> issue is so many angels on a pinhead in the real world.
> The real world doesn't have multiple from addresses regardless of what
> unearthed arcana somebody found in rfc2822.

+1

Let's design SSP for the real world.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 16 Jan 2008 13:56:59 -0500

> for the big, high-value signers & verifiers.

Agreed.  It's much better to define a protocol to do this now so the process 
scales and is not just available to large commercial senders.

Scott K

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 16 Jan 2008 20:23:36 +0100

Michael Thomas wrote:

>> Whereas SSP began as a simple idea as a means of deciding whether
>> an unsigned message should have been signed, it has morphed into
>> an effort to validate the From field.  That is a very, very 
>> different goal.
 
> documents of IIM and DK which directly contradict you.

For other historical documents compare RFC 822, 733, and 724 (1977).
It was always the idea that you could tell me what to send in your
your name (from: you, sender: me), maybe I'm unable to sign in your
name, but I could sign that I'm the sender.  
 
What we do (in this hypothetical example) is perfectly legal, no
matter what the owner of the domain in your address likes better.

Admittedly multiple authors are rare - as far as I can judge it -
but the mail standards since RFC 724 guarantee that there MUST
be a Sender in this case, we're not forced to sort the authors in 
the From header field.  This has consequences, RFC 4409 option 8.1 
offers to get the Sender right, it does not offer to sort authors.

If you think that's all obsolete nonsense 2822upd needs to say so, 
so far all proposals to deprecate at least Resent-* failed.  It's
plausible to envision an architecture where one of the two Sender-
functions are replaced by a logical order of authors.  But how can
SSP get the world to follow this idea, when folks are used to the
similar Sender-solution for over 20 years ?

 Frank

---

From: Michael Thomas <[email-masked]>
Date: Wed, 16 Jan 2008 11:38:00 -0800

> similar Sender-solution for over 20 years ?

This is all rather beside the point. The current draft doesn't
"break" 2822, it merely limits the applicability of SSP itself. SSP
has lots of other limits of applicability that are completely
unrelated to 2822 as well. That's sort of the point of the protocol
in fact: to give guidance as to what limitations a receiver should
expect. I see no reason why we need to get permission or changes
from 2822upd for SSP's own applicability.

		Mike

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 16 Jan 2008 20:55:30 +0100

J D Falk wrote:

>> The real world doesn't have multiple from addresses regardless
>> of what unearthed arcana somebody found in rfc2822.
 
> Let's design SSP for the real world.

In another article you wrote:
 
| If we wait long enough, SSP won't even be necessary for the big,
| high-value signers & verifiers.

If it's all the same for you and "high-value" signers like Yahoo!
SSP could as well try to be compatible with the RFC 2822 Sender.

Don't be surprised if ignoring Resent-* hurts it in the real world.
Focus on Sender is already shaky, SenderID fans might have other
ideas, and one SenderID fan controls big parts of the real world.

JFTR, I'm no SenderID fan, maybe many Resent-* users also aren't.

 Frank

---

From: John Levine <[email-masked]>
Date: 16 Jan 2008 20:12:30 -0000

>scales and is not just available to large commercial senders.

But the key step in setting up the 1:1 agreements is for the receiver
to identify a sender which is enough of a forgery target to be worth
special treatment.

How does an SSP-like protocol do that?  Assertions like "I am a phish
target" don't do it.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Wed, 16 Jan 2008 12:13:59 -0800

Frank Ellermann wrote:

Michael Thomas wrote:

Mike and Dave were referring to the history of the SSP proposal, not
the history of Internet mail.  The question is whether the SSP proposal
has changed in this respect.  I don't think it has, and I have not seen
any evidence that it has (quotes from previous revisions of the SSP
draft).

The roles of sender and author are different.  The fact that a Sender
header field is required when there are multiple authors is not an
assertion that the sender is, in fact, an author.  It's merely a
consequence of the fact that the sender (agent responsible for the
actual transmission of the message) cannot be inferred from the From
header field in this case.

SSP seeks to determine the author's policy.

-Jim

---

From: <[email-masked]>
Date: Wed, 16 Jan 2008 20:44:39 +0000

> From: [email-masked]
> Date: Wed, 16 Jan 2008 09:07:18 +0100
> Subject: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by firstAuthor	breaks email semantics
> 

> would be far more restrictive than anything SPF or PRA do.

You seem to be asserting here that saying " I know what MTA will deliver my messages to you" and "All mail for which the author is in my administrative domain" are semantically equivalent assertions. If SSP were intended to say something about who could validly transmit those messages I could see that but since it is a policy for how I expect mail from authors within my domain to behave I don't see a useful relationship between how confident someone can be in their SPF record and how confident they can be in their SSP assertions.

_________________________________________________________________
Share life as it happens with the new Windows Live.
http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008

---

From: Michael Thomas <[email-masked]>
Date: Wed, 16 Jan 2008 12:56:10 -0800

> JFTR, I'm no SenderID fan, maybe many Resent-* users also aren't.

There seems to be a thread in these interminable threads that RFC2822's
very structure implies that SSP ought to use address XYZ rather than
asking the obvious question of what we want SSP to do _first_. Can
anybody describe what benefit SSP would give if it chose some other
address? Other than supposedly genuflecting to RFC2822?

		Mike

---

From: Douglas Otis <[email-masked]>
Date: Wed, 16 Jan 2008 12:56:48 -0800

On Jan 16, 2008, at 12:13 PM, Jim Fenton wrote:
>
> The roles of sender and author are different.  The fact that a  
> Sender header field is required when there are multiple authors is  
> not an assertion that the sender is, in fact, an author.  It's  
> merely a consequence of the fact that the sender (agent responsible  
> for the actual transmission of the message) cannot be inferred from  
> the From header field in this case.
>

SSP asserts the policy of "first author's" _domain_.  It is not  
accurate to describe SSP as the "first author's" policy.  Nothing  
within SSP offers this level of policy granularity.

There is no need for a signature to always be on-behalf-of any  
specific header of the message to be compliant with "all" or  
"strict".  Efforts at restricting the i= parameter are doomed by the  
complexity.  Referencing policy should be limited to the "first  
author", otherwise validating a dearth of unsigned email is doomed by  
overhead.

Provided the _domain_ of the signature is able to have signed for the  
"first author", a message can be defined as compliant with "strict" or  
"all" assertions when signed by an unrestricted key on-behalf-of _any_  
identity.

Specifically signing for the "first author" is _not_ required.  DKIM  
or SSP is not about assuring the identity of the "first author", or  
providing "first author" specific policies.  Compliance is determined  
by whether the originating _domain_ of the message is compliant with  
the "first author's" _domain's_ assertions.

Whenever a message does not contain an unrestricted signature applied  
by the _domain_ of the "first author", SSP needs to be checked.   An  
exception should be made for restricted keys.  Restricted keys should  
only be compliant when on-behalf-of the "first author".

By not restricting the i= parameter, DKIM is able to clarify which  
entity introduced the message.  The identity of this entity can even  
be opaque.

-Doug

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 16 Jan 2008 15:49:44 -0600

The debate here is whether or not it's mission-critical for SSP to use 
From: in all cases or whether some other sender identity (like Sender: 
header) could be used to equal effect generally or in specific cases 
(like when there are multiple addresses in From).

Given that it would solve the problem described in 1525 and also bring 
us closer to a consensus position perhaps this thread should discuss 
what is lost through utilization of the Sender header in at least some 
cases.

Arvel

Dave Crocker wrote:

> While DKIM has the goal of assigning *any* identity to a message, so 
> that that identity can be assessed, the current work on SSP is 
> attempting to instead validate authorship.
> 
> For the purposes of ensuring the presence of any valid identity, using 
> the Sender: field is just as acceptable as From:.  It also has the 
> appeal of being far simpler and, by the way, supporting a wider range of 
> legitimate usage scenarios.
> 
> Rather than deal with the problems caused by rigidly insisting on using 
> the author string, you seem intent on ignoring the feedback about those 
> problems and the remarkably simple and useful suggestion to switch to 
> the Sender: field.
> 
> But, then, this focus on using author information goes back to a belief 
> that SSP can somehow be useful directly to end-users, in spite of there 
> being no empirical basis for believing this and plenty of empirical 
> basis for knowing that it will be trivial for bad actors to bypass this 
> bit of "protection".

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 16 Jan 2008 17:17:59 -0500

> what is lost through utilization of the Sender header in at least some

If it's allowed, then it's trivial to construct messages for which the 
identity used in SSP is likely not the one displayed to the end user.  Then 
I'd really have to ask myself what we are trying to accomplish.

Scott K

---

From: <[email-masked]>
Date: Wed, 16 Jan 2008 18:46:57 -0500

I think I am missing something
DKIM base crypto claiming responsibility of the singing domain

SSP Senders signing policy, usage statement of DKIM by sender

ASP Authors signing policy who is not clearly a sender or a member of the signing domain but wants to assert a policy anyway

MUA how to reliably display something useful about the above information

Am I correctly framing the thread?
thanks,
Bill

-----Original Message-----
From: [email-masked] on behalf of Scott Kitterman
Sent: Wed 1/16/2008 5:17 PM
To: [email-masked]
Subject: Re: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by firstAuthor breaks email semantics

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Wed, 16 Jan 2008 15:56:38 -0800

> MUA how to reliably display something useful about the above information

What is the basis for having the MUA as a goal in our work here?

d/
-- 

   Dave Crocker

---

From: Jon Callas <[email-masked]>
Date: Wed, 16 Jan 2008 15:57:28 -0800

> attempting to instead validate authorship.

+1. Well stated.

You summarize my recent grouchiness very well. I think that the  
attempt to validate authorship is not only impossible, but a complete  
or incomplete implementation of same is a bad idea.

	Jon

---

From: Michael Thomas <[email-masked]>
Date: Wed, 16 Jan 2008 16:12:03 -0800

> What is the basis for having the MUA as a goal in our work here?

RFC 5016 doesn't say anything about the role of the SSP client. That's
a feature IMO. How an SSP client uses the data is its own business
and as such an MUA is perfectly entitled to use SSP information as
any other entity, including displaying something.

	Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 16 Jan 2008 16:14:40 -0800

Jon Callas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

Jon,

Please translate your grouchiness into concrete suggestions on what
if anything should change in draft. There are so many different issues
being discussed here that your +1 one is essentially useless because
it doesn't track to anything actionable.

	Mike

---

From: "J D Falk" <[email-masked]>
Date: Wed, 16 Jan 2008 19:15:25 -0500

> What is the basis for having the MUA as a goal in our work here?

Even if it isn't, we'll need a clearer answer for all the people who
expect it to be.

---

From: Jim Fenton <[email-masked]>
Date: Wed, 16 Jan 2008 16:18:52 -0800

> How does an SSP-like protocol do that?  Assertions like "I am a phish

Why not?

-Jim

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 17 Jan 2008 01:26:32 +0100

> Am I correctly framing the thread?

Yes, renaming "SSP as is" to "ASP" would be clearer.

Authors would immediately see that binding "their"
address to some ASP of the domain owner is strange.
Or maybe they even like it, at least it is clearer.

 Frank

---

From: Jim Fenton <[email-masked]>
Date: Wed, 16 Jan 2008 16:30:56 -0800

> wishes of the purported author dominate.

This is not a requirements statement; you are quoting from the 
introduction to RFC 5016, containing discussion leading up to the actual 
requirements statements in section 5.
> effort to validate the From field.  That is a very, very different goal.

You have stated this before, leading to a long thread "Tracing SSP's 
paradigm change."  I have asked you more than once to cite the basis for 
the alleged change, such as text from a previous draft describing this 
"simple idea".  I have not received a response; since you are alleging 
that it has changed, it is up to you to support that allegation.

-Jim

---

From: "John L" <[email-masked]>
Date: 16 Jan 2008 19:47:47 -0500

>> How does an SSP-like protocol do that?  Assertions like "I am a phish

Because you (the generic you, whoever publishes SSP) aren't credible short 
of some reputation system which would make SSP irrelevant anyway.

It's fine to make statements about your own practices, like "I sign 
everything" or "All of my mail is composed in iambic pentameter" since 
that reflects things you have control over.  Claiming you're a phish 
target is making assertions about the behaviors of zillions of other 
senders who you don't even know.

R's,
John

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 17 Jan 2008 01:49:07 +0100

Jim Fenton wrote:
 
 [Tracing SSP's paradigm change]
> I have asked you more than once to cite the basis for the alleged
> change, such as text from a previous draft describing this "simple
> idea".  I have not received a response; since you are alleging 

<http://en.wikipedia.org/w/index.php?title=Sender_Signing_Policy&action=history> 
indicates that nothing changed since 2006-03 as far as I understood
it at this time, including the point that I didn't like From idea :-)

---

From: Jon Callas <[email-masked]>
Date: Wed, 16 Jan 2008 16:52:03 -0800

> it doesn't track to anything actionable.

I think we should fall back to a minimal SSP that contains only the "I- 
SIGN-ALL" policy, and we let the real-world deployment and desires for  
additions control more in SSP than that. SSP2 can start in a year or  
two, and then we see what is needed in the real world. We can even  
have experimental things in the field to test them.

	Jon

---

From: "John L" <[email-masked]>
Date: 16 Jan 2008 19:53:29 -0500

Just to make sure I don't misunderstand anything, let's assume that 
visasecurity.net doesn't publish any SSP, either because it doesn't exist 
(its current state) or it's registered as a throwawy by someone who 
doesn't publish any DNS records.

Then these headers are SSP compliant and not Suspicious, regardless of 
anything that paypal.com publishes, right?

  From: visasecurity.net (Visa Security), [email-masked] (Paypal Security)
  Sender: [email-masked]
  Subject: An Urgent Message from Your Friends at Paypal and Visa

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Wed, 16 Jan 2008 16:54:13 -0800

> what is lost through utilization of the Sender header in at least some 
Good idea, Arvel.

Suppose that an attacker wanted to spoof a message from the domain 
statements.bigbank.com, a domain having a Strict Sender Signing Practice 
that is used for transactional email.  Attacker sends the following message:

Date: Wed, 16 Jan 2008 15:49:44 -0600
From: BigBank Statements <[email-masked]>, BigBank Security <[email-masked]>
To: John Doe <jdoe@...>
Subject: Account alert
Sender: [email-masked]

As currently composed, this message would not be SSP compliant because 
the SSP retrieved would be that of statements.bigbank.com (Strict) and 
the attacker would not have the ability to create a valid signature for 
that domain.

Now suppose that the Sender header field is used for the SSP lookup.  
Since example.com doesn't have an SSP record, it would be Unknown and 
this spoofed message would be SSP compliant.  Depending on the MUA being 
used, the recipient of the message is likely not to notice that there is 
a Sender: header field at all.

It has been argued that, since this working group (and perhaps all of 
IETF) doesn't have expertise in UI design, the MUA should not be 
considered at all.  While I agree that IETF probably shouldn't be 
designing user interfaces, I believe that it is entirely reasonable for 
us to make design decisions based on observation of the way that 
existing user interfaces do behave.  Not to do so results in protocols 
that are irrelevant because they don't solve real world problems.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Wed, 16 Jan 2008 16:56:14 -0800

Michael Thomas wrote:
> RFC 5016 doesn't say anything about the role of the SSP client. 

What is an "SSP client"?

d/
-- 

   Dave Crocker

---

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

> requirements statements in section 5.

Are you saying that the Introduction's statement is wrong?

d/

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Wed, 16 Jan 2008 16:59:10 -0800

>> RFC 5016 doesn't say anything about the role of the SSP client. 

Something that initiates the SSP protocol.

	Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 16 Jan 2008 17:04:43 -0800

Jon Callas wrote:
> I think we should fall back to a minimal SSP that contains only the 
> "I-SIGN-ALL" policy, and we let the real-world deployment and desires 
> for additions control more in SSP than that. SSP2 can start in a year or 
> two, and then we see what is needed in the real world. We can even have 
> experimental things in the field to test them.

At least this is headed in the direction of action, but I really don't
see this relates to your previous +1. Or is not supposed to?

I've just been re-reading the current draft to implement it, and I have
to say that it's pretty bare bones, even though I have problems with
some of it too (and have opened issues against those problems). Part of
what seems to be going on here is that people are reacting to the
threads -- strawman and all -- and not the actual draft.

	Mike

---

From: Dave Crocker <[email-masked]>
Date: Wed, 16 Jan 2008 16:57:26 -0800

> Even if it isn't, we'll need a clearer answer for all the people who

"DKIM and SSP are for filtering engines, not the recipient's MUA."

d/
-- 

   Dave Crocker

---

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

> Something that initiates the SSP protocol.

So, the sysadmin who creates the SSP DNS record?

How does this relate to the original reference to an MUA?

d/

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Wed, 16 Jan 2008 17:13:22 -0800

> How does this relate to the original reference to an MUA?

Dave, this is hardly rocket science. Is an SMTP client similarly
confusing?

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 16 Jan 2008 17:21:00 -0800

> "DKIM and SSP are for filtering engines, not the recipient's MUA."

The fallacy here is that an MUA and a filtering engine cannot
coexist. Which of course they do all the time.

Where is this quote from? It needs to be fixed.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Wed, 16 Jan 2008 17:28:36 -0800

> Dave, this is hardly rocket science. Is an SMTP client similarly

Mike, you are missing some rather basic differences.

SMTP defines the construct of 'client' explicitly.  SSP does not.

In addition, SMTP is a real-time exchange protocol and SSP is not. For that 
matter, SSP is a very unusual style of "protocol" and so the client-server 
construct does not have obvious application.  I don't mean it can't be applied 
but, as I said, the application isn't obvious.

In any event, I'm still not seeing how any of this relates to the original 
reference to an MUA.

d/

-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Wed, 16 Jan 2008 17:30:14 -0800

> coexist. Which of course they do all the time.

There is no statement that they cannot co-exist, so it's probably better not 
to assert that such a statement is false.

The statement is that SSP is intended for processing by a filtering engine and 
that it has no direct MUA-related intent.

> Where is this quote from? It needs to be fixed.

I invented it, in response to the "we'll need a clearer answer" preceding it.

d/
-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Wed, 16 Jan 2008 17:56:01 -0800

Dave Crocker wrote:
> There is no statement that they cannot co-exist, so it's probably better 
> not to assert that such a statement is false.
> 
> The statement is that SSP is intended for processing by a filtering 
> engine and that it has no direct MUA-related intent.

   I'm pretty sure this a game of gotcha, but opposing "filtering
   engine" and "MUA" in the above construct implies that they are
   two disjoint categories. They aren't, and thus your construction
   falls into the false dilemma fallacy, I'm pretty sure. Also: MUA's and
   their considerations are not outside of our charter, and it's
   perfectly reasonable to bring up issues that may help MUA developers
   use DKIM and SSP. It's also yet another false dilemma to say that
   MUA's are the same thing as their UI's or even worse their human
   interface considerations (which a MUA may or may not even possess).
   It would be helpful to not keep making these errors of composition.

		Mike

---

From: Douglas Otis <[email-masked]>
Date: Wed, 16 Jan 2008 14:37:03 -0800

On Jan 16, 2008, at 1:49 PM, Arvel Hathcock wrote:

> The debate here is whether or not it's mission-critical for SSP to  
> use From: in all cases or whether some other sender identity (like  
> Sender: header) could be used to equal effect generally or in  
> specific cases (like when there are multiple addresses in From).

There should _not_ be a restriction on who the signature is on-behalf- 
of, be it "Sender", "second author" or "opaque identity".  A signature  
of the "first author's" domain should be the only requirement for  
compliance with "strict" and "all".  This is not how SSP is currently  
defined.

The only exception might be for g= restricted keys, where the  
signature must be on-behalf-of the "first author" to offer "strict" or  
"all" compliance.  This is not how SSP is currently defined either.

> Given that it would solve the problem described in 1525 and also  
> bring us closer to a consensus position perhaps this thread should  
> discuss what is lost through utilization of the Sender header in at  
> least some cases.

Nothing is lost when just the _domain_ of the signature is  
significant.  DKIM/SSP is not about identifying individuals.  DKIM/SSP  
is about deciding whether a message contains a compliant signature.

The DKIM signature can indicate which identity it is on-behalf-of.  In  
this regard "first author" is not sacrosanct as it could be for _any_  
identity.

>> an unsigned message should have been signed, it has morphed into an  
>> effort to validate the From field.  That is a very, very different  
>> goal. While DKIM has the goal of assigning *any* identity to a  
>> message, so that that identity can be assessed, the current work on  
>> SSP is attempting to instead validate authorship.

I am in complete agreement with this statement.

>> For the purposes of ensuring the presence of any valid identity,  
>> using the Sender: field is just as acceptable as From:.  It also  
>> has the appeal of being far simpler and, by the way, supporting a  
>> wider range of legitimate usage scenarios. Rather than deal with  
>> the problems caused by rigidly insisting on using the author  
>> string, you seem intent on ignoring the feedback about those  
>> problems and the remarkably simple and useful suggestion to switch  
>> to the Sender: field. But, then, this focus on using author  
>> information goes back to a belief that SSP can somehow be useful  
>> directly to end-users, in spite of there being no empirical basis  
>> for believing this and plenty of empirical basis for knowing that  
>> it will be trivial for bad actors to bypass this bit of "protection".

Agreed.  When a signature is not found, there was agreement that the  
domain within the email-address contained within the From header  
establishes policy.  Using the domain of the first email-address made  
good sense.  I agree a signature should be able to be on-behalf-of  
"Sender", "second author" or for that matter an opaque identity within  
the i= parameter and not associate with any header.  When the policy  
for "first author's" domain indicates "all" or "strict", the only  
requirement this should establish is a signature by the "first  
author's" domain on-behalf-of _any_ identity.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Wed, 16 Jan 2008 18:25:23 -0800

Michael Thomas wrote:
>> There is no statement that they cannot co-exist, so it's probably 
>> better not to assert that such a statement is false.
>>

I don't know what you are playing but all I'm trying to do is a) understand 
what was originally meant and b) make sure we use terminology carefully and 
describes needs and functions precisely.

>   two disjoint categories. They aren't, and thus your construction

Oh.  Well they are in fact entirely disjoint, except to the extent that an MUA 
might contain a filtering engine.  I'd be glad to explain the fundamental 
differences -- they are legion or, at least, considerable.

>   their considerations are not outside of our charter, and it's

Yeah, they are.  They are not explicitly excluded, in the charter next -- nor 
are they included -- but they are most certainly outside the competence of 
this group.  And I thought this had been demonstrated sufficiently many times 
in the past.

To the extent that one more time is needed, feel free to move from the 
'concept' of MUAs being relevant to the work and discuss particulars.

>   use DKIM and SSP. It's also yet another false dilemma to say that

It is always reasonable to bring up issues that may help any developer.  I 
haven't seen that happening here, but no, it's certainly not excluded. 
However I'll ask how this is in any way relevant to the original reference, 

-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Wed, 16 Jan 2008 18:32:33 -0800

d/(sorry.  somehow clicked send rather than paste...)

Michael Thomas wrote:
> Dave Crocker wrote:
>> Michael Thomas wrote: There is no statement that they cannot co-exist, so
>>  it's probably better not to assert that such a statement is false.
>> 

I speak for your goals, but all I'm trying to do is a) understand what was
originally meant and b) make sure we use terminology carefully and describes
needs and functions precisely.

> engine" and "MUA" in the above construct implies that they are two disjoint
>  categories. They aren't, and thus your construction

Oh.  Well they are in fact entirely disjoint, except to the extent that an MUA
might contain a filtering engine.

I'd be glad to explain the fundamental differences -- they are legion or, at
least, considerable.

this group.

And I thought this had been demonstrated sufficiently many times in the past.

To the extent that one more time is needed, feel free to move from the
'concept' of MUAs being relevant to the actual work of attempting to make them
relevant, by discussing particulars.

> perfectly reasonable to bring up issues that may help MUA developers use 
> DKIM and SSP. It's also yet another false dilemma to say that

It is always reasonable to bring up issues that may help any developer.  I
haven't seen that happening here, but no, it's certainly not excluded.
However I'll ask how this is meaningfully relevant to the original reference,
which I'll re-cite, since I suspect most folks have forgotten:

>> I think I am missing something DKIM base crypto claiming responsibility 
>> of the singing domain
>> 
>> ASP Authors signing policy who is not clearly a sender or a member of the
>>  signing domain but wants to assert a policy anyway
>> 
>> Am I correctly framing the thread? thanks, Bill

We have repeatedly demonstrated that this working group is not in a position
to give guidance about 'how to reliably display something useful' about
SSP-related information.

> MUA's are the same thing as their UI's or even worse their human interface
>  considerations (which a MUA may or may not even possess). It would be 
> helpful to not keep making these errors of composition.

I've no idea what errors you are referring to, but for reference a UI is
merely a component of an MUA.

By human interface considerations I assume you mean the User Centered Design
or Activities Based Design factors or the like that affect a user's cognitive
processes while attempting to get work done with the MUA?

d/

-- 

   Dave Crocker

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 17 Jan 2008 01:18:54 +0100

Michael Thomas wrote:

> Can anybody describe what benefit SSP would give if it chose some
> other address? Other than supposedly genuflecting to RFC2822?

I thought I've done this often enough, but maybe it wasn't clear:

  From: [email-masked]
  Sender: [email-masked]

This is a valid scenario, where you used your favourite address
[email-masked] as From, protected by a strict SSP in the
an.example domain.  For reasons that are nobody's business but
your own you submitted the mail at an MSA of elsewhere.example,
and this MSA added your Sender address, implementing RFC 4409 8.1.

The unsigned (or at least not signed by an.example) mail arrives
at Alice's ssp.checker.example MTA, and for some reasons of its
own it accepts your strictly failing mail as "suspicious", ending
up in Alice's "suspicious" folder.  She's used to ignore mails in
this folder because it's almost always spam, and after some days
your mail is purged => legit mail lost.  Neither your nor Alice's
fault, also not the fault of 2822upd or 4409.  It's SSP's fault.

Scott's argument that Alice's MUA would display From: strictly.you
for the same scenario with a malicious sender doesn't convince me:
She'd be in serious trouble if she trusts that a From header means
what it says in 2008, SSP can't rescue her from this bad idea.

MUAs trying to be smart will anyway have to learn new tricks, they
are not forced to display only the From and nothing else, they can
add a smiley for some Authentication-Results "PASS" or whatever.

 Frank

---

From: Douglas Otis <[email-masked]>
Date: Wed, 16 Jan 2008 18:58:23 -0800

On Jan 16, 2008, at 4:54 PM, Jim Fenton wrote:

> statements.bigbank.com, a domain having a Strict Sender Signing  
> Practice that is used for transactional email.  Attacker sends the  
> following message:
>
> From: BigBank Statements <[email-masked]>,  
> BigBank Security <[email-masked]>
> To: John Doe <jdoe@...>
> Subject: Account alert
> Sender: [email-masked]
>
>
> As currently composed, this message would not be SSP compliant  
> because the SSP retrieved would be that of statements.bigbank.com  
> (Strict) and the attacker would not have the ability to create a  
> valid signature for that domain.
>
> Now suppose that the Sender header field is used for the SSP  
> lookup.  Since example.com doesn't have an SSP record, it would be  
> Unknown and this spoofed message would be SSP compliant.  Depending  
> on the MUA being used, the recipient of the message is likely not to  
> notice that there is a Sender: header field at all.

As SSP is currently defined, the signature must be on-behalf-of the  
"first author"!  This should change to indicate that the "first  
author" domain establishes SSP and that compliance with SSP "strict"  
or "all" only requires a signature be by the "first author" domain.   
Compliance should not require a signature be on-behalf-of the "first  
author" via the i= parameter.  This is a mistake SSP is currently  
making.

Correcting this mistake would permit the "first author" domain to sign  
just the Sender header or even no header at all!  The MUA might  
display the From header, but because the "first author" domain had  
signed the message, the message MUST BE compliant with the "first  
author" domain's signing policies!!!!

One must assume the "first author" domain will control access to their  
outbound servers.  After all, the "first author" domain is who signs  
the message, and not the "first author" as you seem to suggest.  This  
might be true only with restricted keys.

> It has been argued that, since this working group (and perhaps all  
> of IETF) doesn't have expertise in UI design, the MUA should not be  
> designing user interfaces, I believe that it is entirely reasonable  
> for us to make design decisions based on observation of the way that  
> existing user interfaces do behave.  Not to do so results in  
> protocols that are irrelevant because they don't solve real world  
> problems.

Yes, but you are adding a condition requiring signatures be on-behalf- 
of the "first author" even when they are not!.  While MUAs might be  
able to indicate a message has a valid/compliant DKIM signature, this  
information only conveys the message was introduced by the signing  
domain.  A message signed by DKIM says _nothing_ about the identity of  
the author.  The MUA might wish to highlight which entity the  
signature was on-behalf-of, but this gets rather complex when there  
are more than one signature involved.  The DKIM charter makes it clear  
this protocol is _not_ to identify the author.  DKIM is to _only_  
identify the domain.  Identifying the domain is plenty.

Instruct recipients to check the domain of the "first author" to know  
which domain established compliance.  Perhaps the compliant on-behalf- 
of header should be highlighted as well. Happy?

Your approach will cause valid messages signed on-behalf-of the Sender  
header to be rejected or require falsification of the on-behalf-of  
information.  Your approach requires something to be lost!

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Wed, 16 Jan 2008 22:24:49 -0800

John L wrote:
> Because you (the generic you, whoever publishes SSP) aren't credible 
> short of some reputation system which would make SSP irrelevant anyway.

Depends on the nature of the assertion.  If the assertion is "I'm a good 
guy" or "I send virus-free messages" the receiver isn't likely to 
believe me.  If the assertion is "Be very careful about messages coming 
from my domain", why shouldn't the receiver pay attention to that?
> senders who you don't even know.

With respect to a domain likely to use SSP (such as a domain used only 
for transactional messages), who are these zillions of other senders, 
and why should that domain be concerned about them?

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Wed, 16 Jan 2008 22:37:08 -0800

John L wrote:
> visasecurity.net doesn't publish any SSP, either because it doesn't 
> exist (its current state) or it's registered as a throwawy by someone 
> who doesn't publish any DNS records.
>

(assuming you mean [email-masked] instead of just 
visasecurity.net)

If visasecurity.net does not exist, the message is not SSP compliant (is 
Suspicious) because it fails the domain existence test.

But yes, if it is registered as a throwaway and doesn't publish SSP, it 
will be SSP compliant (not Suspicious), presuming some DNS record for 
the domain exists (at least an NS record or something).  Hopefully Visa 
has engaged the use of a domain registration monitoring service to 
protect against this.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Wed, 16 Jan 2008 22:56:03 -0800

> fault, also not the fault of 2822upd or 4409.  It's SSP's fault.

I have limited sympathy for "you" (not you, Frank).  You submitted a 
message contrary to the published SSP, and it did its job.  I count this 
is a success.

-Jim

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 17 Jan 2008 12:00:27 -0000

> Let's design SSP for the real world.

-1

The Real World is full of Bad Guys. Currently, multiple From addresses are  
rare, but if the Bad Guys discover that using multiple From addresses  
suits their ends then they will suddenly become quite common.

I am worried about that 'visasecuriy' example. I don't think it exposed a  
loophole as it stood, but I am very worried that something similar might  
let the Bad Guys through. We need to be thinking about that.

---

From: John L <[email-masked]>
Date: Thu, 17 Jan 2008 07:54:28 -0500 (EST)

> Depends on the nature of the assertion.  If the assertion is "I'm a good guy" 
> or "I send virus-free messages" the receiver isn't likely to believe me.  If 
> the assertion is "Be very careful about messages coming from my domain", why 
> shouldn't the receiver pay attention to that?

Because, as I said in my previous message, you are making assertions about 
the behavior of people you don't know or control.

> With respect to a domain likely to use SSP (such as a domain used only for 
> transactional messages), who are these zillions of other senders, and why 
> should that domain be concerned about them?

I was under the impression that SSP was intended to deter unrelated 
senders from sending mail with your domain in the From: line, on the 
theory that such messages might be forgeries.  Are you saying it's for 
something else?

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Thu, 17 Jan 2008 14:04:48 +0100

Charles Lindsey wrote:
>
> -1
>
> The Real World is full of Bad Guys. Currently, multiple From addresses 
> are rare, but if the Bad Guys discover that using multiple From 
> addresses suits their ends then they will suddenly become quite common.

You're right, and so we must fail safe.  Which means that your -1 should 
really be a +1.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 17 Jan 2008 15:15:15 +0100

John L wrote:
> As I think has been hashed out before, it's utterly impossible to keep 
> people from creating lookalike domains.

And as I think has been hashed out before, if we attempt to boil the 
ocean, which is what you're suggesting, we will fail.  There are CLEARLY 
UI issues for which the UI will need to take responsibility.  The 
alternative is to throw the baby out with the bath water, because simply 
SOMEONE taking responsibility for the message mandates the need to 
establish reputation of that someone, and there is no proposal on the 
table that is incrementally deployable to that end.

Eliot

---

From: John L <[email-masked]>
Date: Thu, 17 Jan 2008 09:32:42 -0500 (EST)

> And as I think has been hashed out before, if we attempt to boil the ocean, 
> which is what you're suggesting, we will fail.

Actually, all I was going to suggest was that if SSP purports to manage 
addresses on the From: line, it should manage all of them rather than 
arbitrarily giving N-1 of them a free pass.

> because simply SOMEONE taking responsibility for the message mandates 
> the need to establish reputation of that someone

Indeed.  Does this mean you agree that SSP only applies to unsigned 
messages?  (Actual non-rhetorical question.)

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Thu, 17 Jan 2008 15:41:31 +0100

John L wrote:
>>> As I think has been hashed out before, it's utterly impossible to 
>>> keep people from creating lookalike domains.
>>
>> ocean, which is what you're suggesting, we will fail.
>
> Actually, all I was going to suggest was that if SSP purports to 
> manage addresses on the From: line, it should manage all of them 
> rather than arbitrarily giving N-1 of them a free pass.

Ah.  I see.  So you would require N DKIM signatures (where N is the 
number of domains found)?

> messages?  (Actual non-rhetorical question.)

No, because I make a distinction between just anyone and the person(s) 
in the From line.  I view it as a starting point from which perhaps UI 
folk can make some headway.  I think they'll need to do other things, of 
course.  I agree with you that the display name is what gets shown 
today, and I'm not certain what to do about it, but we need to be 
careful not to leave gaping holes.

But all of this being said, you said you were about to propose 
protecting all addresses in entire From: line.  I think that would be a 
great idea.  Why not send text, being mindful that we have to be careful 
of potential reflection attacks through this mechanism?

Eliot

Eliot

---

From: John L <[email-masked]>
Date: Thu, 17 Jan 2008 09:56:41 -0500 (EST)

> Ah.  I see.  So you would require N DKIM signatures (where N is the number of 
> domains found)?

If all of the domains publish SSP saying they sign all their mail, sure. 
What else would make sense?

> But all of this being said, you said you were about to propose protecting all 
> addresses in entire From: line.  I think that would be a great idea.  Why not 
> send text, being mindful that we have to be careful of potential reflection 
> attacks through this mechanism?

Reflection attacks?  How would a few TXT queries make that happen?

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Thu, 17 Jan 2008 16:00:06 +0100

> Reflection attacks?  How would a few TXT queries make that happen?

It would be the queries themselves I would be worried about.  Suppose 
someone blasts a message to thousands of domains that has many addresses 
in the From: line.  All of sudden all of those domains are under attack.

Perhaps some careful wording about how this is handled can get us around 
that?  I don't know.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John L <[email-masked]>
Date: Thu, 17 Jan 2008 10:11:40 -0500 (EST)

> It would be the queries themselves I would be worried about.  Suppose someone 
> blasts a message to thousands of domains that has many addresses in the From: 
> line.  All of sudden all of those domains are under attack.

Considering all of the other ways that an e-mail message can provoke DNS 
queries, this doesn't strike me as a particularly worrisome issue.  How is 
this any different from a bad guy who puts a bunch of fake DKIM signatures 
on the message?

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Thu, 17 Jan 2008 07:28:17 -0800

> Perhaps some careful wording about how this is handled can get us around 

You know, I really wonder whether this is a mole hill sized mountain.
I wonder how long it would take for spam filter writers to notice this
kind of attack and write a new rule to send them to the bit bucket. A
week? Less? Not to mention that Baysian filtering would glom onto it
even faster.

		Mike

---

From: Eliot Lear <[email-masked]>
Date: Thu, 17 Jan 2008 16:33:20 +0100

Michael Thomas wrote:
>> someone blasts a message to thousands of domains that has many 
>> addresses in the From: line.  All of sudden all of those domains are 
>> under attack.
>>
>> Perhaps some careful wording about how this is handled can get us 
>> around that?  I don't know.
>

Ok, perhaps it's nothing.  It did occur to me as a potential attack.  
Perhaps worth adding a line in Security Considerations?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Thu, 17 Jan 2008 07:42:05 -0800

> Perhaps worth adding a line in Security Considerations?

Is there an open issue about this? If there is, can I propose that we:

1) consider all addresses in the From: address up to some arbitrary
    limit in which case the message is suspicious
2) write a security consideration mentioning the reflection attack, and
    the likely mitigation that filtering software should view this as
    out of the ordinary

		Mike

---

From: Eliot Lear <[email-masked]>
Date: Thu, 17 Jan 2008 16:45:23 +0100

I was viewing this as a resolution to 1525...

Michael Thomas wrote:
>>>> It would be the queries themselves I would be worried about.  
>>>> Suppose someone blasts a message to thousands of domains that has 
>>>> many addresses in the From: line.  All of sudden all of those 
>>>> domains are under attack.
>>>>

---

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

John L wrote:
> [ corrected example ]
>
>>>  From: [email-masked] (Visa Security), [email-masked] 
>>> (Paypal Security)
>> But yes, if it is registered as a throwaway and doesn't publish SSP,
>> it will be SSP compliant (not Suspicious), presuming some DNS record
>> for the domain exists (at least an NS record or something).
>> Hopefully Visa has engaged the use of a domain registration
>> monitoring service to protect against this.
>
> people from creating lookalike domains.  A couple of days ago, I made 
> the lists below of several thousand .COM domains that do and do not 
> belong to the Bank of America.  These are just in .COM; I didn't 
> bother to look in .NET or .ORG or .BIZ or .INFO or any of the hundreds 
> of ccTLDs.
>
> We all knew already that SSP doesn't do anything about phishing from 
> lookalike domains.  But the first From: address rule means that SSP is 
> also trivially defeated for mail with the exact domain in the From: line.
>
The alternative, then, is to lookup SSP based on all domains that appear 
in the From: line?  If that is what you're proposing, let's discuss it.  
The alternative that is on the table (use of Sender), however, means 
that SSP is also trivially defeated through the use of a domain that 
isn't on the From: line at all.

Yes, the lookalike domain thing has been hashed out before, from the 
chartering of this WG, and in fact you own examp1e.com as a "souvenir" 
of one such discussion.  I don't know why we can't move past that.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Thu, 17 Jan 2008 09:26:53 -0800

John L wrote:
>> Depends on the nature of the assertion.  If the assertion is "I'm a 
>> good guy" or "I send virus-free messages" the receiver isn't likely 
>> to believe me.  If the assertion is "Be very careful about messages 
>> coming from my domain", why shouldn't the receiver pay attention to 
>> that?
>
> Because, as I said in my previous message, you are making assertions 
> about the behavior of people you don't know or control.
>
>> With respect to a domain likely to use SSP (such as a domain used 
>> only for transactional messages), who are these zillions of other 
>> senders, and why should that domain be concerned about them?
>

Oh, you mean that I might assert "I'm a phishing target" when in fact 
I'm not.  In any case, nobody is proposing that assertion (nor the 
iambic pentameter one, either).  My point is that there are different 
sorts of assertions:  those suggesting that the receiver apply more 
scrutiny to messages from my domain are likely to be believable even if 
self-asserted, and those suggesting that the sender is a good guy are 
only useful if coming from an accreditor or reputation system the 
receiver trusts.

-Jim

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 17 Jan 2008 11:38:55 -0600

Hi Jim!

Yes, but suppose that the Sender header were used only when the domain 
found therein matched one of those in the From.  Then it would 
disambiguate the process allowing SSP to know precisely which of the 
multiple domains involved in authorship purports to be that which posts 
the message to the mail stream.

This would not help in cases where the Sender: domain is entirely 
different from any found in the From: but at least it would address the 
root concern found in issue 1525.  That is, it could no longer be said 
that SSP requires the first author to be the poster (which is the meat 
of issue 1525) and this issue could perhaps be closed?

Cases in which there are multiple addresses in the From: and no Sender: 
are inconsistent with standardized practice and the spec could handle 
those just as it would messages that have no From: header at all.  I 
don't know.

Arvel

Jim Fenton wrote:
> From: BigBank Statements <[email-masked]>, BigBank 
> Security <[email-masked]>
> To: John Doe <jdoe@...>
> Subject: Account alert
> Sender: [email-masked]
> 
> 
>

---

From: Douglas Otis <[email-masked]>
Date: Thu, 17 Jan 2008 09:44:42 -0800

On Jan 17, 2008, at 5:04 AM, John L wrote:

>> But yes, if it is registered as a throwaway and doesn't publish  
>> SSP, it will be SSP compliant (not Suspicious), presuming some DNS  
>> record for the domain exists (at least an NS record or something).  
> keep people from creating lookalike domains.  A couple of days ago,  
> I made the lists below of several thousand .COM domains that do and  
> do not belong to the Bank of America.  These are just in .COM; I  
> didn't bother to look in .NET or .ORG or .BIZ or .INFO or any of the  
> hundreds of ccTLDs.
>
> lookalike domains.  But the first From: address rule means that SSP  
> is also trivially defeated for mail with the exact domain in the  
> From: line.

John's concern is that people will pay attention to _any_ recognizable  
 From email address, rather than just the first email address.  This  
concern should be weighed against the how multiple addresses might be  
used, and what a recipient would be able conclude from a DKIM signed  
indication.  Multiple addresses might become legitimately more common  
due to Email Address Internationalization (EAI).  So allowing policy  
to be established by a list of From email-addresses means the overhead  
related to discovering policy needs to be multiplied by some factor of  
2 or 3.  SSP must avoid the mistake made by SPF expanding macros  
embedded within the RR.  Macros would mean subsequent transactions  
permit an attack without expending resources of the attacker.  Such a  
scheme would be fundamentally flawed.  Make a statement that an MX  
record must be published by a domain wishing to establish policy.   
Eventually this needs to happen when SLDs start getting hammered.

Adding more DNS overhead to processing of DKIM might cause fewer  
receivers to implement DKIM.  A good trade-off would be to educate  
recipients that only the first email-address seen within the From  
header is protected by DKIM SSP policy.  The "first-author" convention  
makes it easier for recipients to understand which domain governs DKIM  
signature compliance.  Of course, DKIM is not about identifying any  
specific author of the message.  Adding another From email-address to  
the mix does not represent a concern about muddling the identity of  
the author.

Checking SSP policies of all domains within the From header would be a  
possible approach.

Cautions that might be added would be:

- Don't use macros

- Require publication of MX records (get the ball rolling to protect  
SLDs)

- Allow unrestricted keys to sign any identity (allow domains to  
decide what identity they wish to sign on-behalf-of)

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Thu, 17 Jan 2008 09:45:13 -0800

> have experimental things in the field to test them.

That's a suggestion in a different direction (issue #1520).  The issue 
here is how we obtain the policy, be it the minimal "I-SIGN-ALL" that 
you advocate or the richer policy that is in the current draft.  Is it 
queried based on the [first] author's domain, the authors' domain(s), or 
the sender's domain?

-Jim

---

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

Arvel Hathcock wrote:
> found therein matched one of those in the From.  
...
> root concern found in issue 1525.  

Within the strict confines of what the current SSP specification is trying to 
do, I am sorry to say that I actually think this is the best approach and any 
proposed so far.

It is simple to understand and it eliminates the restriction on which of the 
authors may post the message.

I say "sorry" because overall it's pretty awkward, but I think the nature of 
what the current SSP is trying to do mandates awkwardness.

d/
-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Thu, 17 Jan 2008 10:02:31 -0800

On Jan 17, 2008, at 9:55 AM, Dave Crocker wrote:

>
>
> Arvel Hathcock wrote:
>> Yes, but suppose that the Sender header were used only when the  
>> domain found therein matched one of those in the From.
> ...
>> different from any found in the From: but at least it would address  
>> the root concern found in issue 1525.
>
>
> Within the strict confines of what the current SSP specification is  
> trying to do, I am sorry to say that I actually think this is the  
> best approach and any proposed so far.
>
> It is simple to understand and it eliminates the restriction on  
> which of the authors may post the message.
>
> I say "sorry" because overall it's pretty awkward, but I think the  
> nature of what the current SSP is trying to do mandates awkwardness.

+1

-Doug

---

From: "John L" <[email-masked]>
Date: 17 Jan 2008 13:12:47 -0500

> My point is that there are different sorts of assertions:  those 
> suggesting that the receiver apply more scrutiny to messages from my 
> domain are likely to be believable even if self-asserted,

Why? I see no reason to assume this is true.

The only practical evidence we have is that Paypal has told people through 
informal channels that they sign everything and it's OK with them to 
discard unsigned mail, but we already knew they're the biggest phishing 
target around.

My expectation is that a large majority of domains that would publish 
strict SSP policies would be small mail systems with no more forgery 
problems than anyone else, but an exaggerated idea of their own 
importance.  Sort of like the people who send you mail, then demand you 
jump through C/R hoops when you respond to it.

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Thu, 17 Jan 2008 19:26:17 +0100

> I'd really have to ask myself what we are trying to accomplish.

We've closed an avenue of attack.  It's up to UI designers to close 
other avenues.

Eliot

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 17 Jan 2008 13:32:05 -0500

> jump through C/R hoops when you respond to it.
And I wouldn't waste any more sleep over not getting mail because of 
uninformed publishing of a strict SSP record than I would about that.

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Thu, 17 Jan 2008 10:33:09 -0800

John L wrote:
> importance.  

I'm sorry, but is it just your peevishness about their perceived
self-importance? What difference does it make if they aren't as
important as they think they are? How is that negatively affecting
you?

		Mike

---

From: <[email-masked]>
Date: Thu, 17 Jan 2008 14:21:13 -0500

When a message is received the only thing we truly can determine is the
IP it came from (in most cases)no matter what authority or ruleset that
subsequent headers assert. Now DKIM asserts responsibility for signing
but may not be the sender. Perhaps SSP should be asserted by the signing
domain so responsibility can be narrowed to a single party. I see a lot
of DKIM spam in the wild so we will have to ascertain
reputation/accreditation regardless but at least we will have an entity
of some sort to assign responsibility to. Highly phished sites will have
look-a-like issues regardless of what we assign as determinate SSP
lookup headers.

Thanks,
Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jim Fenton
Sent: Thursday, January 17, 2008 12:45 PM
To: Jon Callas
Cc: [email-masked]
Subject: Re: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by
firstAuthor breaks email semantics

> I think we should fall back to a minimal SSP that contains only the
"I-

the sender's domain?

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Thu, 17 Jan 2008 11:33:05 -0800

Arvel Hathcock wrote:
> multiple domains involved in authorship purports to be that which 
> posts the message to the mail stream.
>
> the root concern found in issue 1525.  That is, it could no longer be 
> said that SSP requires the first author to be the poster (which is the 
> meat of issue 1525) and this issue could perhaps be closed?

But we have to handle the case where the Sender: domain is entirely 
different as well.  We can't just be silent on this case.

The choice of first From: domain is, as the draft notes, a largely 
arbitrary one.  I don't have a problem with using all of the domains in 
the From: header field, other than whether we need to impose an 
artificial limit on how many SSP lookups per message we do, and how to 
handle the case where that is succeeded.

I do have a problem with just using Sender in the multiple From case.  
Sender has different semantics than From, so using From under some 
circumstances and Sender under other circumstances does "break" the 
semantics defined in RFC 2822.

>
> Cases in which there are multiple addresses in the From: and no 
> Sender: are inconsistent with standardized practice and the spec could 
> handle those just as it would messages that have no From: header at 
> all.  I don't know.

I'm not worried about what we do with messages that violate 2822.  But I 
do want to make sure that we cover all the cases that are legal.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Thu, 17 Jan 2008 11:40:33 -0800

SSP is trying to provide information in the absence of a valid signature 
from the author.

No signature -> no signing domain.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Thu, 17 Jan 2008 11:45:48 -0800

On Jan 17, 2008, at 11:33 AM, Jim Fenton wrote:

>> domain found therein matched one of those in the From.  Then it  
>> would disambiguate the process allowing SSP to know precisely which  
>> of the multiple domains involved in authorship purports to be that  
>> which posts the message to the mail stream.
>>
>> the root concern found in issue 1525.  That is, it could no longer  
>> be said that SSP requires the first author to be the poster (which  
>> is the meat of issue 1525) and this issue could perhaps be closed?
>

The requirement would be the Sender headers email-address domain must  
be at or above the From email-address domain's policy to be compliant  
with "all" or "strict".  This is not being silent.

> arbitrary one.  I don't have a problem with using all of the domains  
> in the From: header field, other than whether we need to impose an  
> artificial limit on how many SSP lookups per message we do, and how  
> to handle the case where that is succeeded.
>
> I do have a problem with just using Sender in the multiple From  
> case.  Sender has different semantics than From, so using From under  
> some circumstances and Sender under other circumstances does "break"  
> the semantics defined in RFC 2822.

Agreed.  Having the Sender domain impose policy would be problematic.

>> Sender: are inconsistent with standardized practice and the spec  
>> could handle those just as it would messages that have no From:  
>> header at all.  I don't know.
>
> I'm not worried about what we do with messages that violate 2822.   
> But I do want to make sure that we cover all the cases that are legal.

By only using the From domain(s) to establish policy, the MTA is free  
to decide about these types of RFC errors.  IMHO, the identity within  
the i= parameter does not need to associate with any header.  When the  
key is unrestricted, the only significant element with respect to  
compliance would be the d= parameter of the signature.

-Doug

---

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

> From: [email-masked]
> To: [email-masked]
> Subject: Re: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by first	Author breaks email semantics
> Date: Wed, 16 Jan 2008 16:52:03 -0800
> CC: [email-masked]; [email-masked]
> 

I don't think I'd have a problem with only have a "I sign everything" policy. I think the bigger issue is, as a verifier, who is the "I" who I should be looking for that assertion from when I have an unsigned message. The options appear to be, check the domain of the Sender, check the domain of the first address in the From: (the currently defined behavior), or check all addresses  in the From: .

My personal preference would be the latter for the entirely selfish reason that, if any domains can make that assertion it immediately becomes useful. The same does not appear to me (at least yet) to be true for the Sender.

Robert

> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Universal 2.6.3
> Charset: US-ASCII
> 
> wj8DBQFHjqa2sTedWZOD3gYRAoZhAKCCalYvImeJrhB07fv6jS59s8l3LACeM7TS
> v7K/BLZqwg76skcocMPmaUk=
> =LHa/
> -----END PGP SIGNATURE-----

_________________________________________________________________
Helping your favorite cause is as easy as instant messaging.  You IM, we give.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join

---

From: Dave Crocker <[email-masked]>
Date: Thu, 17 Jan 2008 12:10:00 -0800

> semantics defined in RFC 2822.

If the Sender: is the same as one of the From: addresses, why does it matter 
that the semantics is different?

d/

-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Thu, 17 Jan 2008 12:23:26 -0800

On Jan 17, 2008, at 11:40 AM, Jim Fenton wrote:

> SSP is trying to provide information in the absence of a valid  
> signature from the author.

Would you be okay with this stated a bit differently?

SSP provides policy information in the absence of a valid signature  
from the domain of the author.

-Doug

---

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

> from the domain of the author.

Sure.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Thu, 17 Jan 2008 12:57:04 -0800

Dave Crocker wrote:
> If the Sender: is the same as one of the From: addresses, why does it 
> matter that the semantics is different?

If it is, that's fine, but it doesn't have to be, and we need to handle 
that case too.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Thu, 17 Jan 2008 13:38:54 -0800

d/

-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Thu, 17 Jan 2008 14:01:17 -0800

Dave Crocker wrote:
>
>
> Jim Fenton wrote:
>>> If the Sender: is the same as one of the From: addresses, why does 
>>> it matter that the semantics is different?
>>
>> If it is, that's fine, but it doesn't have to be, and we need to 
>> handle that case too.
>

I'm still missing a suggestion for what we use when the Sender header 
field does not match any of the addresses in the From.  Do we then 
revert to First Author?  All Authors?

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Thu, 17 Jan 2008 14:37:32 -0800

On Jan 17, 2008, at 2:01 PM, Jim Fenton wrote:

> I'm still missing a suggestion for what we use when the Sender  
> header field does not match any of the addresses in the From.  Do we  
> then revert to First Author?  All Authors?

Establishing compliance is a separate matter from that of establishing  
policy.

If the DKIM WG adopts John Levine's suggestion, then all From domain  
policies would need to be obtained.  If the "first author" policy  
strategy is retained, only the From domain policy of the first email- 
address would be obtained.

Policy compliance for a From domain expressing either "all" or  
"strict" would require a signature from that domain, irrespective of  
the "on-behalf-of" header assertion.  An exception might be made for  
g= restricted keys, but again the WG would need to decide this as  
well.  IMHO, there should be an exception made for restricted keys.

Depending upon how restricted keys are handled, there might be a need  
to obtain the policy of the signing domain when "all" or "strict"  
assertions are intended to invalidate these signatures and when the  
domain is not present within the From header.  The signing domain  
might be associated with any header, or no header at all.  It could be  
the Sender header.  It could be simpler to say g= restricted keys  
should only sign on-behalf-of a From email-address domain.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Thu, 17 Jan 2008 14:50:14 -0800

Douglas Otis wrote:
> strategy is retained, only the From domain policy of the first 
> email-address would be obtained.

Yes, this is an alternative suggestion to those.
> should only sign on-behalf-of a From email-address domain.

You have brought this up several times, and you're at least a couple of 
steps ahead of us.  Before you do anything based on the policy 
(practices), you need to decide where to look to find them.  This 
discussion has to do with the where-to-look part of the process.

-Jim

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 18 Jan 2008 05:01:48 +0100

Arvel Hathcock wrote:

> suppose that the Sender header were used only when the domain 
> disambiguate the process allowing SSP to know precisely which
> of the multiple domains involved in authorship purports to be
> that which posts the message to the mail stream.
 
> This would not help in cases where the Sender: domain is
> entirely different from any found in the From: but at least
> it would address the root concern found in issue 1525.  That
> is, it could no longer be said  that SSP requires the first
> author to be the poster (which is the meat of issue 1525) and
> this issue could perhaps be closed?

It's a plausible idea, IMO really better than "first author".

Wannabe "mailing lists" mutilating an existing Sender have no
leg to stand on, multi-author scenarios are rare at best, and
SSP explicitly notes that it's not designed for "non-standard"
mailing lists.

SSP would have to note very clearly that your proposal does NOT
allow for at least two standard use cases:  Sender in entirely
different domain, and almost all Resent-* cases.  That covers
Jim's "working as designed" point about my strictly.you@ case.

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 18 Jan 2008 05:26:02 +0100

Jim Fenton wrote:

> a message contrary to the published SSP, and it did its job.
> I count this is a success.

"Working as designed" is a compelling argument.  Let's use
Arvel's "Sender" proposal instead of renaming SSP to "FASP".  

Please keep the revised "author" terminology, Arvel's idea
is for cases where "Sender" picks one of the author domains.

 Frank

---

From: Hector Santos <[email-masked]>
Date: Thu, 17 Jan 2008 23:52:30 -0500

> is for cases where "Sender" picks one of the author domains.

Off hand +1.

For cases where there exist multiple From: domains, using the Sender: 
domain (assuming they could only be ONE domain for Sender:) as a 
"helper" for the SSP domain discovery sounds feasible.

But it must be under the following conditions:

REQ-1: From: and Sender: are part of the DKIM binding process.
REQ-2: Sender domain IS within the list of From: domain(s).

What if these conditions are not met?

REQ-1:

First, From: is required to be part of the binding process. Sender: does 
not to be bound by the signature.  But when multiple From: domains are 
used, then the SENDER: MUST be bound by the signature.

But the real issue is why there are NO real signatures. As it always 
been, the issue of failed vs no real signature rears its ugly head.
In either case, the NO signature state SHOULD enforce requirement #2.

REQ-2:

The valid scenario for the SSP discovery is:

    From: A, B, C
    Sender: A|B|C   <--- has one of these.

But when we have this:

    From: A, B, C
    Sender: D

Then there are a few design approaches:

  1) Use the first From: domain -> A
  2) Use the Sender: domain -> D

Obviously, there is only one TRUE server, regardless when there are 
co-authors.  So it probably makes sense to use Sender: IFF there are 
non-matching co-authors.

-- 
Sincerely

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

---

From: "John L" <[email-masked]>
Date: 17 Jan 2008 23:58:34 -0500

>> problems than anyone else, but an exaggerated idea of their own importance. 
>

My understanding is that the point of publishing SSP is to help mail 
recipients filter their mail better, where the only useful meaning of 
better is that it makes the recipient users happier.  (I see occasional 
claims that the purpose of SSP is to permit senders to make statements 
regardless of whether they're useful to anyone else.  If that's the case, 
we need to document it better but you can ignore the rest of this 
message.)

Senders' opinions about third parties aren't useful in making filtering 
decisions.  In the example above, what happens when a user of such a 
domain sends mail through a mailing list and the signatures break?  If you 
believe the strict SSP, you throw away perfectly good mail, making users 
unhappy.  Well, OK, perhaps you adjust your rules to whitelist mail from 
known mailing lists.  But now what about a domain like Paypal that you 
know (not from SSP) is both heavily forged and doesn't send mail through 
lists?  My filter rules dump anything not sent directly from Paypal, list 
or no list.  But how can SSP help us distinguish the Paypals from the 
self-importants?  It can't, and there are clearly far more inept mail 
system managers than Paypal-style mega-phish targets.

It's fine to publish statements about what you actually do.  "I sign 
everything" is fine, a sender controls that.  Perhaps "I don't send mail 
through lists" would be useful, again, a sender can control that.  But 
"I'm a phish target" or "broken signatures are forgeries" or anything else 
that purports to describe what other people do isn't useful, because the 
guy making the statement doesn't know any more about it than anyone else 
does.  For the vast majority of domains, I suspect that AOL and Hotmail 
and other large inbound mail systems have much better data on how much

R's,
John

PS: I say this even though I happen to be a moderately signficant forgery 
target.  Every day abuse.net gets over 300,000 bounces of spam it didn't 
send, but I don't see why anyone who doesn't already know me would take my 
word for it.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Fri, 18 Jan 2008 00:27:15 -0500

John L wrote:
> better is that it makes the recipient users happier.  

Well, that applies to any filtering concept in general - hence the term 
filtering.

To me, SSP is related to the DKIM-BASE "promotion" for a new level of 
operations and expectations.

The DKIM-BASE presumption is such that all mail is going to be signed or 
not signed and that the receiver should make new assertions about the 
valid DKIM-BASE signed mail.

The problem is two folds:

   - Was it authorized (signed) by the right person?
   - Was it REALLY not signed (as opposed to failed) at all?

The idea that a receiver should just apply special DKIM considerations 
to valid signed mail and ignore the "Same Considerations" when they are 
not signed, just accept it as it was legacy stuff, is unacceptable in my 
book.

This can only only be resolved by what is expected by the "domain 
owner."   That expectation has to come from somewhere.

In my opinion, it boils down to:

  a) Some believe that come from a non-standard TRUST service
     (another form of SSP, but limited only to those who are
     members of the TRUST server).

  b) A "batteries not required" industry standard SSP approach
     which allows the DOMAIN itself to define the expectation.

The first methods can offer both merged "POLICY" and "REPUTATION" logic.

The latter is simply about DKIM-BASE protocol consistency. In lieu of a 
white/black list, no reputation is considered. Everyone is viewed the 
same way.

The first has limited effectiveness since it is secluded to member 
records only and it has NO logic for unsigned mail signatures.  This 
will not allow receivers to cover DKIM across the board. i.e, it doesn't 
address the legacy market - where the majority of abuse is located.

The latter has the potential to be vastly effective since no special 3rd 
party membership is required and MOST of the abuse occurs when they is 
protocol inconsistency. This will allow receivers to cover DKIM across 
the board.

-- 
Sincerely

Hector Santos, CTO

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 18 Jan 2008 06:58:13 +0100

John L wrote:

> Every day abuse.net gets over 300,000 bounces of spam it didn't send

It's your decision to rely *only* on BATV instead of adding SPF FAIL:
Setups suited for BATV are also suited for SPF FAIL (the opposite is
unfortunately not always true, or at least not trivial).  

In addition to the 300,000 bounces you get for forged "mail from
abuse.net" there are likely millions of forged "mail from abuse.net"
making it into the inbox of unhappy users.

If getting behind a few user@alumni forwarders doesn't allow you to 
publish SPF FAIL you made up your mind what's more important for you.

> I don't see why anyone who doesn't already know me would take my 
> word for it.

Not publishing FAIL is clear, if that's abuse.net, PayPal, or GMail
doesn't matter, it means "I don't care about forged envelope sender
addresses claiming to be from me, I have other priorities".

 Frank

---

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

>It's your decision to rely *only* on BATV instead of adding SPF FAIL:

You haven't looked at abuse.net's SPF record, have you?

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 18 Jan 2008 11:06:56 +0000

We seem to be approaching the point where the editors have
enough information to include Arvel's proposal in a new rev.
(And I guess 1525 becomes an ACCEPT(CHECK) in the list of
issues.) That's good, thanks.

Maybe move on to try close #1534? [1,2]

S.

[1] https://rt.psg.com/Ticket/Display.html?id=1534
[2] http://mipassoc.org/pipermail/ietf-dkim/2007q4/008437.html
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 18 Jan 2008 14:50:13 +0100

> Maybe move on to try close #1534? [1,2]

Maybe the draft could note, that its use of "parent"
means "remove leftmost label and try again", not
some "find zone cut" query=ns magic.  And that this
use of "parent" will hit co.uk (etc.) domains.

How about asking the "namedroppers" if that's okay ?
Not volunteering:

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 18 Jan 2008 14:30:07 +0100

> You haven't looked at abuse.net's SPF record, have you?

No - I recalled the articles where you exlained how you
deal with this flood, and why you don't like SPF FAIL.

It didn't occur to me that you could *ever* change your
mind about this.  Maybe that was like my old "promise"
to killfile any @gmail.com on sight, now I use it... :-|

 Frank

---

From: <[email-masked]>
Date: Fri, 18 Jan 2008 16:01:40 +0000

> Date: Thu, 17 Jan 2008 09:32:42 -0500
> From: [email-masked]
> To: [email-masked]
> Subject: Re: [ietf-dkim] ISSUE 1525 -- Clarification about posting by first	Author
> CC: [email-masked]
> 
> 

+1 I think in the case of multiple From: addresses only checking one, or only checking the one that matches the sender seems to arbitrarily ignore the policy of other domains appearing in that header. As long as the document suggests a limit on how many checks to do I think John's approach makes the most sense to me.
 
> messages?  (Actual non-rhetorical question.)

I would agree here, except for one consideration. It makes it possible to trivially bypass someone's policy by inserting a completely bogus signature in all messages claiming to be from them. If anyone has a good suggestion for how to tell the difference between a signature broken in transit and one
just made up out of nothing or copied from a different valid message  apart from keeping a list of known mailing lists and forwarders who change message content, I'd be willing to change my mind.

- Robert

_________________________________________________________________
Climb to the top of the charts!  Play the word scramble challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan

---

From: Michael Thomas <[email-masked]>
Date: Fri, 18 Jan 2008 08:18:06 -0800

> SSP explicitly notes that it's not designed for "non-standard"

What about the situation where you have multiple From addresses
and no Sender (or a sender that doesn't correspond to any of the
 From addresses)? This might not be legal 2822, but spammers don't
care about that.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 18 Jan 2008 08:28:08 -0800

John L wrote:
> regardless of whether they're useful to anyone else.  If that's the 
> case, we need to document it better but you can ignore the rest of this 
> message.)
> 
> domain sends mail through a mailing list and the signatures break?  If 
> you believe the strict SSP, you throw away perfectly good mail, making 
> users unhappy.  Well, OK, perhaps you adjust your rules to whitelist 
> mail from known mailing lists.  But now what about a domain like Paypal 
> that you know (not from SSP) is both heavily forged and doesn't send 
> mail through lists?  My filter rules dump anything not sent directly 
> from Paypal, list or no list.  But how can SSP help us distinguish the 
> Paypals from the self-importants?  It can't, and there are clearly far 
> more inept mail system managers than Paypal-style mega-phish targets.

There's an infinite variation of things that inept system managers
can do. If they misuse SSP why is that so very different inept sysadmins
who run open relays? Both are dumb and will get you in trouble. If we're
limited to the lowest common denominator, then there's _nothing_ we can
do because that's really low, and it really doesn't have anything to do
with their motivation (cf self-importance).

> "I'm a phish target" or "broken signatures are forgeries" or anything 
> else that purports to describe what other people do isn't useful, 
> because the guy making the statement doesn't know any more about it than 
> anyone else does.  For the vast majority of domains, I suspect that AOL 
> and Hotmail and other large inbound mail systems have much better data 
> on how much

Well, SSP doesn't have "I'm a phish target" but does have the other two
more or less, so I guess there's no argument here.

		Mike

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 18 Jan 2008 10:27:07 -0600

hi Jim (and everyone)!

 > revert to First Author?  All Authors?

The idea of checking SSP on up to N From: domains is the only suggestion 
I've seen so far and I can't think of anything better.

So, if the SSP algorithm returns Suspicious for any one of the domains 
found in From: then let that be the final SSP result (in fact, further 
SSP checks could be skipped at this point).  In other words, if even one 
of the domains listed on the From: requires a verifiable signature and 
that signature is NOT present then the message is Suspicious even if the 
result of SSP for one or more of the other domains is non-Suspicious.

Would this work?

Arvel

---

From: John Levine <[email-masked]>
Date: 18 Jan 2008 16:37:53 -0000

>I would agree here, except for one consideration. It makes it possible
>to trivially bypass someone's policy by inserting a completely bogus
>signature in all messages claiming to be from them. If anyone has a good
>suggestion for how to tell the difference between a signature broken in
>transit and one just made up ...

As far as DKIM is concerned, there is no difference between a broken
signature and no signature.  A message that arrives with a bogus
signature is unsigned.

R's,
John

---

From: John Levine <[email-masked]>
Date: 18 Jan 2008 16:34:45 -0000

>deal with this flood, and why you don't like SPF FAIL.

It didn't make any difference, since nobody of any importance rejects
for -all.

Followups to some place other than the DKIM list, please, although
this is probably a useful data point for anyone who thinks that
SSP "strict" will be effective.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Fri, 18 Jan 2008 08:44:55 -0800

On Jan 18, 2008, at 8:18 AM, Michael Thomas wrote:

>>> disambiguate the process allowing SSP to know precisely which of  
>>> the multiple domains involved in authorship purports to be that  
>>> different from any found in the From: but at least it would  
>>> address the root concern found in issue 1525.  That is, it could  
>>> no longer be said  that SSP requires the first author to be the  
>>> poster (which is the meat of issue 1525) and this issue could  
>>> perhaps be closed?
>>
>> Wannabe "mailing lists" mutilating an existing Sender have no leg  
>> to stand on, multi-author scenarios are rare at best, and SSP  
>> explicitly notes that it's not designed for "non-standard" mailing  
>> lists.
>
> What about the situation where you have multiple From addresses and  
> no Sender (or a sender that doesn't correspond to any of the From  
> addresses)? This might not be legal 2822, but spammers don't care  
> about that.

It should not matter which header a signature is on-behalf-of as long  
the signing domain could be valid for the From email-address domain.   
The i= parameter within the signature could be an opaque value and not  
be associated with any header.  An unrestricted signature of the From  
_domain_ irrespective of the i= parameter would make the message  
compliant with "all" or "strict".   The MUA might be able to only  
highlight the signing-domain and not a specific header.  Limited  
highlighting is not really different for a signature without an i=  
where are multiple email-addresses within the same domain.

-Doug

---

From: John L <[email-masked]>
Date: Fri, 18 Jan 2008 11:42:34 -0500 (EST)

> who run open relays?

Because open relays don't purport to provide information useful in 
handling mail.  Since you apparently agree that a significant fraction of 
SSP info will be wrong, how is a receiver supposed to tell useful SSP from 
useless SSP?

If you need a reputation system to decide whether to use someone's SSP, 
why wouldn't you just put the useful info into the reputation system and 
forget about SSP?

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Fri, 18 Jan 2008 08:50:33 -0800

John L wrote:
> handling mail.  Since you apparently agree that a significant fraction 
> of SSP info will be wrong, how is a receiver supposed to tell useful SSP 
> from useless SSP?

   In both cases, it leads to the receiver throwing away potentially
   useful mail so the inept sysadmin gets pretty much what they deserve.
   So why even worry about it at all? When they fix their configuration,
   you'll start receiving from the again. Lots of people do exactly that
   with open relays after all and I don't see a whole lot of
   hand-wringing about that.

> why wouldn't you just put the useful info into the reputation system and 

   First party information is not the same as third party information.
   Both are useful, both have their limitations.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

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

> Date: Fri, 18 Jan 2008 16:37:53 +0000
> From: [email-masked]
> CC: [email-masked]
> 

Sorry, I think I may have misunderstood your earlier point. When you say SSP applies only to unsigned messages were you talking about excluding valid third party signatures (I apologize if I misread that part of the email).

If you are talking about third party signatures I guess it comes down to what you think the P in SSP stands for. If it is practices it is clear that I cannot usefully say anything about anyone else's practices. If it is policy I would say it is reasonable for a domain owner to be able to assert the policy that noone else is allowed to sign messages on their behalf. Whether it is wise to do so is really a matter for the domain ownder to decide for themselves looking at their terms of service, how their users (if there are any) actually use their domain, etc..

What a receiver does with this information is in my opinion out of scope for this discussion. It is essentially just one more useful piece of information to throw into the vast sea of information they already have available to help make decisions. If they choose to pick a set of third parties who they trust regardless of the originating domains assertion that would be up to them. SImilarly if they want to pick a list of originating domains they are completely unwilling to accept  third party signatures for that is also up to them. The policy of the originating domain may be of some help in deciding if someone belongs in either of those categories. .

- Robert

_________________________________________________________________
Connect and share in new ways with Windows Live.
http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008

---

From: John L <[email-masked]>
Date: Fri, 18 Jan 2008 12:19:02 -0500 (EST)

>  So why even worry about it at all?

Because my goal is not to punish inept administrators, my goal is to 
deliver mail.  Inept admins usually have other users who send actual mail 
to my users.

Seems to me that you've said that if your goal is to deliver your users' 
mail, you dare not use SSP.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Fri, 18 Jan 2008 09:35:36 -0800

John L wrote:
> deliver mail.  Inept admins usually have other users who send actual 
> mail to my users.
> 

If you're that concerned, you shouldn't be using any sort of reputation
and/or filtering since the chance of false positive is > 0. But of
course you do, so you obviously accept the possibility of inept
sysadmins doing themselves harm. Why badly configured SSP is any
different is beyond me. Frankly, I'd be a lot more worried about
badly administered RBL's and their ilk since they aren't accountable
to anybody but themselves.

		Mike

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 18 Jan 2008 11:42:14 -0600

hi Jim (and everyone)!

Would this work?

Arvel

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 18 Jan 2008 20:54:05 +0100

> From addresses)? This might not be legal 2822, but spammers don't

The first case isn't legal, it's IMO no job for SSP to specify
what implementations / receivers do with syntactically invalid
mails.  Invalid => do what you like (it could be first author).

The second case is legal (ditto Resent-* and domain literals).

I've no idea what to do, nobody here liked the proposal to use
the PRA, many don't like to use the Sender (if it's not one of
the From-domains), "toss a coin" (Message-ID or 1st author or
Reply-To) is unconvincing => SSP has to give up, receivers can
treat it like a single 2882-From with a domain literal.

 Frank

---

From: Jim Fenton <[email-masked]>
Date: Fri, 18 Jan 2008 12:11:03 -0800

Arvel Hathcock wrote:
> The idea of checking SSP on up to N From: domains is the only 
> suggestion I've seen so far and I can't think of anything better.
>
> SSP checks could be skipped at this point).  In other words, if even 
> one of the domains listed on the From: requires a verifiable signature 
> and that signature is NOT present then the message is Suspicious even 
> if the result of SSP for one or more of the other domains is 
> non-Suspicious.
>
> Would this work?

It could.

Let me summarize what I think we have consensus on (chairs, please 
correct me if I'm incorrect because this is your call):

If a message has multiple From addresses, and the Sender address matches 
one of the From addresses, then the SSP of the Sender address domain is 
queried. (change from the first From address in the current draft)

What we have left to answer:

If a message has multiple From addresses, and the Sender address does 
not match one of the From addresses, then I have seen three 
possibilities proposed:

1.  Use the domain of the first From address
2.  Use the domain of the Sender address
3.  Use the domains of all From addresses, and if the message is 
Suspicious (SSP non-compliant) according to the SSP of any of the From 
address domains, the message is considered Suspicious (SSP non-compliant).

Note that when I say "Sender address matches..." that means the entire 
addr-spec of the address (including the local-part, but not the 
display-name).  If you think it should be something else (such as just 
the domain part) that should be compared, please say so now.

Arvel's suggestion above is #3. I believe Hector earlier favored #2.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Fri, 18 Jan 2008 12:19:24 -0800

On Jan 18, 2008, at 11:54 AM, Frank Ellermann wrote:

> The first case isn't legal, it's IMO no job for SSP to specify what  
> implementations / receivers do with syntactically invalid mails.

Agreed.

> Invalid => do what you like (it could be first author).
>
> I've no idea what to do, nobody here liked the proposal to use the  
> PRA, many don't like to use the Sender (if it's not one of the From- 
> domains), "toss a coin" (Message-ID or 1st author or Reply-To) is  
> unconvincing => SSP has to give up, receivers can treat it like a  
> single 2882-From with a domain literal.

There is a domain within the signature that should be used to assess  
compliance.  What prevents a valid signature of the From domain from  
allowing a message to comply with "all" or "strict"?

Why attempt to have SSP define permitted values of the i= parameter  
for compliance.  With the one proviso of excluding a g= restricted  
key, _any_ signature where the domain would be valid when signed on- 
behalf-of the From header email-address, these signatures alone should  
be considered compliant with "strict" or "all".

What gets displayed by the MUA is not a problem for this WG, but this  
display problem is not any different than when the i= parameter is  
excluded from the signature and there are multiple addresses within  
the same domain.

There is no need to search for any purported responsible domain.  This  
is the function of a valid DKIM signature.  When the signing domains  
desires to make it clear which identity is being signed on-behalf-of,  
this is an entirely separate matter that should not be an issue for  
SSP to handled.  Clearly, the signer is able to convey this choice  
without the use of SSP.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Fri, 18 Jan 2008 12:45:08 -0800

>> implementations / receivers do with syntactically invalid mails.

I'm sorry, but we're writing a security protocol here. Spammers
don't obey real laws, let alone care about 2822 arcana. You might
as well just put all your eggs in the RFC3514 basket.

		Mike

---

From: Jim Fenton <[email-masked]>
Date: Fri, 18 Jan 2008 13:03:57 -0800

> as well just put all your eggs in the RFC3514 basket.

So fine...call it Suspicious (I mean SSP non-Compliant).

-Jim

---

From: John L <[email-masked]>
Date: Fri, 18 Jan 2008 16:08:11 -0500 (EST)

Ah, now we're getting somewhere.

> Why badly configured SSP is any different is beyond me. Frankly, I'd be 
> a lot more worried about badly administered RBL's and their ilk

I'm quite concerned about badly administered DNSBLs.  That's why I use 
DNSBLs run by people I know and trust, rather than DNSBLs run by random 
strangers.

Using SSP is a whole lot like using random DNSBLs run by strangers -- in 
both cases you're asking someone who has no particular credibility whether 
to discard your incoming mail.  If you wouldn't do one, why would you do 
the other?

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: Michael Thomas <[email-masked]>
Date: Fri, 18 Jan 2008 13:16:34 -0800

John L wrote:
>> Why badly configured SSP is any different is beyond me. Frankly, I'd 
>> be a lot more worried about badly administered RBL's and their ilk
> 
> both cases you're asking someone who has no particular credibility 
> whether to discard your incoming mail.  If you wouldn't do one, why 
> would you do the other?

Assumedly the first party has some desire to get their mail delivered.
That's a lot different than a RBL who might have an agenda, be lazy
or both. The first party always has the ability to correct the problem
too, unlike RBL's.

		Mike

---

From: Douglas Otis <[email-masked]>
Date: Fri, 18 Jan 2008 13:21:41 -0800

On Jan 18, 2008, at 12:45 PM, Michael Thomas wrote:

>>> mails.
> don't obey real laws, let alone care about 2822 arcana. You might as  
> well just put all your eggs in the RFC3514 basket.

Valid DKIM signatures only ensure which domain introduced the message.  
RFC 2822 compliance is completely a separate matter.

When a signing domain decides to make the signature's on-behalf-of  
clear, they can do so without needing SSP.  If you think ambiguously  
signed messages by the From domain represent a security risk, you must  
not depend upon SSP to make this decision for you.  This would be  
depending upon the same entity that ambiguously signed message.   
Ambitiously signed messages represent legal and valid signatures,  
since DKIM is _not_ about identifying the individual per the charter,  
nor should this become a requirement of SSP.

When SSP makes a policy assertion of "all" or "strict", this should  
only establish a requirement for the domain of the signature.  Call it  
the validated responsible domain.

What difference would it make when the i= parameter to contains an  
opaque value not associated with any header contained within the  
message?  Remember, DKIM is not about identifying individuals.  What  
security risk do you envision when there are multiple email-addresses  
within the same domain, but where the i= is not included within the  
signature?  Why would it be safe to assume the signature is on-behalf- 
of any specific identity in that case?

Keep in mind, you are describing something well within the control of  
the signing domain.  What risk are you concerned about?

-Doug

---

From: John L <[email-masked]>
Date: Fri, 18 Jan 2008 16:25:13 -0500 (EST)

> Assumedly the first party has some desire to get their mail delivered.

Based on some of the rants I've seen, that seems a rather optimistic 
assumption.  Anyone who publishes "strict" is telling you that they 
*don't* want mail delivered.  Whether the mail they don't want to deliver 
is the same as the mail you don't want to deliver remains an open 
question.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Fri, 18 Jan 2008 13:40:03 -0800

John L wrote:
>>> Using SSP is a whole lot like using random DNSBLs run by strangers -- 
>>> in both cases you're asking someone who has no particular credibility 
> *don't* want mail delivered.  Whether the mail they don't want to 
> deliver is the same as the mail you don't want to deliver remains an 
> open question.

So you want to sadistically deliver the mail that they've so
masochistically set up for the bit bucket? Um, ok I guess.

		Mike

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 18 Jan 2008 17:40:27 -0600

> If you think it should be something else (such as just the domain
 > part) that should be compared, please say so now.

I was thinking that just the domain needs to match.  You'll get the same 
policy regardless and this would allow for an author's secretary (for 
example) to do the posting on behalf of all the authors which I vaguely 
remember being an example case in one of the messaging RFCs (can't 
remember which now).

Arvel

---

From: Jon Callas <[email-masked]>
Date: Fri, 18 Jan 2008 15:53:17 -0800

>   the likely mitigation that filtering software should view this as

This is the way I think we should handle it.

Charles Lindsey noted that multiple Froms are legal but rare today,  
but might be common later.

This is a marvelous point, but it never was an intent of DKIM to be  
the perfect mail security system.

If it became common for someone to play a DKIM game with multiple  
Froms, then I would expect other software (like SpamAssassin, or even  
the MTA) to start flagging it. I can envision the Sendmail/Postfix  
option to cause all multiple-from messages to be counted as DKIM- 
noncompliant (or what ever word we're using for "suspicious").

That wouldn't be a bug, it would be a feature.

If there is an edge condition that can easily be handled elsewhere in  
the mail system, let them do it.

	Jon

---

From: SM <[email-masked]>
Date: Fri, 18 Jan 2008 23:30:34 -0800

At 15:40 18-01-2008, Arvel Hathcock wrote:
>I was thinking that just the domain needs to match.  You'll get the 
>same policy regardless and this would allow for an author's 
>secretary (for example) to do the posting on behalf of all the 
>authors which I vaguely remember being an example case in one of the 
>messaging RFCs (can't remember which now).

RFC 2822, Appendix A.1.

The author's domain can be different from the sender's domain.

Regards,
-sm

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 19 Jan 2008 08:53:37 +0100

Douglas Otis wrote:

> There is a domain within the signature that should
> be used to assess compliance.  What prevents a valid
> signature of the From domain from allowing a message
> to comply with "all" or "strict"?

The most interesting case for SSP is "no signature".

For my unconvincing "toss a coin" list (Message-ID or
first author or Reply-To) it's of course possible to
add "use any signature for a domain in From addresses"
to figure out a relevant domain for SSP.

But that only works if there is a corresponding DKIM
signature, when it's not really necessary to test SSP.

Or do I miss something obvious in your proposal ?  We
could pick John's proposal where Arvel's idea doesn't
work, just look at all domains in From addresses, for
legit mail it's rare.  That needs some "SSP processing
limits" for malicious mails (not as badly as for SPF).

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 19 Jan 2008 09:07:40 +0100

Arvel Hathcock wrote:
 
> example case in one of the messaging RFCs (can't remember which now)

RFC 733 (or RFC 724, read "@" for "at" today, note Host != SHost):

| George Jones logs in as Jones on his Host.   His  secretary,  who
| logs in as Secy on Shost sends mail for him.  Replies to the mail
| should go to George, of course.
|
|    From:    George Jones <Jones at Host>
|    Sender:  Secy at SHost

 Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Sat, 19 Jan 2008 14:42:01 -0000

> I've seen so far and I can't think of anything better.

And indeed it is the only one that will even work.

Suppose the Bad Guy owns the domain n.tv (and maybe got it through a dodgy  
registrar willing to take his money and ignore his subsequent badness).

Suppose he has a signing key for that domain, properly registered in the  
DNS, and maybe he even publishes an SSP, with the 'strict'est possible  
policy.

He sends mail with
     From: "Natwest Bank Security"@n.tv, <[email-masked]>
(I chose Natwest, because it is the current prime phishing target in *.uk  
at the moment). Suppose Natwest has published the 'strict'est possible SSP  
- it has no effect because, as the Bad Guy knows, only the first From  
address is looked at ...

So the ONLY method that will work is to lookup the SSP for ALL the From  
addressas AND the Sender as well (though usually the Sender will already  
be covered somewhere in the From). And there better be signatures to cover  
ALL of the SSP policies that show up.

A few commments:
1. We all agree that multiple From addresses are rare in practice, so the  
burden of the extra DNS lookups will hardly matter.

2. Unless someone tries to do a DOS attack against the DNS system that way  
(but there are easier ways to DOS the DNS system). A little common sense  
by verifying agents should prevent such attacks.

3. If Amazon and Ebay (both with 'strict' policies) want to send out a  
joint message From: them both, then it will need to be signed by both of  
them. How they arrange to do that is their poblem :-).

4. With this sort of system, it may be necessary to rethink just what  
policies we choose to be able to express in the SSP.

+1

---

From: Hector Santos <[email-masked]>
Date: Sat, 19 Jan 2008 11:38:32 -0500

> Arvel's suggestion above is #3. I believe Hector earlier favored #2.

After reviewing this, I think we have no choice but to lookup all the 
co-author's domains, regardless of the presence of sender.  At best, 
Sender can be use to change the lookup order.

Examples:

#1: sender matching domain

    From: p1 @ a.com, p2 @ b.com, p3 @ b.com, p1 @ c.com
    Sender: p4 @ b.com

#2: sender no matching domain

    From: p1 @ a.com, p2 @ b.com, p3 @ b.com, p1 @ c.com
    Sender: p4 @ d.com

#3: no sender

    From: p1 @ a.com, p2 @ b.com, p3 @ b.com, p1 @ c.com

I think #2 and #3 is the same situation, so therefore we need the
logic for handling no-sender header situations as it was a non-matching 
situation as well.

We have no choice but to look at each co-author domain.

IMO, there is only one thing we are looking for here - a restricted policy:

    dkim=all
    dkim=strict

I think if any one co-author domain is restrictive, then in order to 
provide protocol consistency and fail-safe transactions, the message 
must be deemed non-compliant.

This is preferable for the (rare) situations where maybe the primary 
author with DKIM signing potential is given the responsibility to 
distribute mail for co-authors who are not capable of signing, hence no 
SSP record.

The only place I see Sender helping is as a "helper" to help avoid 
lookup overhead and redundancy.  Like in #1, if a sender header exist, 
and its domain matches one of the co-authors, then possibly it can be 
used as the FIRST domain to lookup.

In other words, when there is no sender, the look up order would be:

      A.COM
      B.COM
      C.COM

but with a matching sender (B.COM), the lookup order could be:

      B.COM
      A.COM
      C.COM

But regardless of the lookup order, I believe we have no choice but to 
lookup all the unique domains in the From: field.  If B.COM comes back 
as SSP DKIM=UNKNOWN, you still need to lookup A.COM and C.COM for any 
restrictive policies.

The only time a Sender domain lookup is meaningful, is when the policy 
is restrictive, thus short-circuiting any further lookup.

Make sense?

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Sat, 19 Jan 2008 13:15:29 -0800

On Jan 18, 2008, at 11:53 PM, Frank Ellermann wrote:

> Douglas Otis wrote:
>
>> There is a domain within the signature that should be used to  
>> assess compliance.  What prevents a valid signature of the From  
>> domain from allowing a message to comply with "all" or "strict"?
>

SSP should create compliance requirements for messages based upon From  
header's domain(s).   A "strict" or "all" compliance requirement  
should be met with a signature that could be valid for the From email- 
address's domain.  The signature should not need to be "on-behalf-of"  
the From email-address (as determined by the signatures i= parameter).

IMHO there should be an exception for restricted keys, where these  
signatures must be on-behalf-of the From email-address to fulfill a  
compliance requirement of "all" or "strict".

> For my unconvincing "toss a coin" list (Message-ID or first author  
> or Reply-To) it's of course possible to add "use any signature for a  
> domain in From addresses" to figure out a relevant domain for SSP.

It should not matter which header a domain's signature is on-behalf- 
of.  DKIM is not about establishing an author's identity.  The trust  
being established is with the signing domain.  The signing domain has  
the option of using ambiguous signature (no i= or no local-part and  
multiple email-addresses of their domain).  IMHO, the signing domain  
should be able to even use an opaque identity that does not associate  
with any header.  An opaque id could prove useful to protect someone's  
privacy.  A domain should be able to indicate they sign "all" without  
conveying anything more than that it was signed by their domain.

> But that only works if there is a corresponding DKIM signature, when  
> it's not really necessary to test SSP.

Just having a DKIM signature is not enough.  Domains protected by DKIM  
and an SSP assertion of "all" or "strict" must include a signature  
from a domain that would be valid for the From email-address domain in  
question.  The DKIM WG seems unnecessarily focused on the on-behalf-of  
feature of the DKIM signature.  This feature _might_ enable an MUA to  
highlight which identity the signature was on-behalf-of.  There may be  
cases where it is not possible for MUAs to establish which identity  
the signature was on-behalf-of.  In that case, just the signature  
domain could be highlighted.  Due to the possible on-behalf-of  
uncertainty, DKIM signature notifications must be able to convey just  
the domain of the signature.

Although compliance for "all" or "strict" could be defined to require  
an unambiguous on-behalf-of, such a requirement will make unambiguous  
on-behalf-of less certain.  The signing domain might then "falsify"  
the on-behalf-of to meet an unambiguous on-behalf-of.  Security  
concerns are better met by not placing constraints on the types of  
signatures used.  There are also the issue of body length, and subject  
lines where security might be impacted.  The verifier/MUA can use the  
information and display whatever they consider appropriate.  One could  
argue that excluding the subject line and including body length should  
not be used as well.  There is no reason to use SSP as a means to  
constrain these parameters.

> Or do I miss something obvious in your proposal ?  We could pick  
> John's proposal where Arvel's idea doesn't work, just look at all  
> domains in From addresses, for legit mail it's rare.  That needs  
> some "SSP processing limits" for malicious mails (not as badly as  
> for SPF).

EAI might wish to allow two From email-addresses to permit alternative  
formats.  SSP could assert that messages containing more than two From  
email-addresses are not complaint with "all" or "strict".  This would  
limit the number of policy search operations to two per message.   
Except in cases of restricted keys, SSP compliance should not depend  
upon which header the address is on-behalf-of.  Ensuring an  
unambiguous signature is within the control by the signing domain and  
is independent of SSP compliance.  MUAs are free to display  
ambiguously signed, body length, and excluded subject line messages in  
any manner they consider appropriate.  There is no reason for the DKIM  
WG to dictate how the on-behalf-of feature of the signature must be  
used before a domain can assert their signing practices or policies.   
Let the market decide.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 21 Jan 2008 11:45:21 -0000

> Sender can be use to change the lookup order.

Which does not give you any benefit that I can see. More useful would  
always be to lookup the Sender in SSP just as if it had been in the From  
header.
>     From: p1 @ a.com, p2 @ b.com, p3 @ b.com, p1 @ c.com

In that case, you have already looked up b.com in the From, so no need to  
do it again, of course.
>     From: p1 @ a.com, p2 @ b.com, p3 @ b.com, p1 @ c.com

That might be where [email-masked] was a mailing list expander. If the mailing  
list published an SSP and signed, then that would get checked (though I  
doubt mailing lists would often be specifying "strict").

If any of [abc].com was 'strict', then the message would get through iff  
the mailing list had not broken their sig(s). If they were all 'all', then  
it would get through if either their sig worked or the mailing list's sig  
worked.
>     From: p1 @ a.com, p2 @ b.com, p3 @ b.com, p1 @ c.com

No problem in that case.

---

From: John L <[email-masked]>
Date: Mon, 21 Jan 2008 23:06:33 -0500 (EST)

> Sorry, I think I may have misunderstood your earlier point. When you say 
> SSP applies only to unsigned messages were you talking about excluding 
> valid third party signatures (I apologize if I misread that part of the 
> email).

Seems to me that no matter what we say, if a message is signed by someone 
a receiver sufficently trusts, they're going to whitelist it, so it's 
silly to try to tell them to do anything else.  I'm inclined to completely 
remove anything about what receivers do with mail with other signatures.

R's,
John

---

From: Damon <[email-masked]>
Date: Tue, 22 Jan 2008 09:45:08 -0500

> to anybody but themselves.

Are we seriously saying that we need to be concerned because of inept sysadmins?
I would hate to see the training wheels welded on.
Funny thing about inept sysadmins is that when all of their email
starts to get thrown away, they either fix it or get replaced.
Please let's not try to water this down so much that it becomes useless (again).

Regards,
Damon

---

From: Damon <[email-masked]>
Date: Tue, 22 Jan 2008 09:52:30 -0500

> used before a domain can assert their signing practices or policies.

I liken this ~entire~ argument to something as asinine as not selling
right-handed golf clubs because there are a lot of left handed people
out there. Fringe cases should be considered only as to whether or not
we should add an asterisk to the suggested usage page.

Regards,
Damon S

---

From: <[email-masked]>
Date: Tue, 22 Jan 2008 18:00:37 +0000

> Date: Mon, 21 Jan 2008 23:06:33 -0500
> From: [email-masked]
> To: [email-masked]
> Subject: RE: [ietf-dkim] ISSUE 1525 -- Clarification about posting by first Author
> 

I agree with the part about not telling receivers what to do with a piece of mail but I think there are two assumptions built into the premise above that I have a problem with.

1) It sounds like you are saying that, unless I expect that a receiver is going to use that fact as a binary decision point to accept or reject a piece of mail it is not worth expressing
    Since I am avoiding making any assumptions about how people intend to use the data I think it is useful to be able to express a policy for how I expect domains I control to be used. If some people find that useful sometimes and irrelevant at others then I can't see that I'm worse off than I was before, or that the receiving system is.
and
2) We have to build SSP assuming that people are only ever going to use this information by itself and that they for some reason do not have access to any other information about the sender.
    I understand the idea of keeping reputation out of scope, and not making assumptions about how people use the data. But the idea that all filtering decisions are now and wil be forever a set of hurdles someone has to pass over is just as big an assumption about how the data will be used, as assuming that they will look at the totality of data they have about a sender. The fact is that both cases exist already, and for the latter case any useful information you add to those models makes them better. We don't have to make assumptions (or worse prescriptions) about how people use the data to know that giving people extra information is helpful.
    Since there are a number of useful cases I can think of where domain owners could for valid reasons say "I expect all mail using my domain to be signed by me" I think this is a policy worth allowing in the spec (and no this is not limited to big commercial mailers, many small corporate environments, and environments with very strict legal regimes regarding how they archive their email both jump out as cases where it would be entirely reasonable to express that policy).

    I don't think this qualifies as telling anyone what to do. Just conveying my expectation of how certain domain owners expect their domains to be used. If receiving systems still end up accepting mail from third parties they trust that would be up to them. And, if you are using this data as a single hurdle in mail acceptance, then like virtually any other single hurdle most systems use, you're probably going to have some kind of whitelist for exceptions to that test , but again that is entirely a matter for RECEIVER policy and is independent of any assertions made byt the sender.

Robert

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

---

From: John L <[email-masked]>
Date: Tue, 22 Jan 2008 13:07:37 -0500 (EST)

> 1) It sounds like you are saying that, unless I expect that a receiver 
> is going to use that fact as a binary decision point to accept or reject 
> a piece of mail it is not worth expressing

Oh, no.  I am trying to say that senders should stick to what they know 
about.  "I sign all my mail" certainly qualifies.

> 2) We have to build SSP assuming that people are only ever going to use 
> this information by itself and that they for some reason do not have 
> access to any other information about the sender.

Actually, I feel quite the opposite, that receivers will make their 
filtering decisions based on all sorts of useful information from multiple 
sources.  But I still don't understand why anyone expects "I'm a phish 
target" from some random stranger to be useful.  If you have access to a 
lot of receiver data, e.g., a large ISP, you probably know way more about 
that the sender does.

R's,
John

---

From: <[email-masked]>
Date: Tue, 22 Jan 2008 18:49:48 +0000

> about.  "I sign all my mail" certainly qualifies.

Agreed, and one of the things a domain owner knows in at least some situations is what policies they have set for users of that domain about how they are allowed to use that domain. Clearly this is not the case for a the majority of domains on the internet, but how many have to be able to make this assertion for it to be useful to have in the standard?

> lot of receiver data, e.g., a large ISP, you probably know way more about 

By asserting that any mail that claims authorship from a domain I control must be signed by me I'm not making any particular assertion about why any other mail might not fit that policy. Just the fact that it does not. 

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

---

From: Dave Crocker <[email-masked]>
Date: Tue, 22 Jan 2008 11:16:31 -0800

[email-masked] wrote:
> Agreed, and one of the things a domain owner knows in at least some 
> situations is what policies they have set for users of that domain about 
> how they are allowed to use that domain. Clearly this is not the case 
> for a the majority of domains on the internet, but how many have to be 
> able to make this assertion for it to be useful to have in the standard?

I suspect that "how many" needs to be a secondary criterion, where the primary 
one is characterization of the group(s) to which the mechanism is useful.

If we have some differential statements of constituencies and scenarios to 
which a given feature applies -- sometimes called an applicability statement 
-- then we can make much more realistic statements about utility.

Some constituencies are few in number but big in impact.  That's fine.  As 
long as we can characterize them and convince ourselves that they will benefit.

> By asserting that any mail that claims authorship from a domain I 
> control must be signed by me I'm not making any particular assertion 
> about why any other mail might not fit that policy. Just the fact that 
> it does not.

(just to make sure:  "by me" means "by the same domain as listed in the author 
field?)

At any rate, phrased in the way that you have phrased it, I believe you are 
correct.

However, if you state that all mail claiming authorship from a domain is 
signed by that domain, then there is an inescapable implication about unsigned 
mail claiming that authorship.  There is not need to state the implication 
explicitly.

d/
-- 

   Dave Crocker

---

From: John L <[email-masked]>
Date: Tue, 22 Jan 2008 14:19:20 -0500 (EST)

> about why any other mail might not fit that policy. Just the fact that 

But here we go again.  Why should anyone care about your policy?  We don't 
care about your policy, only about the mail that shows up here, and it is 
most definitely not my job to enforce rules that you claim that apply to 
your users.

A message shows up on a mailing list with a From: address in your domain. 
Your SSP says to discard it.  Tough noogies, I won't.  If an unsigned 
message were otherwise dubious, and you said you signed everything, that 
might tip the balance to filtering it, but not because you told me to.

R's,
John

---

From: <[email-masked]>
Date: Tue, 22 Jan 2008 19:53:46 +0000

> Date: Tue, 22 Jan 2008 14:19:20 -0500
> From: [email-masked]

But if you already have enough data to make a decision about a message's disposition in that case, you also have enough data to make a decision about that message's disposition regardless of any SSP policy that anyone might express. To a system implementing the receiver policy you outlined above SSP is only useful at all for the messages where you don't have enough information to make a decision.

So the question in this case really comes down to whether the policy we are discussing (or any particular SSP statement) is useful, or at least non-harmful, when you are evaluating a message for which your existing policies do not provide a completely efficacious decision algorithm. In any case where your current policies about mail acceptance already work well and provide the answers you want why would you bother to layer extras on top anyway?

Robert

---

From: John L <[email-masked]>
Date: Tue, 22 Jan 2008 15:17:12 -0500 (EST)

> But if you already have enough data to make a decision about a message's 
> disposition in that case, you also have enough data to make a decision 
> about that message's disposition regardless of any SSP policy that 
> anyone might express.

Right.  That's another reason that "strict" is a bad idea, because it 
gives senders the unwarranted impression that they control (or even 
affect) things that we know they don't.

> So the question in this case really comes down to whether the policy we 
> are discussing (or any particular SSP statement) is useful, or at least 
> non-harmful, when you are evaluating a message for which your existing 
? policies do not provide a completely efficacious decision algorithm.

Right again.  That's where I say that statements about things about which 
the sender has actual knowledge (e.g., "I sign everything") are far more 
likely to be useful than statements about things that they don't.

Regards,

---

From: Jim Fenton <[email-masked]>
Date: Mon, 21 Jan 2008 10:57:28 -0800

SM wrote:
>> same policy regardless and this would allow for an author's secretary 
>> (for example) to do the posting on behalf of all the authors which I 
>> vaguely remember being an example case in one of the messaging RFCs 
>> (can't remember which now).
>
> RFC 2822, Appendix A.1.
>

SM,

You're reading this a little out of context.  This isn't about whether 
the message is legal or not, it's for determining whether the Sender 
address can be used as a "tie breaker"to select among multiple From 
addresses to determine which domain should be used for an SSP lookup.

I'm thinking that if we want to be thorough in handling this case (and 
the fact that there have been ~110 messages on this thread, despite the 
fact that it's an exceedingly rare corner case, seems to suggest that we 
do) then SSP lookups should be performed on the domain(s) of all 
address(es) in the From header field, excluding those addresses for 
which there is a valid Author Signature.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Tue, 22 Jan 2008 18:12:01 -0800

On Jan 21, 2008, at 10:57 AM, Jim Fenton wrote:

> You're reading this a little out of context.  This isn't about  
> whether the message is legal or not, it's for determining whether  
> the Sender address can be used as a "tie breaker"to select among  
> multiple From addresses to determine which domain should be used for  
> an SSP lookup.
>
> I'm thinking that if we want to be thorough in handling this case  
> (and the fact that there have been ~110 messages on this thread,  
> despite the fact that it's an exceedingly rare corner case, seems to  
> suggest that we do) then SSP lookups should be performed on the  
> domain(s) of all address(es) in the From header field, excluding  
> those addresses for which there is a valid Author Signature.

Jim,

While RFC 4871 did not impose limits on the number of email-address  
domains contained within the From header, it seems dangerous and  
unlikely supported to suggest all email-addresses fitting within a  
 From header should be searched for SSP records.  Imposing a limit  
requires messages with too many email-addresses within the From header  
to be considered "SSP non-compliant".  Setting a limit would be  
incumbent upon SSP to ensure interchange.  There must be some level of  
email-addresses that are considered compliant.  (Of course, indicating  
a policy is only established by the first email-address within the  
 From header avoids this problem.)

The statement "excluding those addresses for which there is a valid  
Author Signature" needs to be rephrased.  This really depends upon the  
definition given "Author Signature" of course.  To make this clear,  
the statement would be-

  excluding those addresses for which there is a valid
  signature where the d= domain tag is at or above the
  email-address's domain.  Signatures using a g= restricted
  key will be considered SSP non-compliant for "strict"
  or "all" when not on behalf of an email-address within
  the From header.

This clarification overcomes yet another corner case where an office  
admin within the same domain sends a message on behalf of their  
manager.  This definition allows the signing domain to both indicate  
they sign "all" mail, and accurately indicate which entity introduced  
the message.  The signature's domain is seen as valid for the From  
email-address, while also being on-behalf-of the Sender email-address  
within the same domain.  The only exception needed would be for g=  
restricted keys.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Tue, 22 Jan 2008 22:42:55 -0800

Doug,

The question of what qualifies as an Author Signature is a different 
issue and we need to use the same definition in the multiple From 
address case as in the single From address case.  That is issue #1519, 
and let's discuss it in the context of that issue.

I don't think that the specification should specify a limit on the 
number of From address domains that should be checked, because RFC 2822 
doesn't specify a limit.  As a practical matter, some verifiers may 
decide to impose their own limits, and I don't think that introduces a 
problem with "interchange".  SSP is really about giving additional 
information to the verifier, and if they decide not to avail themselves 
of all of the information available, that's up to them (as is the 
decision whether they want to use SSP information at all).

-Jim

Douglas Otis wrote:
>> whether the message is legal or not, it's for determining whether the 
>> Sender address can be used as a "tie breaker"to select among multiple 
>> From addresses to determine which domain should be used for an SSP 
>> lookup.
>>

---

From: <[email-masked]>
Date: Wed, 23 Jan 2008 15:11:34 +0000

Date: Tue, 22 Jan 2008 15:17:12 -0500

> affect) things that we know they don't.

I suspect that the group of senders who think they can somehow mandate
how a receiver treats their mail already have the belief independent of
SSP, but I agree that the current wording of the document gives the
impression that it is mandating a use of the data rather than just
providing information and it could be clearer about that fact (the
existence of the handling tags doesn't help here). To clarify this
point a little more it is not even the sender who would be making this
assertion, but the domain owner.

Assuming we can make it clear that the domain owner's role is simply to
provide information and that receivers will make use of that
information or not however they decide it best serves their users then
I still think this is a good policy to be expressible.

> likely to be useful than statements about things that they don't.

I have got to disagree here. I think most cases where domain owners are
likely to be able to make a "strict" assertion that information is
likely to be extremely helpful. And if someone makes that assertion
erroneously and I don't have enough information to make a decision
independent of SSP and the mail is transmitted via someone who I don't
trust to sign messages on behalf of others then it seems really
unlikely that 

I'm going to miss that mail.

Robert

---

From: <[email-masked]>
Date: Wed, 23 Jan 2008 16:23:11 +0000

> Date: Tue, 22 Jan 2008 11:16:31 -0800
> From: [email-masked]

> long as we can characterize them and convince ourselves that they will benefit.

As is the case with pretty much any type of policy publication there are both publishers and consumers of that information. I think I could readily characterize instances where a domain owner could accurately publish a "strict" policy for their domain, both from personal experience and from the set of senders/domain ownders I regularly work with. That's clearly not the whole internet but would represent at least on constituency on the publishing side. Characterizing the consumer side accurately is slightly harder because this data is supplementary to whatever people already do and I don't think this data can really be accurately viewed in a vacuum but still should not be an insurmountable problem.

Are you looking for descriptions of one of the above, both, or the interaction between the two? 

> (just to make sure:  "by me" means "by the same domain as listed in the author 
Yes, sorry resorted to  putting myself in the place of a domain owner publishing a policy rather than remaining in the third person. The "me" refers specifically to the owner or administrator of the domain which appearts in the author field.

> mail claiming that authorship.  There is not need to state the implication 

Yes, that's true, but that implication is not the same as John's characterization of this statement as saying "I am a phish target". The implication I would get from that is if you get a piece of unsigned mail, or mail signed by someone other than that domain that it was not validly authored by that domain. That encompasses more possibilities than just "I am a phish target" and still requires that the receiver make a decision about whether they care that the mail was not validly authored by that domain given the information they have available about both the source that transmitted it to them, and the source that actually did sign the mail.

Robert

---

From: Douglas Otis <[email-masked]>
Date: Wed, 23 Jan 2008 12:26:11 -0800

On Jan 22, 2008, at 10:42 PM, Jim Fenton wrote:

> address case as in the single From address case.  That is issue  
> #1519, and let's discuss it in the context of that issue.

Jim,

You are missing the point.  The requirements created by the Author  
Signature definition is breaking email semantics.  This problem exists  
whether the SSP process depends upon policy being obtained from the  
first or all email-address domains within the From header.  The  
suggested solution was to have signatures with a domain at or above  
the domain of the From address in question to provide "all" or  
"strict" compliance.  (An exception would need to be made only for g=  
restricted keys.)  By depending upon just the _domain_, a signature  
could be on-behalf-of the Sender header, or any other header for that  
matter, and provide SSP compliance.  Basing compliance upon just the  
domain avoids semantic problems created when a Sender entity  
introduces the message, rather than the From entity.

> number of From address domains that should be checked, because RFC  
> 2822 doesn't specify a limit.  As a practical matter, some verifiers  
> may decide to impose their own limits, and I don't think that  
> introduces a problem with "interchange".  SSP is really about giving  
> additional information to the verifier, and if they decide not to  
> avail themselves of all of the information available, that's up to  
> them (as is the decision whether they want to use SSP information at  
> all).

Whenever a verifier decides there are too many From domains to bother  
discovering all the SSP records, it MUST treat this message as having  
failed SSP compliance.  Otherwise, additional From email-addresses  
would be a means to bypass SSP policies.  This also means you are  
suggesting there be some undefined limit that might then cause email  
to be rejected.  Valid mail rejected as a result of an undefined limit  
must be described as an interchange problem.

If the WG has the brass to say all From email-addresses should have  
their SSP records discovered, the WG should also define a minimum  
number of email-addresses where interchange is assure.  EAI has  
defined the use of two From addresses to permit alternative formats.   
With the introduction of non-ASCII TLDs, these alternative formats  
might become required, as ACE labels may not be displayed.

Set the From email-address minimum maximum at 2, 4, or 6.  SSP policy  
established by just the first domain without imposing a limit on the  
number of From email-addresses would also be acceptable.  Recipients  
must understand what element of the message is being protected.  This  
protection is easier to explain as being for just the "first" email- 
address domain.  Saying the first two would make a signature  
indication less informative.

-Doug

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 29 Jan 2008 12:52:57 -0500

Sorry for the very late posting. I realize there are lots of replies to
this, but I have trouble keeping thoughts straight after reading a long
thread, so I'll just add my 2 cents now:

On Wed, Jan 16, 2008 at 09:46:26AM -0800, Dave Crocker wrote:
<snip>

> In any event, "on behalf of" is key wording that permits more flexibility 
> than you seem to be acknowledging.  Note, for example, that the agent 
> specified in the Sender field is acting "on behalf of" the author.

Is that agent authorized to work "on behalf of" the author?

> unsigned message should have been signed, it has morphed into an effort to 
> validate the From field.  That is a very, very different goal.
>
> While DKIM has the goal of assigning *any* identity to a message, so that 
> that identity can be assessed, the current work on SSP is attempting to 
> instead validate authorship.

DKIM needs to say what part of DKIM asserts a new identity. What is the
output of DKIM? And should that output be treated as opaque.

-- 
:: 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

---

From: Dave Crocker <[email-masked]>
Date: Tue, 29 Jan 2008 10:41:05 -0800

Jeff Macdonald wrote:
>> In any event, "on behalf of" is key wording that permits more 
>> flexibility than you seem to be acknowledging.  Note, for example, 
>> that the agent specified in the Sender field is acting "on behalf of" 
>> the author.
> 

Seems so:

   <http://www.bartleby.com/64/C003/0169.html>

> output of DKIM? And should that output be treated as opaque.

Yup.

d/

-- 

   Dave Crocker

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 29 Jan 2008 14:00:18 -0500

>[mailto:[email-masked]] On Behalf Of Dave Crocker
>Sent: Tuesday, January 29, 2008 1:41 PM
>To: Jeff Macdonald
>Subject: Re: [ietf-dkim] Re: ISSUE 1525 -- Restriction to 
>posting by firstAuthor breaks email semantics
>
>
>
>Jeff Macdonald wrote:

"Seems so" is exactly the correct phrase..... because we don't really
know - and currently can't generally know - whether the claim of agency
by the identity in the sender field is an authorized, and thus valid
claim.....

Signed on behalf of Dave Crocker by Michael Hammer

---

From: Dave Crocker <[email-masked]>
Date: Tue, 29 Jan 2008 11:22:03 -0800

> Signed on behalf of Dave Crocker by Michael Hammer

Yup. Almost makes one wish that one knew the reputation of Michael Hammer, 
doesn't it?

In fact, the reputation of Dave Crocker is probably irrelevant for this situation...

And, yes, one could start with Crocker's reputation and go through some sort of 
formal delegation mechanism, but that's more complicated and it ignores the 
potential for independent action that this Hammer fellow retains.  So no matter 
what Crocker delegates, one is left needing to know something about Hammer.

d/

-- 

   Dave Crocker

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 29 Jan 2008 14:30:41 -0500

>From: Dave Crocker [mailto:[email-masked]] 
>Sent: Tuesday, January 29, 2008 2:22 PM
>To: MH Michael Hammer (5304)
>> know - and currently can't generally know - whether the claim of 
>> agency by the identity in the sender field is an authorized, 
>and thus 
>> valid claim.....
>> 
>> 
>Yup. Almost makes one wish that one knew the reputation of 
>Michael Hammer, doesn't it?
>

Are we sure that reputation is the issue? If we could look somewhere and
determine whether Dave Crocker allows anyone to act as his agent then we
can determine whether the claim of agency is valid without having to
worry about Michael Hammers reputation. 

>In fact, the reputation of Dave Crocker is probably irrelevant 

And so too is the reputation of Michael Hammer. Why rely on reputation
when one can get a direct answer?

>And, yes, one could start with Crocker's reputation and go 
>through some sort of formal delegation mechanism, but that's 
>more complicated and it ignores the potential for independent 
>action that this Hammer fellow retains.  So no matter what 
>Crocker delegates, one is left needing to know something about Hammer.
>
>d/
>

This Hammer fellow can do whatever he wants but that doesn't and
shouldn't involve Dave Crocker if Dave Crocker doesn't care to be
dragged into it. It has nothing to do with reputation. Your assertion is
almost like someone listening to the neighbor that says it's ok to go
pick Hammers apples despite Hammer having put up a no trespassing sign.
I haven't raised the formal delegation (positive) situation - I have
only raised the "I don't delegate agency to anyone" (negative)
situation. Not very complicated at all. 

There may be value in including a formal delegation capability but that
is another discussion.

Mike

Mike

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 29 Jan 2008 14:31:01 -0500

>   <http://www.bartleby.com/64/C003/0169.html>

I guess I wasn't clear. A Bad Actor can decide to be an agent to work
"on behalf" any other. It doesn't mean he was authorized to do so.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 29 Jan 2008 11:31:01 -0800

On Jan 29, 2008, at 9:52 AM, Jeff Macdonald wrote:
>> that the agent specified in the Sender field is acting "on behalf  
>> of" the author.
>

When the author's email-address domain is within (applying the key's  
g= and t= restrictions) the domain of the signature on-behalf-of the  
sender (per i=), the signature is authoritative for the author's  
domain.  By signing the message, the author's domain confirms the  
message meets their signing policies.  As such, the signing domain has  
indicated their authorization of the Sender in this case.

What sense would it make for an SSP assertion to declare valid  
signatures of the very domain to be non-compliant?

>> goal.
>> While DKIM has the goal of assigning *any* identity to a message,  
>> so that that identity can be assessed, the current work on SSP is  
> DKIM needs to say what part of DKIM asserts a new identity. What is  
> the output of DKIM? And should that output be treated as opaque.

In general, the i= parameter should be considered independent of SSP  
policies (an exception may be made for g= restricted keys).  For  
unrestricted keys, only the d= parameter needs to be assessed.   
Unfortunately, the scope of a signature has been complicated.  A  
signature's scope can be restricted with g= and t= parameters within  
the key.

The i= parameter should be generally considered independent of SSP  
policies.  Whether the i= parameter is on-behalf-of a particular  
header is a separate matter.  Any on-behalf-of identity indication  
conveyed to the recipient must ensure this information is included  
within the signature's hash.  This information must also be within the  
key's g= and t= parameters.  A signing domain can have the signature's  
i= parameter assert on-behalf-of to convey who introduced the  
message.  This identity might be opaque and not match with any  
existing headers.  This might be done to retain the privacy of the  
entity introducing the message.

-Doug

---

From: "Siegel, Ellen" <[email-masked]>
Date: Tue, 29 Jan 2008 14:44:07 -0500

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of MH Michael Hammer (5304)
> Sent: Tuesday, January 29, 2008 2:31 PM
> To: [email-masked]
> Subject: RE: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting
> byfirstAuthor breaks email semantics
> 
> 
> 

Just because it is possible to abuse a particular configuration doesn't
mean that the configuration is inherently invalid. If that were true,
then none of us would be willing or able to send any email at all. 

Yes, it's possible to come up with scenarios that involve abuse, but
there are at least as many that are legitimate, i.e. where the sender is
truly sending on behalf of the author and with their express consent. 

The goals behind SSP are laudable, but from where I sit I see relatively
few domains that lock down their email sufficiently to reasonably be
able to deny their individual account holders the right to use their
address as they desire. Yours may well be one of these, but please don't
assume that because it works for you therefore it should be applied
across the board to everyone. 

Ellen

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 29 Jan 2008 20:43:15 +0100

> Signed on behalf of Dave Crocker by Michael Hammer

Yes, let Michael Hammer and Dave Crocker fight it
out if they disagree.  RFC 822 lists both From and
Sender as <authentic>.

 Frank

---

From: Dave Crocker <[email-masked]>
Date: Tue, 29 Jan 2008 12:02:29 -0800

> "on behalf" any other. It doesn't mean he was authorized to do so.

And being authorized doesn't make them a Good Actor...

Further, DNS delegation takes care of the authorization question, since it 
subsumes the actor explicitly and directly under the name (and reputation) of 
the delegator.  No additional (sub-)mechanism is needed in another specification 
to accomplish this. The DNS-based approach is therefore simpler and 
well-established.

Whatever the claims about DNS administrative effort, they cannot be better for a 
new mechanism that has no history and requires the same level of maintenance.

d/

-- 

   Dave Crocker

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 29 Jan 2008 16:36:44 -0500

>From: Siegel, Ellen [mailto:[email-masked]] 
>Sent: Tuesday, January 29, 2008 2:44 PM
>To: MH Michael Hammer (5304); [email-masked]
>Subject: RE: [ietf-dkim] Re: ISSUE 1525 -- Restriction to 
>posting byfirstAuthor breaks email semantics
>
>
>
>Just because it is possible to abuse a particular 
>configuration doesn't mean that the configuration is 
>inherently invalid. If that were true, then none of us would 
>be willing or able to send any email at all. 
>
>Yes, it's possible to come up with scenarios that involve 
>abuse, but there are at least as many that are legitimate, 
>i.e. where the sender is truly sending on behalf of the author 
>and with their express consent. 
>

So where is the problem? The author (account holder) uses that email
address at the pleasure of the domain owner. Most domains that provide
accounts have some sort of Terms of Service. So unless you are willing
to assert that domain owners have no right to decide how accounts at
their domains will be used, it is implicit that domain owners have the
right to tell a user...you may only send through authorized servers.
Many domains may choose not to implement or publish such a strong
policy. 

If the domain owner doesn't have a problem with the author (account
holder) sending unsigned email from other domains, why should I...or
anyone else for that matter? 

>The goals behind SSP are laudable, but from where I sit I see 
>relatively few domains that lock down their email sufficiently 
>to reasonably be able to deny their individual account holders 
>the right to use their address as they desire. Yours may well 
>be one of these, but please don't assume that because it works 
>for you therefore it should be applied across the board to everyone. 
>

That's the point. For those domains that do want to lock down their
email, it works. For those domains that do not wish to lock down their
email it works. Nobody has claimed that locking down DKIM signing works
across the board for every domain owner or author. 

Mike

---

From: Douglas Otis <[email-masked]>
Date: Tue, 29 Jan 2008 14:29:33 -0800

On Jan 29, 2008, at 12:02 PM, Dave Crocker wrote:
>> I guess I wasn't clear. A Bad Actor can decide to be an agent to  
>> work "on behalf" any other. It doesn't mean he was authorized to do  
>> so.
>

Agreed.

> Further, DNS delegation takes care of the authorization question,  
> since it subsumes the actor explicitly and directly under the name  
> (and reputation) of the delegator.  No additional (sub-)mechanism is  
> needed in another specification to accomplish this. The DNS-based  
> approach is therefore simpler and well-established.
>
> Whatever the claims about DNS administrative effort, they cannot be  
> better for a new mechanism that has no history and requires the same  
> level of maintenance.

Strongly disagree.

Key exchanges might be a method to delegate DKIM signing to third- 
parties.  Unless an ad-hoc private key exchange is employed,  
redirection or delegation will not provide a means to restrict the  
scope of a DKIM key.  However, ad-hoc private key exchange is neither  
safe, simple, or well-established.

Private key exchanges or public key redirection obfuscates who handled  
the message.  DKIM servers contain private keys that, if exposed,  
might compromise thousands of other domains when DKIM keys are used as  
a method for delegating message handling to third-parties.  If such an  
exposure were to occur, who actually handled the message becomes  
critical.  However, private key exchanges or public key redirection  
necessitates a number of forensic details be reported before others  
will be able to assess who handled the message.  The potential scope  
of these details may also make reporting these security breaches  
impractical.

With many methods where DKIM key delegation might be achieved, and the  
number of DKIM specific key details involved, DKIM public key  
redirection should not be described as either simple or well- 
established.  Attempting to redirect public keys using DNS requires  
two or more administrative entities to routinely co-ordinate the  
details they publish.  Details that coincide with specific real-time  
DKIM message handling across multiple administrative domains.  Such a  
complex system can not be described as simple.  With respect to DKIM,  
public key redirection as a third-party message handling delegation  
method on a large scale is not well-established either.  If adopted as  
a solution by large providers, public key redirection also creates  
significant security issues.

On the other hand, TPA-SSP provides a method where third-party  
delegation is handled autonomously and without any exchange of keys.   
Although TPA-SSP makes use of DNS, each administrative entity is able  
to publish information without co-ordination with specific real-time  
message handling within different administrative domains.  In  
addition, the TPA-SSP third-party authorization does not require  
periodic modification, as will DKIM key publications.  There is little  
to suggest that DKIM public key redirection or ad-hoc DKIM key  
exchange is not a disaster in the waiting.  In addition, other  
applications beyond email may attempt to utilize these keys for other  
purposes.

The motivation behind DKIM was to establish a responsible domain to  
enable correction of various types of abuse.  Has this goal changed?   
Anything that obfuscates who the responsible domain introducing the  
message is diminishes that effort.  IMHO, SSP should standardize a way  
to signal a domain's use of the TBD TPA-SSP.  Other than that, SSP can  
remain unchanged.  However, third-party delegation by way of key  
redirection or exchanges should be strongly discouraged.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 30 Jan 2008 11:18:08 -0000

On Tue, 29 Jan 2008 17:52:57 -0000, Jeff Macdonald  
<[email-masked]> wrote:

>> flexibility than you seem to be acknowledging.  Note, for example, that  
>> the agent specified in the Sender field is acting "on behalf of" the  
>> author.
>

That is what the person who actually sent it is claiming.

A well-organized 1st party signer will not sign anything that did not  
originate within is domain, and containing a From/Sender within bis domain.

So if the Sender is in his domain, then he ought to establish that is  
where it came from, and then include that header within his signature.

But, in that case, he really needs some mechanisn to be able to say, in  
his SSP, that "we check and sign Sender headers where present". Ditto for  
Resent-From and Resent-Sender.

BTW, would it be useful for a signature to contain some feature to  
indicate whether it claimed to be a 1st/2nd/3rd/whatever-party signature?

---

From: Hector Santos <[email-masked]>
Date: Wed, 30 Jan 2008 07:55:41 -0500

> indicate whether it claimed to be a 1st/2nd/3rd/whatever-party signature?

I believe the following proposal was stamped as issue #1542.

     http://mipassoc.org/pipermail/ietf-dkim/2008q1/008816.html

Understanding the sensitive nature of this, I will try to propose this
delicately.

Proposal:

DKIM signing domains who wish to implement restrictive signing policies
such as DKIM=STRICT or ALL and have a desire for verifiers to
aggressively handle this policies, SHOULD consider adding a SSP=STRICT
or SSP=ALL tag to the DKIM-BASE key record.

The goal is to reduce verifier DNS overhead by short circuiting the SSP
discovery steps 2/3 which is only necessary when the transaction state is:

   a) valid 3rd party signature, or
   b) no signature which can result from a broken signature.

The following sub-steps should be added to step 1:

   1a) If we have a valid 3rd party signature or no signature resulting
       from a failed DKIM-signature validation, and the key record
       contains a tag SSP=strict, then the message is Suspicious and
       the algorithm terminates.

   1b) If we have no signature resulting from a failed
       DKIM-signature validation, and the key record contains
       a tag  SSP=ALL, then the message is Suspicious and the
       algorithm terminates.

If no SSP= tag is present in the DKIM key record, the verifier should
continue with step 2.

Discussion:

I believe Jim agreed that this would "reduce the number of SSP lookups a
bit" however, he felt this may be an implementation or deployment
consideration and/or we might review this after the initial SSP-01
specification is completed.  He also correctly indicated with a less
concern, there would still be a need for an SSP record and now a dual
management of SSP; A SSP= tag for the DKIM key record, and a SSP record
  itself.  The policy  in both places must match.

I agree with all Jim's point.

However, in the effort need to make SSP viable, acceptable, less
complex, its usefulness well understood for consideration, and
hopefully, we can get it to a point where everyone is the same page,
then considerations like this should be put on the table now.

If many domains (which I believe they will be many) will be considering
DKIM with the intent to operate in strict or all signing mode, we could
lose the opportunity to correctly and efficiently deploy the combination
of DKIM and SSP to everyone's benefit and satisfaction.

If we don't wish to consider this now, I can see an I-D proposing an
update to RFC 4871 to add the SSP=strict|all tag.  Is that the better
approach?

Follow up comment:

This proposal will also help make this multiple From: issue a moot point.

-- 
Sincerely

Hector Santos, CTO

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 30 Jan 2008 09:46:56 -0500

> originate within is domain, and containing a From/Sender within bis domain.

Ah, I thought were were talking about the case where there isn't a
signature for the domain that is present in the From: header, but just
the Sender: header. Additionally the domains for those two headers
would be different.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 30 Jan 2008 09:57:02 -0800

On Jan 30, 2008, at 3:18 AM, Charles Lindsey wrote:

> On Tue, 29 Jan 2008 17:52:57 -0000, Jeff Macdonald <[email-masked] 
> > wrote:
>
> A well-organized 1st party signer will not sign anything that did  
> not originate within is domain, and containing a From/Sender within  
> bis domain.
>
> So if the Sender is in his domain, then he ought to establish that  
> is where it came from, and then include that header within his  
> signature.
>
> But, in that case, he really needs some mechanisn to be able to say,  
> in his SSP, that "we check and sign Sender headers where present".  
> Ditto for Resent-From and Resent-Sender.
>

SSP should be applied only when there are _no_ valid signatures  
encompassing the identities in question by the domain in question.   
When the key used to sign the message is not restricted from  
encompassing the From email-address in question, there is _no_ reason  
to question whether this identity is complaint with the signing  
domain's policy.  The domain signed it, so therefore it MUST be  
compliant!

There is no need to check SSP in these cases.  Doing so represents  
wasted overhead and adds undue complexity.  Why create a list of  
semantic corner cases for anyone claiming to use RFC 4871 to sign all  
messages?  Why should SSP change how RFC 4871 is to be used?  Why  
should SSP require a domain to add ambiguous or falsified signatures  
only to satisfy SSP convoluted requirements for what constitutes a  
compliant signature?

The easy solution would be a statement that by signing the message,  
all headers containing identities within the scope of the key and  
within the signature's hash will be considered complaint whenever  
their signature is found to be valid.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 31 Jan 2008 14:15:49 -0000

> the Sender: header. Additionally the domains for those two headers

Agreed. If the Sender domain was already one of the From domains, there is  
no need to consider it further.

But suppose that there were 4 From addresses, from domains which published  
no SSP. But for some reason the 4 authors had engaged someone from domain  
E to Send it for them. Suppose E publishes a strict SSP. Then they are  
going to sign it on the way out, and so it is a 1st party signature.

The verifier sees the valid signature and is puzzled because it does not  
relate to any of the Froms; he looks for SSP, and there is none for those  
Froms. Is it a 1st or 3rd party signature (for some reason he likes to  
know which it is)? Then he looks closer and discovers that it was indeed  
Sent from the domain that signed it, which has a strict SSP (plus a good  
reputation). So maybe that makes him happier, especially if we provide a  
mechanism in SSP for E to say "we sign Sender headers where appropriate".

So for sure we could build that into SSP if we wanted to.

I agree that I can't think of anything the Bad Guys might that do would be  
spotted due to an unsigned Sender header, but you never know what Bad Guys  
are going to dream up next :-( .

And note that this thread started with Dave asking what a Sender header  
actually "meant", presumably with the intent of enquiring what mechanisms  
we were providing that might increase confidence in that meaning.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 31 Jan 2008 12:42:04 -0500

>[mailto:[email-masked]] On Behalf Of Charles Lindsey
>Sent: Thursday, January 31, 2008 9:16 AM
>To: DKIM
>But suppose that there were 4 From addresses, from domains 
>which published no SSP. But for some reason the 4 authors had 
>engaged someone from domain E to Send it for them. Suppose E 
>publishes a strict SSP. Then they are going to sign it on the 
>way out, and so it is a 1st party signature.
>

By what mechanism do you know that the 4 authors (from addresses)
engaged someone from domain E? We currently have no way of knowing that
across domains other than the fact that the person from domain E claims
it.

>The verifier sees the valid signature and is puzzled because 
>it does not relate to any of the Froms; he looks for SSP, and 
>there is none for those Froms. Is it a 1st or 3rd party 
>signature (for some reason he likes to know which it is)? Then 
>he looks closer and discovers that it was indeed Sent from the 
>domain that signed it, which has a strict SSP (plus a good 
>reputation). So maybe that makes him happier, especially if we 
>provide a mechanism in SSP for E to say "we sign Sender 
>headers where appropriate".
>

What about the cases where domain E has no reputation? 

>I agree that I can't think of anything the Bad Guys might that 
>do would be spotted due to an unsigned Sender header, but you 
>never know what Bad Guys are going to dream up next :-( .
>
>And note that this thread started with Dave asking what a 
>Sender header actually "meant", presumably with the intent of 
>enquiring what mechanisms we were providing that might 
>increase confidence in that meaning.
>

Unless there is a mechanism for showing that Sender (from a domain other
than that of From) has been authorized to send on behalf of From then it
can only be considered an arbitrary assertion (that may or may not be
true) by sender. Upon reviewing RFC822 it is interesting to note in
section 4.4.2 2 use cases are indicated:

1) It is intended for use when the sender is not the author of the
message,  or  
2) to  indicate who among a group of authors actually sent the message.

There is nothing that states that sender is authorized by the purported
authors unless it is case #2 where sender is one of the authors of the
message. Even case #2 provides no way of determining
authorization....only "indication" which is at best a weak thing to hang
ones hat on.

When we look at the examples given in A.2.  ORIGINATOR ITEMS, we see
that none of the examples include an example where the sender is from a
different FQDN than the author.

If we look to RFC2822 for guidance we don't get much more help at all.
Although the example given in A.1.1. shows Sender and uses FQDN, both
>From and Sender are within the same domain.

The only thing that can be gleaned from reviewing the RFCs is that if
there is a Sender field then that is the claim of origination. There is
no claim of authorization that is recognized within the RFCs that can be
meaningfully applied when the domain of Sender is not the same as the
domain of From. The RFCs do not preclude us from comparing From and
Sender fields to determine authorization. They simply don't discuss it.
That being the case, in the context of SSP, what makes sense? Which
"voice" do we consider? Where competing claims might be made are
reputation systems the only way to decide? Should the direct assertion
of the owner of a domain be considered authoritative for that domain? 

In past discourse with Dave I have used the terms "spoofed" and forged"
to describe mail where an originator of email puts an email address in
the From field that is not within their domain. Dave was not happy with
applying those terms because of connotations that may not be applicable.
Dave suggested using the term "independent" to describe this situation.
My response was to suggest the following:

First Person: User of email address is sending through mail server of
domain of the email address.

Second Person: User of email address is sending through a mail server
not of the domain of the email address but is the specific initiator of
the email message. An example of this might be a person walking up to a
public internet kiosk and sending mail using their own email address but
the server of the kiosk provider.

Third Person: Third party (domain) is sending an email that uses the
email address of the user of the email address but the sent email was
not directly initiated and injected by the "user". 

Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 31 Jan 2008 10:40:03 -0800

On Jan 31, 2008, at 6:15 AM, Charles Lindsey wrote:

> On Wed, 30 Jan 2008 14:46:56 -0000, Jeff Macdonald <[email-masked] 
> > wrote:
>
>>>>> flexibility than you seem to be acknowledging.  Note, for  
>>>>> example, that the agent specified in the Sender field is acting  
>>>>> "on behalf of" the author.
>>>>
>>> not originate within is domain, and containing a From/Sender  
>>> within bis domain.
>>
> Agreed. If the Sender domain was already one of the From domains,  
> there is no need to consider it further.

Agreed.

> But suppose that there were 4 From addresses, from domains which  
> published no SSP. But for some reason the 4 authors had engaged  
> someone from domain E to Send it for them. Suppose E publishes a  
> strict SSP. Then they are going to sign it on the way out, and so it  
> is a 1st party signature.

Disagree.  The concept of 1st Party signature would be with respect to  
the From email-address.  In other words, SSP assurance is limited to  
policy statements regarding email-addresses found within the From  
domain.  When a signature is signed on-behalf-of the Sender header  
(i=) using a key that could encompass that of the From email-address  
(g= t=) in question, the signature alone verifies the signing domain's  
policy.  When the From email-addresses do not reference SSP records,  
and the signature on-behalf-of the Sender does not encompass the From  
address, this signature represents that of a Third-Party.

> The verifier sees the valid signature and is puzzled because it does  
> not relate to any of the Froms; he looks for SSP, and there is none  
> for those Froms. Is it a 1st or 3rd party signature (for some reason  
> he likes to know which it is)? Then he looks closer and discovers  
> that it was indeed Sent from the domain that signed it, which has a  
> strict SSP (plus a good reputation). So maybe that makes him  
> happier, especially if we provide a mechanism in SSP for E to say  
> "we sign Sender headers where appropriate".

While this check can be made, checking email-addresses found in  
different headers will likely have little benefit, but that might  
depend upon the MUA/OS being used.  Outlook will show the From as the  
"on behalf of" following the Sender's address.  The virtual From  
header is to support the PRA validations.  This might open the door  
for Sender header spoofing, but this will also increase the overhead  
involved with checking SSP.  Consider that most email is not signed.

> So for sure we could build that into SSP if we wanted to.

No need when "all" or "strict" is complaint where just the signature's  
domain and key qualify a valid signature.

> I agree that I can't think of anything the Bad Guys might that do  
> would be spotted due to an unsigned Sender header, but you never  
> know what Bad Guys are going to dream up next :-( .

Perhaps.

> And note that this thread started with Dave asking what a Sender  
> header actually "meant", presumably with the intent of enquiring  
> what mechanisms we were providing that might increase confidence in  
> that meaning.

Ignoring the i= parameter found within the signature represents the  
simplest way to address this concern.  This then allows verifiers, at  
their discretion, to check the policy of any email-address.

-Doug

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 31 Jan 2008 20:31:44 +0100

MH Michael Hammer (5304) wrote:

> engaged someone from domain E?

By definition (in RFC 822).

> We currently have no way of knowing that across domains other
> than the fact that the person from domain E claims it.

Yes, but you only somebody you wish to hold responsible, and if
E signed it you have someone.  If nobody signed it, with E's SSP
saying "strict signer", you can reject it.

It's a semantical matter, do you want to protect senders (as the
name SSP suggests) or authors (in conflict with e-mail practice).
For the typical case one From, no Sender, there's no difference. 

> What about the cases where domain E has no reputation?

Same problem as a PASS "From: A" (no B, C, D, E).
 
> There is nothing that states that sender is authorized by the
> purported authors unless it is case #2

| originator  =   authentic                   ; authenticated addr
|                 [ "Reply-To"   ":" 1#address] )
|
| authentic   =   "From"       ":"   mailbox  ; Single author
|             / ( "Sender"     ":"   mailbox  ; Actual submittor
|                 "From"       ":" 1#mailbox) ; Multiple authors
|                                             ;  or not sender

You could ask Dave what "authenticated addr" for <authentic> was
supposed to mean back in 1982 ;-)  The sender is the "submittor"
of the mail - not necessarily to SMTP, the envelope sender can
be different in e.g. UUCP -> UUCP gateway SMTP -> SMTP scenarios.

 Frank