Re: ***SPAM-3*** Re: [ietf-dkim] What is your view on these three SSP topics?
2008-01-23 05:59:34
On Tue, 22 Jan 2008 19:43:43 -0000, Douglas Otis <dotis(_at_)mail-abuse(_dot_)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(_dot_)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(_dot_)
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(_dot_)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(_dot_)man(_dot_)ac(_dot_)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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
|
|