On Fri, 2006-08-18 at 06:27 -0400, Hector Santos wrote:
> From: "Douglas Otis" <[EMAIL PROTECTED]>
> 
> >>  Is this a threat to company.com? Yes.
> >
> > No. Either this is prevented or a different signing domain is
> > used. When there is no designated domain, there is no
> > expectation the 2822.From is valid.
> >
> > It would seem Hector would advocate a separate flag indicating
> > whether the 2822.From is valid as a separate assertion from by
> > whom it should be signed.  My view differs in this case.  Either
> > the 2822.From is valid or don't list a designated (authoritative)
> > domain in the policy.  A flag that signals a required signature
> > without an assertion the 2822.From is valid offers little
> > protective value.
> 
> I'm not sure what this means, but we still have the DKIM-BASE hashing
> of 2822.From.  Thats a great assertion for validity.

You appear less concerned about whether the signature implies the
2822.From is valid from the perspective of being used by the correct
entity.  Without a 2822.From policy, there is little real reason to
assume the correct entity is using the 2822.From address.  It has been
suggested in the base draft, correct use is implied only when the i=
parameter contains the full email-address.  When a designated domain has
signed on behalf of the 2822.From address, this syntax is not possible
where it should be assumed that this designation only occurs when the
2822.From address is _absolutely_ restricted to being used by the
correct user.    

> I argue only that it is unsafe for company.com to be using his domain
> promisculously after it has arranged for his mail to be signed by
> anyone or himself.  If he wants to do that, fine.  But he should at
> least declare such a relaxed policy.

I assume you mean that by "relaxed" the 2822.From is not valid but here
are the domains who should be signing for this 2822.From domain.  Here
is where a flag might be needed to indicate this state.  This would
create the need for:

 - "All" All initially signed.

 - "Only" Only these signing domains used.

 - "Invalid" 2822.From is not assured to be valid.  

> He doesn't know what will happen at mailinglist.com.  Maybe tomorrow
> mailinglist.com will find a different ISP.  Who knows?

In my view, a domain that permits a mailing list unrestricted use of the
2822.From addresses should never be a designated domain, and should not
be certified as being suitable for this purpose.  You, on the other
hand, wish to limit the set of valid signers for the 2822.From address
even when anyone is still able to spoof this address who also has access
to this domain.  This removes the protection expected of a 2822.From
policy.  As long as there is a flag that indicates the 2822.From address
should not be considered valid, then damage is mitigated to some extent.
This message might not be filtered, but then it should not be annotated
as having an assured address in any manner.


> But if domain wants to allow that, I don't see it as any different
> than other relaxed domain policy.
> 
> > The goal that Hector is seeking represents a desire to list
> > who should sign without making any assertion regarding the
> > validity of the 2822.From.  While not agreeing with that use,
> > a policy could be structured to accommodate that use as well.
> 
> Lets not forget there is still DKIM-BASE.  The tie in would be the
> hashing of the 2822.From: header.  The signature still needs to
> verify.

Signed by a domain that does not restrict the use of the 2822.From will
not protect the use of the 2822.From, whether or not the signature
verifies.  You should admit that this mode of operation offers little
value to the 2822.From address holder and to the recipient.


> So the delegation is a middle ground for those people who don't want
> to be 100% strict with OA only signatures and yet do not just want
> anyone signing.

Here we do not agree.  A designated or delegated domain should only
occur when the 2822.From address is expected to be protected.  For large
ISPs, some organization like DAC could certify which DKIM domains offer
this form of protection.  Without that assurance, either through a
contract or third-party indication of compliance, designation or
delegation should not occur.  Not having a designated domain for the
2822.From address should indicate this address domain should never be
trusted as being used by a specific entity.  Acceptance, if there is
any, would be based solely upon the signing domain and the IP address of
the sender.

-Doug




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

Reply via email to