ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] "I sign everything" is not a useful policy

2006-08-08 13:14:49
>> Since someone who doesn't sign anything wouldn't publish any keys, how
>> could this possibly be useful?  Where would these rogue signatures
>> come from, and how is a recipient going to verify a signature that has
>> no key record?
>
> This was put in because I was reading threads where they wanted to be
> able to say "I sign no mail". From what I read, this was for domains
> that expliciately do not send _any_ mail what-so-ever.

"I sign no mail" is quite different from "I send no mail."  The latter
says to throw away unsigned mail.

>> >"I sign all" only from this domain(s) or _FDQN(s)_. Messages from this
>> >domain(s) or FDQN(s) that are not signed are expected by me not to
>> >reach their destination. However, messages coming from everywhere else
>> >may or may not be signed. I expect that these messages will not be
>> >effected under this policy.
>>
>> It should be obvious that "domain" and "FQDN" are exact synoyms in
>> this discussion.  With that in mind, how does this differ from the
>> first "I sign all"?  Nobody's going to be looking at your SSP for
>> any domains other than yours.
>
> I do not see them as being exact but fdqn being a subset.

In the DNS, a domain is a domain.  Subdomains are useful when you think
about organizing your network, but when we're talking protocols, a query
for dsl-467.podunk.someisp.com is no different from one for someisp.com.


It is if there is a policy record at dsl-467.podunk.someisp.com
I have some real life examples if you would like to see them.



> For instance, all the messages I send come from the mta:
> mail1.bigbank.com which are not signed and have a mail from: of
> <employee>/at/bigbank.com except for my transactional messages. These
> come from the mta: reciepts.bigbank.com which has a mail from:
> customer_service/at/bigbank.com for which I want to apply the policy
> of "I sign all" with the expected result of do not deliver anything
> that is not signed.

Please send that scenario in to the list so someone other than me can tell
you that path authentication is completely off the table.

If you want your transactional mail treated differently from your employee
mail, put them in different domains, e.g.
customer_service(_at_)svc(_dot_)bigbank(_dot_)com(_dot_)



This is *exactly* my problem with SSP. Without being able to state the
above, it makes it unwieldly. My example shows just one domain but
what if I have 132 peppered within these, 1 to 10 mta's some I would
want to sign for, some I would not. So now I would have to have all
email sent to postmaster/at/svc.bigbank.com forwarded to
postmaster/at/bigbank.com, plus every address that may be signing
mail.
As an administrator, I would like the policy that says any time I
send to XYZ.com from bigbank.com due to a content policy or because
the email was sent between 3:15 and 3:17pm, whatever... I want to be
able to point that email at my "signing mta" and not break my
return-paths or add extra work for myself.

Why is it completely off the table?
I will let you send to the list if you'd like so that it is not
assumed that I am blindsiding you. :)
..on second thought... I will go ahead and post it. Since I feel this
_may_ be a new way of looking at the problem, I believe that it
follows Stephan's rules.

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