Subject: [ietf-dkim] What is your view on these three SSP topics?

From: Douglas Otis <[email-masked]>
Date: Mon, 21 Jan 2008 18:32:28 -0800

As SSP is currently defined, a restricted or unrestricted key must be  
on-behalf-of the From header to be compliant with SSP "strict".

1) To be SSP "strict" or "all" compliant, the identity associated with  
a signature:

a) must match an email-address within the From header.

b) must match an email-address associated an entity introducing the  
message contained within the following headers:

    From, Sender, Resent-From, Resent-Sender.

c) may not match with any header and may not be defined.

d) may not match with any header and may not be defined except for SSP  
"strict" which is limited to not being defined or matching the first  
email-address within the From. (as currently defined)

The number of DNS transactions required to support SSP is affected by  
the number of From email-addresses being protected.  Currently SSP is  
defined to reference SSP only for the first From email-address.

2) SSP references should be done for:

a) Only the first From email-address. (as currently defined)

b) All From email-addresses.

c) More than one From email-address is not be SSP compliant and is to  
be considered to produce an invalid signature.

d) More than two From addresses is not be SSP compliant and is to be  
considered to produce an invalid signature.  When two From addresses  
are used, both domains should be checked for SSP compliance.

RFC 4871 Section B.1.1 4th paragraph makes this statement:

[An outsourcing company can supply g= restricted keys] "using a unique  
selector that authorizes a specific From header field Local-part.  For  
example, a client with the domain "example.com" could have the  
selector record specify "g=winter-promotions" so that this signature  
is only valid for mail with a From address of "[email-masked] 
"."

This comment is within the appendix and there is nothing within RFC  
4871 nominative section that limits use of a g= restricted keys to the  
just the From header, although this seems implied by section B.1.1.

Currently SSP is defined where g= restricted keys are compliant with  
"all".

3) Keys restricted by a g= parameter are treated as valid and are:

a) SSP "all" or "strict" compliant only when on-behalf-of a From  
header email-address.

b) SSP "all" or "strict" compliant regardless of the identity signed  
on-behalf-of.

c) SSP "strict" compliant only when on-behalf-of the first From header  
email-address. (as currently defined)

1-c

2-d

3-a

-Doug

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 22 Jan 2008 11:12:22 -0000

On Tue, 22 Jan 2008 02:32:28 -0000, Douglas Otis <[email-masked]>  
wrote:

> 1) To be SSP "strict" or "all" compliant, the identity associated with a  
> signature:
>
+1
>     From, Sender, Resent-From, Resent-Sender.
+1
> c) may not match with any header and may not be defined.
+0
> email-address within the From. (as currently defined)
-1

Add:
   e) Each entity with a "strict" or "all" SSP within the following headers
       From, Sender, Resent-From, Resent-Sender
   must be matched by an associated signature (if, in some complicated case,
   this requires the presence of several signatures, then so be it).
+2

> a) Only the first From email-address. (as currently defined)
-1
> b) All From email-addresses.
+1

Add:
   bb) All From email-addresses PLUS the Sender address, if any
+2
>
> c) More than one From email-address is not be SSP compliant and is to be  
> considered to produce an invalid signature.
-1
> considered to produce an invalid signature.  When two From addresses are  
> used, both domains should be checked for SSP compliance.
-1

> a) SSP "all" or "strict" compliant only when on-behalf-of a From header  
> email-address.
+1

Add:
   a) SSP "all" or "strict" compliant only when on-behalf-of a From, Sender,
   Resent-From or Resent-Sender header email address.
+2
> b) SSP "all" or "strict" compliant regardless of the identity signed  
-1
> email-address. (as currently defined)
-1

-- 
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: "Siegel, Ellen" <[email-masked]>
Date: Tue, 22 Jan 2008 10:11:51 -0500

You all seem very comfortable saying that for all or strict a signature that doesn't match one of the designated message headers is automatically non-compliant, and that the message itself is non-compliant if that signature is the only one on the message. 

There's a fair bit of mail out there that doesn't fit this scenario, i.e. which is signed by an entity other than those in the designated headers. 

Are you assuming that it's fine for that mail to be treated as suspicious/non-compliant, or that any domains for which this may be the case will never publish SSP records? I suspect that by the time you eliminate all domains that may have this problem you won't be left with very many that can safely publish SSP records, so either a lot of valid mail will be going into the bit-bucket or hardly anyone will be able to safely use SSP.

