ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] over-the-wire (in)compatibility between pre-IETF DKIMand (eventual) IETF DKIM

2005-10-19 07:26:38
Douglas Otis wrote:
When the From/Sender headers do not represent the actual sender, such messages may be forfeit had the domain contained within the From/Sender published close-ended authorizations. SSP policies reduce delivery integrity for other senders! : (

I don't agree.  I believe the combination of the ability to specify
which header you're attesting to, combined with the ability to specify
in the SSP whether you sign and whether you authorize third parties
to sign (though I'm not happy with the confusion that the term "third
party" has generated, I don't have a better term in mind), gives the
flexibility we need to solve the problem we're trying to solve --
which, keep in mind, is a limited one.

protection and makes the domain highly restricted to two-party use, but still suitable for sensitive transactions.

  - All originating headers match the signing-domain!

I argue that "sensitive transactions" are not what DKIM is about.  If
one wants to protect sensitive transactions, one should use S/MIME or
OpenPGP.

That said, I wouldn't object to an additional, strict signing policy
that lists headers and asserts that they must match.  I think it'd be
rather nice to say, "Only consider a message validly signed by us if
the signature verifies AND ALL of the following SMTP and header fields
represent our domain: HELO, MAIL-FROM, From, Sender, Reply-To [...]."

What do others think of this?

Barry

--
Barry Leiba, Pervasive Computing Technology  
(leiba(_at_)watson(_dot_)ibm(_dot_)com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
ietf-dkim mailing list
http://dkim.org

<Prev in Thread] Current Thread [Next in Thread>