***SPAM-3*** Re: [ietf-dkim] What is your view on these three SSP topics?

[Charles Lindsey]

On Tue, 22 Jan 2008 19:43:43 -0000, Douglas Otis <dotis at mail-abuse.org>  
wrote:

> On Jan 22, 2008, at 3:12 AM, Charles Lindsey wrote:
>
>> On Tue, 22 Jan 2008 02:32:28 -0000, Douglas Otis <dotis at mail-abuse.org>  
>> wrote:
>>>
>>> 1) To be SSP "strict" or "all" compliant, the identity associated with  
>>> a signature:

>> 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).

>
> 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 at 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 at ebay
legitimately come about and not get signed by Ebay?

Or, suppose someone outside sends email to someone at ebay.com who then  
decides to resend it to someone outside. How could that NOT get signed by  
Ebay on the way out?



>>> 2) SSP references should be done for:
>>>
>>> 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
>
> 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.

> What benefit is derived imposing policy for Sender headers?
>
> Would a From header referenced policy override a Sender header  
> referenced policy?

See my Ebay example above.
>
> 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.


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

>> Add:
>> a) SSP "all" or "strict" compliant only when on-behalf-of a From,  
>> Sender,
>> 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.  ...

Where do you get that? Please provide an example.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: chl at clerew.man.ac.uk      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