Ellen

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Charles Lindsey
> Sent: Tuesday, January 22, 2008 6:12 AM
> To: DKIM
> Subject: Re: [ietf-dkim] What is your view on these three SSP topics?
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 22 Jan 2008 15:41:23 +0000

> There's a fair bit of mail out there that doesn't fit this scenario, i.e. which is signed by an entity other than those in the designated headers. 

If there are data available demonstrating this, that would be good to
see.

Stephen.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 22 Jan 2008 08:36:41 -0800

Stephen Farrell wrote:
>> There's a fair bit of mail out there that doesn't fit this scenario, 
>> i.e. which is signed by an entity other than those in the designated 
>> headers. 
> 

Stephen, that requirement needs to work both ways.

It is, for example, why I noted that SSP needs a real and separate threat 
analysis, and statement about the scenarios it applies to and those it does not.

d/

-- 

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 22 Jan 2008 17:08:45 +0000

> Stephen, that requirement needs to work both ways.

Just to clarify. I wasn't trying to impose any requirement. If
such data exist and can be made available that may well help us
to make decisions. If it doesn't exist, is hard to gather or
commercially sensitive or whatever, then we'll have to live with
that and do our best.

 > It is, for example, why I noted that SSP needs a real and separate
 > threat analysis, and statement about the scenarios it applies to and >
 > those it does not.

Sure. Those are fine, but different, things.

S.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 22 Jan 2008 11:43:43 -0800

On Jan 22, 2008, at 3:12 AM, Charles Lindsey wrote:

> On Tue, 22 Jan 2008 02:32:28 -0000, Douglas Otis <dotis@mail- 
> abuse.org> wrote:
>>
>> 1) To be SSP "strict" or "all" compliant, the identity associated  
>> with a signature:
[...]
>> d) may not match with any header and may not be defined except for  
>> SSP "strict" which is limited to not being defined or matching the  
>> first email-address within the From. (as currently defined)
> -1
>
> Add:

What benefit is derived by imposing an explicit i= parameter  
requirement on an originating header for "all" or "strict" compliance?

RFC 4871 does not require signatures to identify specific entities,  
and may produce ambiguous signatures lacking an i= local-part.

For SSP to impose a requirement that signatures _MUST_ identify  
specific entities is beyond the WG charter.

A solution to assure compatibility with RFC 4871 would be 1-c.

> bb) All From email-addresses PLUS the Sender address, if any

How many From email-addresses should be allowed?

What benefit is derived imposing policy for Sender headers?

Would a From header referenced policy override a Sender header  
referenced policy?

Currently, a small percentage of emails are signed using DKIM.  Sender  
header policy requirements substantially increases overhead related to  
SSP.

> Resent-From or Resent-Sender header email address.

Allowing compliance with headers other than From permits a holder of a  
g= restricted key to sign a message purporting to be "From" anyone  
within the signing domain.  In other words, g= restricted keys would  
be of little value for protecting recipients with existing MUAs.

A solution where g= restricted keys can not be abused would be to  
preclude compliance for any header other than From.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 23 Jan 2008 12:51:17 -0000

>
> What benefit is derived by imposing an explicit i= parameter requirement  
> on an originating header for "all" or "strict" compliance?

I don't know, but what has that got to do with my suggestion above?
>
> RFC 4871 does not require signatures to identify specific entities, and  
> may produce ambiguous signatures lacking an i= local-part.

A signature identifies a domain. By implication, it identifies  
any-local-part@that-domain.
>
> For SSP to impose a requirement that signatures _MUST_ identify specific  
> entities is beyond the WG charter.

And nobody has suggested any such thing. Please look at my proposed  
additional "e)".

You (a verifier) see a bunch of addresses in a bunch of  
From/Sender/Resent-From/Resent-Sender headers.

You also see a bunch of valid signatures on behalf of an assortment of  
domains.

So you look through the domains that are signed for, and you tick off all  
the addresses in all those headers that contain those domains (well, maybe  
only for the headers explicitly covered by the signature, where "From" is  
alwys covered, of course).

If, when you are done, you have ticked off all the available addresses,  
then there is nothing to be suspicious about. But, if any address has not  
been ticked, you are entitled to ask "why not?".

