On Thursday 06 December 2007 07:12, Charles Lindsey wrote:
> On Wed, 05 Dec 2007 14:18:09 -, Scott Kitterman
>
> <[EMAIL PROTECTED]> wrote:
> > On Wednesday 05 December 2007 08:53, John Levine wrote:
> >> >How would doing this work change what verifiers do after the RFC is
> >> > deployed?
> >>
On Wed, 05 Dec 2007 14:18:09 -, Scott Kitterman
<[EMAIL PROTECTED]> wrote:
On Wednesday 05 December 2007 08:53, John Levine wrote:
>How would doing this work change what verifiers do after the RFC is
> deployed?
Probably not much, but it will help rein in unwarranted expectations
by send
Folk on this list are confusing what the protocol states MUST be done in
order to be implemented with what the protocol's algorithm states MUST
be done to a message. Any protocol has to have language with respect to
the former. This protocol has NO language with respect to the latter.
Sorry,
Somehow, we need to tell verifiers what they need to do in order to
implement this specification. Nobody is saying that verifiers MUST
implement SSP at all, but rather that if they want to implement SSP,
this is how they MUST do it. Of course, verifiers are free to implement
some other SSP-like
On Wednesday 05 December 2007 08:53, John Levine wrote:
> >How would doing this work change what verifiers do after the RFC is
> > deployed?
>
> Probably not much, but it will help rein in unwarranted expectations
> by senders that publishing SSP will affect what happens to their mail.
>
It sounds
>How would doing this work change what verifiers do after the RFC is deployed?
Probably not much, but it will help rein in unwarranted expectations
by senders that publishing SSP will affect what happens to their mail.
R's,
John
___
NOTE WELL: This list
On Wednesday 05 December 2007 08:07, Charles Lindsey wrote:
> On Tue, 04 Dec 2007 18:10:37 -, Jim Fenton <[EMAIL PROTECTED]> wrote:
> > Charles Lindsey wrote:
> >> But it has no business whatsoever making normative statements about
> >> what verifiers are to do, so wording of the form "Verifier
On Tue, 04 Dec 2007 18:10:37 -, Jim Fenton <[EMAIL PROTECTED]> wrote:
Charles Lindsey wrote:
But it has no business whatsoever making normative statements about
what verifiers are to do, so wording of the form "Verifiers MUST" is
quite out pf place - that is BCP material.
Somehow, we need
On Tue, 04 Dec 2007 16:22:16 -, J D Falk <[EMAIL PROTECTED]> wrote:
Charles Lindsey suggested:
And I am still happy to see BCP material which then, essentially,
describes ways in which verifiers are "expected"
to apply the "advice".
A fine idea -- except, how do we list Best Current Pra
Eric Allman responding to Dave's Review:
* Several places you compare this version (unfavorably) to "the original
SSP specification". Which one would that be? There was _policy in DK,
and some stuff in draft-allman-dkim-base that got pulled out, but I
don't recall anything that got further t
I'm going to reply to this message twice. This is a short note, but
given the size of your critique and the fact that we got less than 24
hours to look at it before the meeting, I'm planning on doing a more
detailed reply later.
Briefly, please consider Patrick Peterson's response dated 12/4
hsbc.co.uk != hsbc.com. That they have layer 8+ ties to one another
is not a problem SSP is trying to solve.
Right. So forget that digression.
I said, I get a bunch of messages purporting to be from a bank I've never
seen before. This isn't lookalike, this uses the actual domain (in this
John L wrote:
This assumes that SSP tries to solve the lookalike domain problem.
Can we review the last couple of messages, please?
You said that a way to avoid making useless SSP lookups was only look up
a domain if you've previously seen a signed message from it.
I said, I get a bunch of
This assumes that SSP tries to solve the lookalike domain problem.
Can we review the last couple of messages, please?
You said that a way to avoid making useless SSP lookups was only look up a
domain if you've previously seen a signed message from it.
I said, I get a bunch of messages purpo
John L wrote:
As it happens, lots of people around here have HSBC US accounts, the two
banks' branding is nearly identical, and it's not absurd to worry that
if someone put HSBC US account info into the HSBC UK phish, the bad guys
would be able to make use of it.
This assumes that SSP tries
On Dec 4, 2007, at 9:49 AM, Michael Thomas wrote:
John Levine wrote:
There is a trivial mechanism that can cut down SSP lookups to
almost nothing: don't query domains from which you've never
received a valid DKIM signature.
My network gets tons of fake mail from HSBC UK and no real mail
Michael Thomas wrote:
> At this point, making sweeping condemnations is pointless. If you want
> something in the draft changed, suggest specifics. Better yet: use the
> ISSUE mechanism for which Eliot is still paying attention, I believe.
>
Indeed I am. All you need to do to create an issu
There is a trivial mechanism that can cut down SSP lookups to almost
nothing: don't query domains from which you've never received a valid
DKIM signature.
My network gets tons of fake mail from HSBC UK and no real mail from
them since none of my North American users have an account there.
Charles Lindsey wrote:
> But it has no business whatsoever making normative statements about
> what verifiers are to do, so wording of the form "Verifiers MUST" is
> quite out pf place - that is BCP material.
Somehow, we need to tell verifiers what they need to do in order to
implement this specif
John Levine wrote:
There is a trivial mechanism that can cut down SSP lookups to almost
nothing: don't query domains from which you've never received a valid
DKIM signature.
My network gets tons of fake mail from HSBC UK and no real mail from
them since none of my North American users hav
> There is a trivial mechanism that can cut down SSP lookups to almost
> nothing: don't query domains from which you've never received a valid
> DKIM signature.
My network gets tons of fake mail from HSBC UK and no real mail from
them since none of my North American users have an account the
John Levine wrote:
In article <[EMAIL PROTECTED]> you write:
Review of:
DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)
Wow, thanks for a very thorough review.
The biggest problem with this draft is that it goes way beyond
defining a protocol.
Part of it describes the way th
Dave Crocker wrote:
3. Scope and scale of query traffic
SSP originally was constrained to apply only to unsigned mail. The current
specification applies to unsigned messages *and* signed messages where the
DKIM i= domain name does not match the rfc2822.From domain.
This
is a considerable
On Dec 3, 2007, at 3:37 PM, Dave Crocker wrote:
3. Scope and scale of query traffic
SSP originally was constrained to apply only to unsigned mail. The
current specification applies to unsigned messages *and* signed
messages where the DKIM i= domain name does not match the
rfc2822.From
Dave Crocker wrote:
2. Unsigned vs. Mismatched Signature
The original SSP specification applied only to unsigned messages. The
current
version includes mail that is signed but has different domains between the
DKIM i= attribute and the rfc2822.From field. Presumably, this new
capability
ove
Charles Lindsey suggested:
>> It really needs to back up and define how a sender publishes its
>> policy, how a recipient can look up a policy if it wants to do so,
>> then stop. That's all they need to interoperate.
>
> But that is going too far. It covers my #1, but not my #2, which
> includes
On Tue, 04 Dec 2007 04:23:27 -, John Levine <[EMAIL PROTECTED]> wrote:
The biggest problem with this draft is that it goes way beyond
defining a protocol.
True. Essentially. we have standards track documents and we have BCP (Best
Current Practice) documents, and indeed SSP could have bee
My comments inline below. They can be summarized as follows:
1. SSP does not dictate receiver behavior. SSP bends over backwards to
state receiver behavior is at receivers' discretion. If someone can find
someplace where SSP dictates receiver behavior please identify it so it
can be fixed.
2. Som
> Part of it describes the way that senders publish statements about
> their sending practices and the way that receivers can look for those
> statements, which is fine, but the rest attempts to tell receivers
> what to do with mail they have received, which is not.
For the 1000th time this is si
On Monday 03 December 2007 23:23, John Levine wrote:
> In article <[EMAIL PROTECTED]> you write:
> >Review of:
> >
> > DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)
>
> Wow, thanks for a very thorough review.
>
> The biggest problem with this draft is that it goes way beyond
> de
In article <[EMAIL PROTECTED]> you write:
>Review of:
>
> DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)
Wow, thanks for a very thorough review.
The biggest problem with this draft is that it goes way beyond
defining a protocol.
Part of it describes the way that senders publish
31 matches
Mail list logo
