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