So, for each unticked address, you look up the SSP, and if you find some  
of them are 'strict' or 'all', then your suspicions are aroused. What  
happens next depends on exactly how we define 'all' and 'strict',  
including how they apply to the various headers (and it may depend also  
upon your local policies and reputations that may be to hand, but those  
considerations are beyond our scope).

As to whether we need to consider all of  
From/Sender/Resent-From/Resent-Sender, we can discuss that. But consider,  
supposing Ebay has a 'strict' SSP, how could
    Sender: somebody@ebay
legitimately come about and not get signed by Ebay?

Or, suppose someone outside sends email to [email-masked] who then  
decides to resend it to someone outside. How could that NOT get signed by  
Ebay on the way out?

> How many From email-addresses should be allowed?

As many as the verifier can be bothered to check. If he sees 1000 From  
addresses he may assume it is just a DOS attack and discard the whole  
message with no further checks.

> Would a From header referenced policy override a Sender header  

See my Ebay example above.
> header policy requirements substantially increases overhead related to  

In 99.99% of cases the sender domain will already be in one of the Froms,  
so no additional overhead.

> within the signing domain.  ...

Where do you get that? Please provide an example.

---

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

On Jan 23, 2008, at 4:51 AM, Charles Lindsey wrote:

> On Tue, 22 Jan 2008 19:43:43 -0000, Douglas Otis <dotis@mail- 
> abuse.org> wrote:
>
>>> On Tue, 22 Jan 2008 02:32:28 -0000, Douglas Otis <[email-masked] 
>>> > wrote:
>>>>

You said "an associated signature".  It was not clear whether you  
meant "associated" using the d= tag ignoring the i= tag, or using the  
i= tag (and its default)?

> A signature identifies a domain. By implication, it identifies any- 
> local-part@that-domain.

A signature is allowed to not include the local-part, or might include  
the local-part of an email-address within the Sender header that is  
within the same domain as that of the From email-address in question.   
When the signature fails to include the local-part, the entity  
introducing the message remains ambiguous and such signatures do not  
identify any-local-part.   However, such an ambiguous signature  
currently satisfies "strict" compliance.  Nonetheless, a signature  
associated with the Sender header identifies who introduced the  
message, but currently does not satisfy "strict" compliance.

It would seem your agree that a signature on-behalf-of the Sender  
within the same domain as the From should satisfy compliance with  
either "strict" or "all".

> You (a verifier) see a bunch of addresses in a bunch of From/Sender/ 
> Resent-From/Resent-Sender headers.
>
> You also see a bunch of valid signatures on behalf of an assortment  
> of domains.
>
> So you look through the domains that are signed for, and you tick  
> off all the addresses in all those headers that contain those  
> domains (well, maybe only for the headers explicitly covered by the  
> signature, where "From" is alwys covered, of course).

When you said "explicitly covered by the signature, you mean those  
those headers included within the signature's hash?

> If, when you are done, you have ticked off all the available  
> addresses, then there is nothing to be suspicious about. But, if any  
> address has not been ticked, you are entitled to ask "why not?".

You wish to include SSP discovery for any header, rather than just for  
those within the From header lacking a signature within a domain at or  
above the email-address domain?

> So, for each unticked address, you look up the SSP, and if you find  
> some of them are 'strict' or 'all', then your suspicions are  
> aroused. What happens next depends on exactly how we define 'all'  
> and 'strict', including how they apply to the various headers (and  
> it may depend also upon your local policies and reputations that may  
> be to hand, but those considerations are beyond our scope).

Checking SSP for all headers might cause an excessive level of SSP  
discovery.  Excessive SSP discovery increases the overhead related to  
DKIM, and increases concerns related to DDoS effects.

> As to whether we need to consider all of From/Sender/Resent-From/ 
> Resent-Sender, we can discuss that. But consider, supposing Ebay has  
> a 'strict' SSP, how could
>   Sender: somebody@ebay

This strategy could be done differently, while only focusing upon the  
 From header email-addresses.

Any valid signature with a domain at or above the email-address domain  
contained within the From header removes the need to discover SSP for  
that domain.  An exception should be made for signatures using a g=  
restricted keys.  These restricted signatures must be on-behalf-of (i=  
tag match) with that of the From header to satisfy "strict" or "all"  
compliance.  In essence, only the From header email-addresses are  
protected by SSP policy.

