Earl Hood wrote:
On August 25, 2005 at 09:22, Jim Fenton wrote:
The intent of
restricting third-party signatures is to prevent messages signed by
mailing lists and the like (and particularly by attackers posing as
such) from being considered verified if there isn't also a valid
On August 25, 2005 at 09:22, Jim Fenton wrote:
> I'm confused about this paragraph: "enabling TP signing is bad policy"
> but "OA will not care if other entities sign...not claiming a 1st-party
> association". A third-party signature doesn't claim a first-party
> association, or at least that'
Earl Hood wrote:
On August 18, 2005 at 09:57, Douglas Otis wrote:
1- Employs DKIM
2- Employs DKIM universally
3- Allows TP signing
4- Allows sub-domain TP signing
5- Disallows all TP signing
6- Never sends email
It would seem counter productive to for assertion 5 to be the default
taken
Douglas Otis wrote:
On Aug 24, 2005, at 6:05 PM, Dave Crocker wrote:
On Wed, 24 Aug 2005 17:56:55 -0700, Douglas Otis wrote:
It is not the SSP statement that is the problem, but confusion about
forgery protections.
The concern I was responding to was quite clearly stated and specific
On Aug 24, 2005, at 6:05 PM, Dave Crocker wrote:
On Wed, 24 Aug 2005 17:56:55 -0700, Douglas Otis wrote:
It is not the SSP statement that is the problem, but confusion about
forgery protections.
The concern I was responding to was quite clearly stated and
specific in its
focus.
It ha
On Wed, 24 Aug 2005 17:56:55 -0700, Douglas Otis wrote:
> It is not the SSP statement that is the problem, but confusion about
> forgery protections.
The concern I was responding to was quite clearly stated and specific in its
focus.
It had nothing to do with forgery protection, but rather t
On Aug 24, 2005, at 3:43 PM, Dave Crocker wrote:
It is not the SSP statement that is the problem, but confusion about
forgery protections. The MTA does not need to attempt to provide the
complete solution, but rather provide a solid foundation.
I have not noticed anyone suggesting that
On Wed, 24 Aug 2005 16:55:14 -0400, Scott Kitterman wrote:
> Question for you: Is it your view that DKIM-SSP ought to be in scope or
> out of scope for the initial work of the working group?
SSP is in the draft charter.
I have not noticed anyone suggesting that the charter be changed.
d
I'll take that as a no.
For whatever reason you come at the problem from the direction you do, I
think your approach would sharply limit the value of DKIM to individual
domain owners and maximize its value to anti-spam tool vendors.
I do hope this isn't the direction that the working group take
On Aug 24, 2005, at 1:55 PM, Scott Kitterman wrote:
Is it your view that DKIM-SSP ought to be in scope or out of scope
for the initial work of the working group?
DKIM should focus upon verifying the sending domain, and imparting
controls permitting accountability for subsequent abuses si
Douglas Otis wrote:
On Aug 24, 2005, at 12:10 PM, Scott Kitterman wrote:
As I said before, let's just agree that there is work yet to be done
on SSP and quite arguing about if it should be done.
We are back to using the term 'it' again as if 'it' has special
meaning. You have made wil
On Aug 24, 2005, at 12:10 PM, Scott Kitterman wrote:
To give an example, if I receive an e-mail from a domain such as e-
bay (i.e. 2822-From: [EMAIL PROTECTED]), Ebay has published a
restrictive SSP that says messages are all signed, but please don't
accept 3rd party signing, I want to be a
Douglas Otis wrote:
On Aug 24, 2005, at 11:14 AM, Scott Kitterman wrote:
What you are asking is what won't SSP accomplish. It's difficult to
answer those questions before the design work is done. So lets quick
arguing about if it should be done. Get it done and see what it buys
us.
On Aug 24, 2005, at 11:14 AM, Scott Kitterman wrote:
What you are asking is what won't SSP accomplish. It's difficult
to answer those questions before the design work is done. So lets
quick arguing about if it should be done. Get it done and see what
it buys us.
Before setting out on
Douglas Otis wrote:
On Aug 24, 2005, at 7:00 AM, Scott Kitterman wrote:
It seems to me that your proposed approach is anything but simple. It
would appear to me that you want to trade the direct, obvious, near- term
benifits of a defined deterministic Sender Signing Policy (I'm not
saying
On Aug 24, 2005, at 7:00 AM, Scott Kitterman wrote:
It seems to me that your proposed approach is anything but simple. It
would appear to me that you want to trade the direct, obvious, near-
term
benifits of a defined deterministic Sender Signing Policy (I'm not
saying
the current draft is
.. Original Message ...
On Tue, 23 Aug 2005 22:23:15 -0700 Douglas Otis <[EMAIL PROTECTED]>
wrote:
...
It seems to me that your proposed approach is anything but simple. It
would appear to me that you want to trade the direct, obvious, near-term
benifits of a defined deterministic Send
On Aug 23, 2005, at 8:09 PM, Earl Hood wrote:
On August 23, 2005 at 16:13, Douglas Otis wrote:
Let's take a real-world example. CPAN provides a permanent email
address for all CPAN account holders. CPAN account holders specify
where to forward all messages address to their CPAN addresses.
Th
On August 23, 2005 at 16:13, Douglas Otis wrote:
> > DKIM should provide the mechanism to facilitate accountability in
> > an acceptably reliable fashion.
> >
> > Therefore, you are implying that domains may practice policies that
> > selectively sign messages based on what they want to account fo
On Aug 23, 2005, at 12:49 PM, Earl Hood wrote:
On August 20, 2005 at 18:21, Douglas Otis wrote:
DKIM should provide the mechanism to facilitate accountability in
an acceptably reliable fashion.
Therefore, you are implying that domains may practice policies that
selectively sign messages based
On August 20, 2005 at 18:21, Douglas Otis wrote:
> > It appears your discussion of accountability is really something that
> > sits on top of DKIM, since trying to standardize "accountability"
> > seems impractical.
>
> I do not understand what you mean by standardized accountability.
> Either th
On August 20, 2005 at 17:14, Douglas Otis wrote:
> > You can't stop forgery without stopping forgery. Some things that are
> > perhaps technically forgery are considered desireable. Other things
> > that aren't forgery might be affected by forgery prevention protocols.
>
> Stopping forgery re
Douglas Otis wrote:
On Mon, 2005-08-22 at 21:32 -0400, Scott Kitterman wrote:
Once it gets to the MUA, it's too late. I want to reject the message
during SMTP (after DATA, but before OK).
Your notion seems to consider mailbox address authorization will be the
principle mechanism used to re
On Mon, 2005-08-22 at 21:32 -0400, Scott Kitterman wrote:
> Douglas Otis wrote:
>
> > You wish to include an anti-forgery mechanism directly within DKIM. I
> > fear serious issues will likely derail DKIM deployment when "anti-
> > forgery" mechanisms interfere with normal email, while at the sa
Douglas Otis wrote:
On Aug 22, 2005, at 3:23 PM, Scott Kitterman wrote:
Douglas Otis wrote:
Binding a mailbox-address or mailbox-domain to a domain signature is
not a goal, it is a mechanism. What is the intended goal? What is
the selection process? What level of administrative effor
On Aug 22, 2005, at 3:23 PM, Scott Kitterman wrote:
Douglas Otis wrote:
Binding a mailbox-address or mailbox-domain to a domain signature
is not a goal, it is a mechanism. What is the intended goal?
What is the selection process? What level of administrative
effort will this entail?
Douglas Otis wrote:
On Aug 22, 2005, at 11:02 AM, Scott Kitterman wrote:
So to narrow my previous attempt at a summary, you think that
domain-wide assertions cannot be accurately made for mail addresses,
but that it can for HELO/EHLO?
Accuracy is not the issue. While a domain-wide asse
On Aug 22, 2005, at 11:02 AM, Scott Kitterman wrote:
So to narrow my previous attempt at a summary, you think that
domain-wide assertions cannot be accurately made for mail
addresses, but that it can for HELO/EHLO?
Accuracy is not the issue. While a domain-wide assertion may
accurately
Douglas Otis wrote:
On Aug 22, 2005, at 8:35 AM, Scott Kitterman wrote:
To summarize, you think that SSP is dangerous, won't do what it's
proponents claim, and can't be fixed. Thus SSP and it's ilk
shouldn't be dealt with by the working group. You believe that there
are other, better wa
On Aug 22, 2005, at 8:35 AM, Scott Kitterman wrote:
To summarize, you think that SSP is dangerous, won't do what it's
proponents claim, and can't be fixed. Thus SSP and it's ilk
shouldn't be dealt with by the working group. You believe that
there are other, better ways to solve whateve
I really don't have an opinion on your revocation identifier idea. I
thought we were discussing scope of the WG effort rather than the design
of the product.
I also think that we are pretty much going in circles at this point.
To summarize, you think that SSP is dangerous, won't do what it's
On Sun, 2005-08-21 at 23:38 -0400, Scott Kitterman wrote:
> Douglas Otis wrote:
> As I've said before, we are wanting to solve two different problems.
> You want another input to improve spam filtering and reporting in order
> to get from IP based solutions to name based solutions. Fine. I do
Douglas Otis wrote:
On Sun, 2005-08-21 at 13:35 -0400, Scott Kitterman wrote:
Douglas Otis wrote:
This also, I think, brings to light an important reason for the
divergence in our perspectives. I believe that you are saying that you
think DKIM's usefulness is primarily in supporting reliabl
On Sun, 2005-08-21 at 13:35 -0400, Scott Kitterman wrote:
> Douglas Otis wrote:
>
> This also, I think, brings to light an important reason for the
> divergence in our perspectives. I believe that you are saying that you
> think DKIM's usefulness is primarily in supporting reliable name based
Douglas Otis wrote:
By industry, I am referring to institutions and companies who depend
upon email to conduct business. Email is suffering with protocols that
currently do not offer effective means for locating and preventing the
repetitions of abusive behavior.
Thanks for clearing that up
On Sat, 2005-08-20 at 22:17 -0400, Scott Kitterman wrote:
> Douglas Otis wrote:
> > With DKIM, a small list of trusted signing domains will exclude most
> > emails which need greater examination. The level of support to maintain
> > this type of trusted list would be less than the traditional IP
Douglas Otis wrote:
On Sat, 2005-08-20 at 20:29 -0400, Scott Kitterman wrote:
So, given that view, as a sender, what's in it for me?
Sounds like all I get is more spam reports and maybe on a domain based
blacklist if someone doesn't like my mail? What benifit is being
offered that I should
On Sat, 2005-08-20 at 20:29 -0400, Scott Kitterman wrote:
> Douglas Otis wrote:
>
> > DKIM should verify a domain that can be held accountable for stopping
> > abusive messages. (It would be nice for the recipient to see who is
> > accountable.) However, displaying the accountable domain is not
On Sat, 2005-08-20 at 18:58 -0500, Earl Hood wrote:
> On August 19, 2005 at 17:23, Douglas Otis wrote:
>
> In your view, if all the domains do DKIM signing, are all the
> domains equally accountable (or claiming equal accountability),
> regardless the role they play?
In my view, if there is alre
Douglas Otis wrote:
DKIM should verify a domain that can be held accountable for stopping
abusive messages. (It would be nice for the recipient to see who is
accountable.) However, displaying the accountable domain is not needed
and should not be attempted with feeble header bindings. With DK
On Sat, 2005-08-20 at 13:08 -0400, Scott Kitterman wrote:
> Douglas Otis wrote:
>
> > Defensive strategies must find a different identifier assured by the
> > domain as a unique basis for locating trouble. This is simply being
> > pragmatic, but this new identifier will not impact the way ema
On August 19, 2005 at 17:23, Douglas Otis wrote:
> Different levels seem to suggest shifting accountability to
> coincident mailbox-domains, or even listed mailbox-domains, when
> accountability is not fully attributed to the signing domain.
> Mailbox-domain selection and related permission
Douglas Otis wrote:
Defensive strategies must find a different identifier assured by the
domain as a unique basis for locating trouble. This is simply being
pragmatic, but this new identifier will not impact the way email
operates, as would adding constraints on the mailbox-domains. MASS
Dave Crocker wrote:
On 19 Aug 2005 16:14:06 -, John Levine wrote:
A third-party signature is a lot weaker assertion than an OA signature,
unless you know something about the third party.
Seems to me that no signature is useful unless you know something about the
signing party.
That nic
On Aug 19, 2005, at 12:42 PM, Earl Hood wrote:
On August 19, 2005 at 01:03, Douglas Otis wrote:
Is your view in a nutshell (of what DKIM should be): When a domain
signs a message, it is saying, "Here is what I got and transmitted."
DKIM only provides a verifiable trace of a message.
The
At 12:19 18-08-2005, Earl Hood wrote:
As for the receiver making the final decision, all receiver
implementation should generate the same result on the same message
(at the DKIM level). There should not be room for ambiguity and
variability, this can lead to exploitation.
That is where impleme
On August 19, 2005 at 01:03, Douglas Otis wrote:
> > Is your view in a nutshell (of what DKIM should be): When a domain
> > signs a message, it is saying, "Here is what I got and transmitted."
> > DKIM only provides a verifiable trace of a message.
>
> The signature indicates a specific message
>A third-party signature is a lot weaker assertion than an OA signature,
>unless you know something about the third party.
Seems to me that no signature is useful unless you know something about
the signing party.
Let's say you get a message from [EMAIL PROTECTED], with valid signatures
from sli
On 19 Aug 2005 16:14:06 -, John Levine wrote:
> > A third-party signature is a lot weaker assertion than an OA signature,
> > unless you know something about the third party.
>
> Seems to me that no signature is useful unless you know something about the
> signing party.
That nicely summar
On Thu, 2005-08-18 at 22:41 -0500, Earl Hood wrote:
> On August 18, 2005 at 17:01, Douglas Otis wrote:
>
> Is your view in a nutshell (of what DKIM should be): When a domain
> signs a message, it is saying, "Here is what I got and transmitted."
> DKIM only provides a verifiable trace of a message
On August 18, 2005 at 17:01, Douglas Otis wrote:
> DKIM provides significant value beyond implementing a weak and
> uncertain anti-spoofing mechanism. MUAs are not designed to ensure
> the identity of the author or sender. As a result, MUAs often fail
> to show headers intended to indicate
On Aug 18, 2005, at 1:02 PM, Earl Hood wrote:
On August 18, 2005 at 09:57, Douglas Otis wrote:
1- Employs DKIM
2- Employs DKIM universally
3- Allows TP signing
4- Allows sub-domain TP signing
5- Disallows all TP signing
6- Never sends email
It would seem counter productive to for assertion 5
On August 18, 2005 at 14:19, Earl Hood wrote:
> Also, if the sender/signer can reliably perdict what a verifier will do
-^^^
cannot
> (at the DKIM level), there is little use in signing messages.
--ewh
__
On August 18, 2005 at 09:57, Douglas Otis wrote:
> 1- Employs DKIM
> 2- Employs DKIM universally
> 3- Allows TP signing
> 4- Allows sub-domain TP signing
> 5- Disallows all TP signing
> 6- Never sends email
>
> It would seem counter productive to for assertion 5 to be the default
> taken as thi
On August 18, 2005 at 09:33, SM wrote:
> >because it makes things simpler for mailing lists (why check SSP at
> >every step?) and because it puts the decision in the hands of the
> >recipient's verifier because it's really the recipient we're serving.
>
> Whatever we put in the SSP, it comes do
On August 18, 2005 at 08:59, Jim Fenton wrote:
> >If no SSP record is defined, "never signs" should be assumed (note
> >the current SSP draft does support a "never signs" policy). This will
> >prevent malicious domains from exploiting any "trust" DKIM generates
> >in order to spoof identities.
>
On Aug 18, 2005, at 8:59 AM, Jim Fenton wrote:
Earl Hood wrote:
On August 17, 2005 at 22:07, Jim Fenton wrote:
When a DKIM verifier, "V", receives the message, the signature
validates cryptographically (remember, the signer public key is
retrieved from EXAMPLE.com). The verifier now check
At 08:59 18-08-2005, Jim Fenton wrote:
because it makes things simpler for mailing lists (why check SSP at
every step?) and because it puts the decision in the hands of the
recipient's verifier because it's really the recipient we're serving.
Whatever we put in the SSP, it comes down to the re
Earl Hood wrote:
On August 17, 2005 at 22:07, Jim Fenton wrote:
Let's say example.org knows nothing about DKIM or has not adopted
it yet. EXAMPLE.com is operated by questionable folks, and they
know example.org does not have any SSP records defined. EXAMPLE.com
defines _domainkey.EXAMPLE.
On August 17, 2005 at 22:07, Jim Fenton wrote:
>> Let's say example.org knows nothing about DKIM or has not adopted
>> it yet. EXAMPLE.com is operated by questionable folks, and they
>> know example.org does not have any SSP records defined. EXAMPLE.com
>> defines _domainkey.EXAMPLE.com records
Earl Hood wrote:
On August 17, 2005 at 16:55, Jim Fenton wrote:
If the Sender Signing Policy record does not exist, verifier systems
MUST assume that some messages from this entity are not signed and
the message SHOULD NOT be considered to be Suspicious.
Now, in this ca
On August 17, 2005 at 16:55, Jim Fenton wrote:
> > If the Sender Signing Policy record does not exist, verifier systems
> > MUST assume that some messages from this entity are not signed and
> > the message SHOULD NOT be considered to be Suspicious.
> >
> >Now, in this case, we have a signed me
Earl Hood wrote:
On August 11, 2005 at 13:27, Jim Fenton wrote:
But how would they get a valid signature on behalf of the OA? Or are
you saying that one should treat the message differently from an
unsigned message because there is an invalid OA signature present?
There isn't
On August 11, 2005 at 13:27, Jim Fenton wrote:
> >Why is it not safe? Because a malicious domain can send out messages
> >with forged rfc2822.From addresses where the domain portion does not
> >have any SSP defined. Therefore, when a DKIM verifier checks the
> >SSP for rfc2822.From, the message
Earl Hood wrote:
In the DKIM SSP draft, the following is stated:
If the Sender Signing Policy record does not exist, verifier systems
MUST assume that some messages from this entity are not signed and
the message SHOULD NOT be considered to be Suspicious.
I'm wondering if this a safe policy
>IMHO, if no SSP records is defined for the OA, then messages from
>the OA must be considered to never be signed, and any signed message
>should be considered suspicious.
I see why you might want to mandate that any domain that publishes
dkim keys also must publish SSP records, but it doesn't feel
In the DKIM SSP draft, the following is stated:
If the Sender Signing Policy record does not exist, verifier systems
MUST assume that some messages from this entity are not signed and
the message SHOULD NOT be considered to be Suspicious.
I'm wondering if this a safe policy to assert, espec
67 matches
Mail list logo
