On Fri, 28 Oct 2005, Jim Fenton wrote:
Stephen Farrell wrote:
In an offlist exchange with Doug I asked him whether he thinks
the following scenario is an example of his perceived problem
with ssp. He said it is an example, so I wanted to check with
the list about this.
1. Alice works for Alice-Corp who publish a policy to the effect
that they and only they sign all their outbound mail.
2. Alice posts a message to Foo-list which signs the message
itself and drops Alice's signature.
You didn't say whether foo-list did something that broke the original
signature. I'm not sure whether that is completely relevant here, but IMO
the removal of Alice's signature is reasonable if it was broken anyway.
Did you mean to say if it would be broken after consideration of mail list
processing?
[Personally I think signatures should stay even if it were broken - I'm
against removal of any trace data even if it is possibly forged]
Otherwise, I think it should have stayed.
3. Bob receives the message from the Foo-list, signed by the list.
4. Bob looks up Alice-Corp's ssp assertion and considers the
message as having a bad signature.
[#define domain "border MTA at recipient-side (Bob) ISP"]
It's probably a better example if Bob's domain did this, and made the
decision. Bob potentially knows he's subscribed to foo-list and can
whitelist it. Domains are less likely to be able to do this.
[#undef domain]
5. In order to allieviate this problem Alice-Corp are forced
to weaken their policy to allow 3rd party signatures to be
accepted by Bob.
I expect that domains that wish to send through munging/re-signing mailing
lists will either need to do this, or move their users who want to enable
re-signing to a different domain or to a subdomain that allows third party
signatures.
Another option is working on such signature design/format that it will
allow signature to survive mail list processing and give option for
recipient user/system to either trust 3rd party signature added by mail
list or to drop the data added by mail list and trust assertion made by
original sender.
So, is there an error in the above? (E.g. does the problem go
away if both signatures are maintained with the message, or
does it just get more messy, but remain a problem.)
If the above is possible, how should/can it be avoided?
We are trying to not force changes in mail addressing, but segregating users
with different signing policies may be an exception to that. My expectation
was that only relatively number of high-value domains (banks, etc.) would
use the Exclusive (no third-party) signing policy anyway.
In other words only those domains who do not have users that send email
to mail lists.
Nobody has yet mentioned the user-level granularity option in SSP. The SSP
draft specifies a way to set signing policy at the user level, but I'm not
sure whether it's practical or not, due to DNS load.
DNS load is not an issue. A problem is greatly increased amount of data
(or rather number of records) that ISP dns servers would have to cache.
This all gets back to the issue of over-reliance on dns for authorization
in DKIM design which makes some potential use of signature impractical.
It probably does lack
one thing: a way of defining default policy for addresses that don't have a
user-level record.
DNS takes care of that with use of wilcards, i.e. you make a pointer to
<username>._user._policy.example.com
and enter
*._user._policy.example.com IN TXT "default policy record"
bob._user._policy.example.con IN TXT "Bob's policy record"
BTW - You might want to include example of this use in the draft.
This would make it possible for there to be a policy
allowing third-party signatures, except for some specific addresses. The
price for this is an additional DNS check and (mostly) negative caching of
the result.
Caching is the biggest issue really especially for domains with large
number of users.
Note: even if this is a valid problematic scenario, I don't
believe we need to fix it right now, but we should recognise
it as a problem that needs solving.
As Mike Thomas pointed out, another thing that may be lacking in SSP is a
preference from the subject domain of how harshly to interpret failures.
Options might include increased scrutiny and outright deletion of the
message.
See SPF with its ?, ~ and -
Of course it's the verifier that ultimately decides what to do
with the message, and may or may not follow that preference.
Yes. For example earthlink decided to drop SPF record even though all
they had at the end was just "?all" - but apparently they found that
some are going to interpret this as something other then neutral The
problem is really that what is making a decision is not yes/no trigger
[let it through or not], but mostly anti-spam filters which assign
certain score for every value and for every spf result value.
I consider the Exclusive policy to be an improvement available to some
domains that send mail in particular ways, relative to signing policies
that have been discussed in the past. In other words, let's not throw
out Exclusive just because it doesn't work for some domains that would
like to use it.
-Jim
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
_______________________________________________
ietf-dkim mailing list
http://dkim.org