> decides to resend it to someone outside. How could that NOT get  
> signed by Ebay on the way out?

This strategy could introduce an inordinate level of SSP discovery.   
Conversely, the Sender [email-masked] could be signed by ebay.biz,  
but should not satisfy "all" or "strict" compliance with a From of [email-masked] 
.  However, when a signature is on-behalf-of (i= tag match) of the  
Sender of [email-masked], then an email-address of [email-masked] 
  within the From header should still satisfy "all" or "strict"  
compliance where an exception is made only for signatures using g=  
restricted keys.

> As many as the verifier can be bothered to check. If he sees 1000  
> From addresses he may assume it is just a DOS attack and discard the  
> whole message with no further checks.

When should a verifier decide to not discover SSP records?  At two,  
three, four, twenty, fifty?  When the verifier decides there are too  
many From email-addresses, the treatment given that message must be  
that of an SSP non-compliant message, or this situation becomes a  
means to bypass SSP checking.  This variable restriction becomes an  
unspoken limit that might cause messages to become rejected.

In addition, it would not be hard to place "From" within a folded  
Display Name to confuse recipients about the email-address really  
being the sixth email-address contained within the From header.

SSP MUST specify a limit or it will cause interchange problems.

> See my Ebay example above.

Due to MUA displaying the Sender header, this might seem logical.   
However, allowing a signature on-behalf-of the Sender header (within  
the same domain as that of the From email-address) to satisfy "strict"  
or "all" compliance, ebay remains protected when SSP policy is only  
checked for email-addresses within the From header.

>> Currently, a small percentage of emails are signed using DKIM.   
>> Sender header policy requirements substantially increases overhead  
>> related to SSP.
>
> In 99.99% of cases the sender domain will already be in one of the  
> Froms, so no additional overhead.

It seems there would be little benefit derived by the added overhead.   
The From email-addresses are where SSP conflicts are important, and  
where signatures are most needed.

>> Allowing compliance with headers other than From permits a holder  
>> of a g= restricted key to sign a message purporting to be "From"  
>> anyone within the signing domain.  ...
>

Example 1:

Sender: [email-masked] (i=ads-r-us, g=ads-r-us restricted key)
From: [email-masked]
Subject: Account information requested

This should not be "strict" or "all" compliant.

While [email-masked] would be a valid signature from ebay, g=  
restricting keys was an attempt to avoid local-part abuse.  When just  
the domain of signature is considered significant to handle cases like:

Example 2:

Sender: [email-masked] (i=admin, unrestricted key)
From: [email-masked]
Subject: New holiday hours

This must be "strict" or "all" compliant.  Otherwise, the signature  
would need to remain ambiguous about who introduced the message, or  
need to falsify a signature containing i=general-manager.   
Unrestricted keys MUST BE controlled by systems that assure compliance  
with the domain's signing policy.  It would be illogical and wasteful  
to require verifiers to discovery SSP for ebay.com and check whether  
Example 2 is compliant.  ebay MUST control which messages they sign  
using unrestricted keys.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 24 Jan 2008 12:36:35 -0000

> You said "an associated signature".  It was not clear whether you meant  
> "associated" using the d= tag ignoring the i= tag, or using the i= tag  
> (and its default)?

OK, an address in one of those headers matches the signature iff the  
various d=, i= and g= tags so determine according to RFC 4871, taking the  
local-part of the address into account if necessary.

> It would seem your agree that a signature on-behalf-of the Sender within  
> the same domain as the From should satisfy compliance with either  
> "strict" or "all".

Yes, unless there is a g= tag that does  not encompass both.

>> So you look through the domains that are signed for, and you tick off  
>> all the addresses in all those headers that contain those domains  
>> (well, maybe only for the headers explicitly covered by the signature,  
>> where "From" is alwys covered, of course).
>
> When you said "explicitly covered by the signature, you mean those those  
> headers included within the signature's hash?

Yes. (The preecise wording to be used in the document would need some  
care).
>> then there is nothing to be suspicious about. But, if any address has  
>> not been ticked, you are entitled to ask "why not?".
>

Yes, it should apply to any header which ought not to have escaped outside  
the signers boundary without being signed, according to his published SSP.  
Our SSP draft would specify exactly which those headers were (and maybe  
there would be more tags in the SSP records than we have proposed so far).
>> some of them are 'strict' or 'all', then your suspicions are aroused.  
>> What happens next depends on exactly how we define 'all' and 'strict',  

NO IT DOESN'T, because we all agree that these cases of multiple different  
addresses in the headers mentioned are going to be exceedingly rare. In  
99.99% of cases there will be just one From address, the Sender (if  
present) will be from the same domain, and there will be no Resent-*  
headers at all.
>> Resent-Sender, we can discuss that. But consider, supposing Ebay has a  
>> 'strict' SSP, how could
>>   Sender: somebody@ebay

You haven't answered my question. If you see a message with no mention of  
Ebay in its From, but with Sender: somebody@ebay and with no signature  
 from Ebay (who claim to sign everything leaving their boundary), then how  
can that message possibly NOT be bogus? That seems to be a sufficient  
reason for saying that 'all'/'strict' ought to include whatever is in the  
Sender.

>> decides to resend it to someone outside. How could that NOT get signed  
>> by Ebay on the way out?
>

HOW? Do you suppose that the number of outside messages Resent by Ebay  
will be more than a tiny fraction of the messages originating within Ebay  
itself?

> three, four, twenty, fifty?

When the number gets big enough that the DNS overhead REALLY really starts  
to hurt. If I had to choose one of those numbers to write into our  
document as the minimum that SSP owners could reasonably expect to be  
accepted, then I would choose "fifty", as being way beyond any normal  
usage and still not likely to enable a serious DOS attack on the DNS  
system.

> This should not be "strict" or "all" compliant.

Correct. And it would not be compliant according to the rule I have  
proposed.
> This must be "strict" or "all" compliant.

Correct. And it would be compliant according to the rule I have proposed.

---

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

On Jan 24, 2008, at 4:36 AM, Charles Lindsey wrote:

> On Wed, 23 Jan 2008 19:44:47 -0000, Douglas Otis <dotis@mail- 
> abuse.org> wrote:
>
>> meant "associated" using the d= tag ignoring the i= tag, or using  
>> the i= tag (and its default)?
>
> various d=, i= and g= tags so determine according to RFC 4871,  
> taking the local-part of the address into account if necessary.

I do not agree with a local-part exclusion.

DKIM-Signature: i=[email-masked] d=example.com ... (no g= parameter  
in key)
Sender: Tom Smith <[email-masked]>
From: Will Jones <[email-masked]>

This signature indicates the message is compliant with example.com's  
signing policy.  There should be no reason for a recipient to check  
example.com's SSP record.  If they did and it indicated an assertion  
of "all" or "strict", this message should be considered complaint.

Inspection of this signature also indicates which entity introduced  
the message.  Matching this identity with the header might lead  
recipient's to conclude Tom Smith introduced the message as a Sender  
on behalf of Will Jones <[email-masked]>, but this header  
MUST be included within the signature's hash before reaching that  
conclusion.

When highlighting whether a message is signed, and by whom, this  
highlighting should be limited to information included within the  
signature's hash.  The signature's coverage with respect to From  
header compliance should also consider the g= and t= parameter when  
signing for other identities not within the From header.

> Yes, unless there is a g= tag that does not encompass both.

Agreed.

>>> addresses, then there is nothing to be suspicious about. But, if  
>>> any address has not been ticked, you are entitled to ask "why not?".
>>
>> You wish to include SSP discovery for any header, rather than just  
>> for those within the From header lacking a signature within a  
>> domain at or above the email-address domain?
>
> Yes, it should apply to any header which ought not to have escaped  
> outside the signers boundary without being signed, according to his  
> published SSP. Our SSP draft would specify exactly which those  
> headers were (and maybe there would be more tags in the SSP records  
> than we have proposed so far).

I do not agree.  It seems reasonable to limit SSP compliance to only  
the From email-addresses.  However, unrestricted signatures for other  
headers must also be considered proof of policy compliance.  SSP  
definitions must reflect the concept that a signature _defines_ the  
signer's policy.

>>> discovery.  Excessive SSP discovery increases the overhead related  
>>> to DKIM, and increases concerns related to DDoS effects.
>
> NO IT DOESN'T, because we all agree that these cases of multiple  
> different addresses in the headers mentioned are going to be  
> exceedingly rare. In 99.99% of cases there will be just one From  
> address, the Sender (if present) will be from the same domain, and  
> there will be no Resent-* headers at all.

This might depend upon the level of email being handled.  Expecting a  
process to discover SSP records for an unlimited number of domains is  
not safe for the receiver or potential targets of the transactions.   
The resulting overhead is more than able to result in a denial of  
service.

>>> Resent-Sender, we can discuss that. But consider, supposing Ebay  
>>> has a 'strict' SSP, how could
>>>  Sender: somebody@ebay
>> This strategy could be done differently, while only focusing upon  
>> the  From header email-addresses.
>
> You haven't answered my question. If you see a message with no  
> mention of Ebay in its From, but with Sender: somebody@ebay and with  
> no signature from Ebay (who claim to sign everything leaving their  
> boundary), then how can that message possibly NOT be bogus? That  
> seems to be a sufficient reason for saying that 'all'/'strict' ought  
> to include whatever is in the Sender.

When ebay signs a message containing Sender: somebody@ebay and happens  
to contain a From also within their domain, then this message (with  
the possible exception of g= t=s key parameters) must be considered  
complaint.  The protection being sought is for the From header.  If  
you feel it is important to also protect the Sender header, that is  
your prerogative.  A view that the domain of the signature provides  
compliance works for any header.  Including the Sender header will  
significantly increase the number of SSP discoveries needed to support  
protection of From and Sender headers since most messages are not  
signed.

>>> Or, suppose someone outside sends email to [email-masked] who  
>>> then decides to resend it to someone outside. How could that NOT  
>>> get signed by Ebay on the way out?
>>
> HOW? Do you suppose that the number of outside messages Resent by  
> Ebay will be more than a tiny fraction of the messages originating  
> within Ebay itself?

The number of Sender headers found in messages has increased due to  
the use of the PRA algorithm.  There will be a large number of  
messages containing different domains in the From and the Sender  
header.  Protection of the Sender header separately from that of the  
 From requires an increase of SSP discovery.  Is that increase worth  
doing?  What abuse would it prevent?

>>> From addresses he may assume it is just a DOS attack and discard  
>>> the whole message with no further checks.
>>
> When the number gets big enough that the DNS overhead REALLY really  
> starts to hurt. If I had to choose one of those numbers to write  
> into our document as the minimum that SSP owners could reasonably  
> expect to be accepted, then I would choose "fifty", as being way  
> beyond any normal usage and still not likely to enable a serious DOS  
> attack on the DNS system.

This view can result in a significant amount of targeted traffic.  10  
would represent a network amplification that might be seen with many  
other types of attack.

-Doug

---

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

>> various d=, i= and g= tags so determine according to RFC 4871, taking  
>> the local-part of the address into account if necessary.
>

I never proposed a local-part exclusion.
> example.com's SSP record.  If they did and it indicated an assertion of  
> "all" or "strict", this message should be considered complaint.
>
> Inspection of this signature also indicates which entity introduced the  
> message.  Matching this identity with the header might lead recipient's  
> to conclude Tom Smith introduced the message as a Sender on behalf of  
> Will Jones <[email-masked]>, but this header MUST be included  
> within the signature's hash before reaching that conclusion.
>
> signature's hash.  The signature's coverage with respect to From header  
> compliance should also consider the g= and t= parameter when signing for  
> other identities not within the From header.

All that is perfectly correct. I never said or proposed otherwise.

>> published SSP. Our SSP draft would specify exactly which those headers  
>> were (and maybe there would be more tags in the SSP records than we  
>> have proposed so far).
>
> I do not agree.  It seems reasonable to limit SSP compliance to only the  
> From email-addresses.  However, unrestricted signatures for other  

If the sender wishes to specify in his SSP that he signs Sender, Resent-*,  
etc headers if they purport to include his domain, then he should be able  
to do so.

Whether that is implied automatically by 'strict', or by some  
yet-to-be-invented other tag is just a small technical detail to be  
decided.

> not safe for the receiver or potential targets of the transactions.  The  
> resulting overhead is more than able to result in a denial of service.

Nobody is suggesting an "unlimited number of domains". But it needs to be  
large enough for normal expected usage. I have suggested 50. You have  
mentioned 10, which is a bot low for my taste.