Frank Ellermann wrote:
Michael Thomas wrote:
Can anybody describe what benefit SSP would give if it chose some
other address? Other than supposedly genuflecting to RFC2822?
I thought I've done this often enough, but maybe it wasn't clear:
From: [EMAIL PROTECTED]
Sender: [EMAIL PR
John L wrote:
Just to make sure I don't misunderstand anything, let's assume that
visasecurity.net doesn't publish any SSP, either because it doesn't
exist (its current state) or it's registered as a throwawy by someone
who doesn't publish any DNS records.
Then these headers are SSP compliant
John L wrote:
How does an SSP-like protocol do that? Assertions like "I am a phish
target" don't do it.
Why not?
Because you (the generic you, whoever publishes SSP) aren't credible
short of some reputation system which would make SSP irrelevant anyway.
Depends on the nature of the assert
Michael Thomas wrote:
> Can anybody describe what benefit SSP would give if it chose some
> other address? Other than supposedly genuflecting to RFC2822?
I thought I've done this often enough, but maybe it wasn't clear:
From: [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
This is a valid scena
Dave Crocker asked:
> [EMAIL PROTECTED] wrote:
>> MUA how to reliably display something useful about the above
>> information
>
> What is the basis for having the MUA as a goal in our work here?
Even if it isn't, we'll need a clearer answer for all the people who
expect it to be.
_
On Jan 16, 2008, at 4:54 PM, Jim Fenton wrote:
Arvel Hathcock wrote:
The debate here is whether or not it's mission-critical for SSP to
use From: in all cases or whether some other sender identity (like
Sender: header) could be used to equal effect generally or in
specific cases (like whe
d/(sorry. somehow clicked send rather than paste...)
Michael Thomas wrote:
Dave Crocker wrote:
Michael Thomas wrote: There is no statement that they cannot co-exist, so
it's probably better not to assert that such a statement is false.
The statement is that SSP is intended for processing by
Michael Thomas wrote:
Dave Crocker wrote:
Michael Thomas wrote:
Dave Crocker wrote:
J D Falk wrote:
Dave Crocker asked:
[EMAIL PROTECTED] wrote:
MUA how to reliably display something useful about the above
information
What is the basis for having the MUA as a goal in our work here?
E
Dave Crocker wrote:
Michael Thomas wrote:
Dave Crocker wrote:
J D Falk wrote:
Dave Crocker asked:
[EMAIL PROTECTED] wrote:
MUA how to reliably display something useful about the above
information
What is the basis for having the MUA as a goal in our work here?
Even if it isn't, we'll ne
Michael Thomas wrote:
Dave Crocker wrote:
J D Falk wrote:
Dave Crocker asked:
[EMAIL PROTECTED] wrote:
MUA how to reliably display something useful about the above
information
What is the basis for having the MUA as a goal in our work here?
Even if it isn't, we'll need a clearer answer f
Michael Thomas wrote:
Dave Crocker wrote:
Michael Thomas wrote:
What is an "SSP client"?
Something that initiates the SSP protocol.
So, the sysadmin who creates the SSP DNS record?
How does this relate to the original reference to an MUA?
Dave, this is hardly rocket science. Is an SMTP
Dave Crocker wrote:
J D Falk wrote:
Dave Crocker asked:
[EMAIL PROTECTED] wrote:
MUA how to reliably display something useful about the above
information
What is the basis for having the MUA as a goal in our work here?
Even if it isn't, we'll need a clearer answer for all the people who
e
Dave Crocker wrote:
Michael Thomas wrote:
Dave Crocker wrote:
Michael Thomas wrote:
RFC 5016 doesn't say anything about the role of the SSP client.
What is an "SSP client"?
Something that initiates the SSP protocol.
So, the sysadmin who creates the SSP DNS record?
How does this relate
Michael Thomas wrote:
Dave Crocker wrote:
Michael Thomas wrote:
RFC 5016 doesn't say anything about the role of the SSP client.
What is an "SSP client"?
Something that initiates the SSP protocol.
So, the sysadmin who creates the SSP DNS record?
How does this relate to the original refe
J D Falk wrote:
Dave Crocker asked:
[EMAIL PROTECTED] wrote:
MUA how to reliably display something useful about the above
information
What is the basis for having the MUA as a goal in our work here?
Even if it isn't, we'll need a clearer answer for all the people who
expect it to be.
"D
Dave Crocker wrote:
Michael Thomas wrote:
RFC 5016 doesn't say anything about the role of the SSP client.
What is an "SSP client"?
Something that initiates the SSP protocol.
Mike
___
NOTE WELL: This list operates according to
http://mip
Jon Callas wrote:
Please translate your grouchiness into concrete suggestions on what
if anything should change in draft. There are so many different issues
being discussed here that your +1 one is essentially useless because
it doesn't track to anything actionable.
I think we should fall bac
Arvel Hathcock wrote:
The debate here is whether or not it's mission-critical for SSP to use
From: in all cases or whether some other sender identity (like Sender:
header) could be used to equal effect generally or in specific cases
(like when there are multiple addresses in From).
Given that
Michael Thomas wrote:
RFC 5016 doesn't say anything about the role of the SSP client.
What is an "SSP client"?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/i
Jim Fenton wrote:
RFC 5016:
While a DKIM signed message
speaks for itself, there is ambiguity if a message doesn't have a
valid first party signature (i.e., on behalf of the [RFC2822].From
address): is this to be expected or not?
This requirements statement is actually se
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>
>
> Please translate your grouchiness into concrete suggestions on what
> if anything should change in draft. There are so many different issues
> being discussed here that your +1 one is essentially useless because
> it doesn't track to anything act
Jim Fenton wrote:
[Tracing SSP's paradigm change]
> I have asked you more than once to cite the basis for the alleged
> change, such as text from a previous draft describing this "simple
> idea". I have not received a response; since you are alleging
> that it has changed, it is up to you to s
Just to make sure I don't misunderstand anything, let's assume that
visasecurity.net doesn't publish any SSP, either because it doesn't exist
(its current state) or it's registered as a throwawy by someone who
doesn't publish any DNS records.
Then these headers are SSP compliant and not Suspic
How does an SSP-like protocol do that? Assertions like "I am a phish
target" don't do it.
Why not?
Because you (the generic you, whoever publishes SSP) aren't credible short
of some reputation system which would make SSP irrelevant anyway.
It's fine to make statements about your own practi
Dave Crocker wrote:
Jim Fenton wrote:
The goal of SSP is to determine the practices of the (alleged) author
of the message.
That certainly describes the engineering focus that has been taken for
the current draft. It does not necessarily represent the precise goal
of SSP:
RFC 5016:
John Levine wrote:
There'll surely be more of these 1:1 agreements, while we wait for SSP
to become useful. If we wait long enough, SSP won't even be necessary
for the big, high-value signers & verifiers.
Agreed. It's much better to define a protocol to do this now so the process
scale
Bill Oxley wrote:
> Am I correctly framing the thread?
Yes, renaming "SSP as is" to "ASP" would be clearer.
Authors would immediately see that binding "their"
address to some ASP of the domain owner is strange.
Or maybe they even like it, at least it is clearer.
Frank
Jon Callas wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 16, 2008, at 9:46 AM, Dave Crocker wrote:
Whereas SSP began as a simple idea as a means of deciding whether an
unsigned message should have been signed, it has morphed into an
effort to validate the From field. That is
Dave Crocker wrote:
[EMAIL PROTECTED] wrote:
MUA how to reliably display something useful about the above information
What is the basis for having the MUA as a goal in our work here?
RFC 5016 doesn't say anything about the role of the SSP client. That's
a feature IMO. How an SSP client use
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 16, 2008, at 3:32 PM, <[EMAIL PROTECTED]> wrote:
> I would suggest rescheduling weekly jabber sessions starting 30 days
> out, this way they can be on the schedule and canceled later if need
> be.
- -1.
I don't see that we have issues th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 16, 2008, at 9:46 AM, Dave Crocker wrote:
> Whereas SSP began as a simple idea as a means of deciding whether an
> unsigned message should have been signed, it has morphed into an
> effort to validate the From field. That is a very, very d
[EMAIL PROTECTED] wrote:
MUA how to reliably display something useful about the above information
What is the basis for having the MUA as a goal in our work here?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This li
I think I am missing something
DKIM base crypto claiming responsibility of the singing domain
SSP Senders signing policy, usage statement of DKIM by sender
ASP Authors signing policy who is not clearly a sender or a member of the
signing domain but wants to assert a policy anyway
MUA how to rel
Steve Atkins wrote:
On Jan 16, 2008, at 3:19 PM, Michael Thomas wrote:
Considering that this draft is already pretty different than the
original pre-ietf version, and it's likely to change more before
we issue an RFC, can we please have a version number in the RR
so that the software can trac
I would suggest rescheduling weekly jabber sessions starting 30 days out, this
way they can be on the schedule and canceled later if need be.
thanks,
Bill Oxley
-Original Message-
From: [EMAIL PROTECTED] on behalf of DKIM Chair
Sent: Wed 1/16/2008 2:34 PM
To: DKIM Mailing List
Subject:
On Jan 16, 2008, at 3:19 PM, Michael Thomas wrote:
Considering that this draft is already pretty different than the
original pre-ietf version, and it's likely to change more before
we issue an RFC, can we please have a version number in the RR
so that the software can track the changes?
I'm h
Considering that this draft is already pretty different than the
original pre-ietf version, and it's likely to change more before
we issue an RFC, can we please have a version number in the RR
so that the software can track the changes?
I'm happy with the way that DKIM did it, ie pre-rfc v=SSP0.
On Jan 16, 2008, at 1:49 PM, Arvel Hathcock wrote:
The debate here is whether or not it's mission-critical for SSP to
use From: in all cases or whether some other sender identity (like
Sender: header) could be used to equal effect generally or in
specific cases (like when there are multipl
On Wednesday 16 January 2008 16:49, Arvel Hathcock wrote:
> Given that it would solve the problem described in 1525 and also bring
> us closer to a consensus position perhaps this thread should discuss
> what is lost through utilization of the Sender header in at least some
> cases.
If it's allow
The debate here is whether or not it's mission-critical for SSP to use
From: in all cases or whether some other sender identity (like Sender:
header) could be used to equal effect generally or in specific cases
(like when there are multiple addresses in From).
Given that it would solve the pro
Frank Ellermann wrote:
If it's all the same for you and "high-value" signers like Yahoo!
SSP could as well try to be compatible with the RFC 2822 Sender.
Don't be surprised if ignoring Resent-* hurts it in the real world.
Focus on Sender is already shaky, SenderID fans might have other
ideas, an
On Jan 16, 2008, at 12:13 PM, Jim Fenton wrote:
The roles of sender and author are different. The fact that a
Sender header field is required when there are multiple authors is
not an assertion that the sender is, in fact, an author. It's
merely a consequence of the fact that the sender
> From: [EMAIL PROTECTED]
> Date: Wed, 16 Jan 2008 09:07:18 +0100
> Subject: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by firstAuthor
> breaks email semantics
>
> If "SSP strict" is bound to the "first author" it's DOA. :-(
>
> I fail to see why we should create an RFC only working
Frank Ellermann wrote:
Michael Thomas wrote:
Whereas SSP began as a simple idea as a means of deciding whether
an unsigned message should have been signed, it has morphed into
an effort to validate the From field. That is a very, very
different goal.
>> There'll surely be more of these 1:1 agreements, while we wait for SSP
>> to become useful. If we wait long enough, SSP won't even be necessary
>> for the big, high-value signers & verifiers.
>>
>
>Agreed. It's much better to define a protocol to do this now so the process
>scales and is not
J D Falk wrote:
>> The real world doesn't have multiple from addresses regardless
>> of what unearthed arcana somebody found in rfc2822.
> +1
> Let's design SSP for the real world.
In another article you wrote:
| If we wait long enough, SSP won't even be necessary for the big,
| high-value si
Frank Ellermann wrote:
Michael Thomas wrote:
Whereas SSP began as a simple idea as a means of deciding whether
an unsigned message should have been signed, it has morphed into
an effort to validate the From field. That is a very, very
different goal.
This is revisionist history. I've point
Owing to confusion about whether and when we're to have a teleconference, and to
concerns about whether this week's announcement was sufficiently timely, given
that confusion, Stephen and I think it best to cancel it, and, in fact, NOT TO
HOLD ANY of the teleconferences that we'd planned. We'll
Michael Thomas wrote:
>> Whereas SSP began as a simple idea as a means of deciding whether
>> an unsigned message should have been signed, it has morphed into
>> an effort to validate the From field. That is a very, very
>> different goal.
> This is revisionist history. I've pointed to both of
On Wednesday 16 January 2008 12:24, J D Falk wrote:
> > I fail to see why we should create an RFC only working for PayPal &
> > Co. - especially while they are still too timid to use FAIL in their
> > SPF or PRA policies. SSP "first author"
> > would be far more restrictive than anything SPF or PR
Michael Thomas wrote:
> Frank Ellermann wrote:
>> If "SSP strict" is bound to the "first author" it's DOA. :-(
>
> DOA. It might be helpful to get a sense of proportion here as this
> issue is so many angels on a pinhead in the real world.
> The real world doesn't have multiple from addresses reg
Michael Thomas wrote:
Dave Crocker wrote:
Evidently you missed the massive number of discussions both in the
working group and elsewhere that agreed that SSP was about unsigned
messages. And, just for the heck of it, note that you missed the
"error" about this in the DKIM Overview draft tha
Dave Crocker wrote:
Michael Thomas wrote:
Whereas SSP began as a simple idea as a means of deciding whether an
unsigned message should have been signed, it has morphed into an
effort to validate the From field. That is a very, very different goal.
This is revisionist history. I've pointed
Michael Thomas wrote:
DOA. It might be helpful to get a sense of proportion here as this
issue is so many angels on a pinhead in the real world. The real
world doesn't have multiple from addresses regardless of what unearthed
arcana somebody found in rfc2822.
Wasn't aware that you operated w
Michael Thomas wrote:
Dave Crocker wrote:
RFC 5016:
While a DKIM signed message
speaks for itself, there is ambiguity if a message doesn't have a
valid first party signature (i.e., on behalf of the [RFC2822].From
address): is this to be expected or not?
This requirements
Dave Crocker wrote:
Jim,
Please read the following carefully and assume, just as a hypothetical,
that I might actually have a legitimate basis for the assessment being
offered and that there is a chance that your views are not automatically
correct:
Jim Fenton wrote:
The goal of SSP is to
Frank Ellermann wrote:
If "SSP strict" is bound to the "first author" it's DOA. :-(
DOA. It might be helpful to get a sense of proportion here as this
issue is so many angels on a pinhead in the real world. The real
world doesn't have multiple from addresses regardless of what unearthed
arcana
Jim,
Please read the following carefully and assume, just as a hypothetical, that I
might actually have a legitimate basis for the assessment being offered and
that there is a chance that your views are not automatically correct:
Jim Fenton wrote:
The goal of SSP is to determine the practice
> I fail to see why we should create an RFC only working for PayPal &
> Co. - especially while they are still too timid to use FAIL in their
> SPF or PRA policies. SSP "first author"
> would be far more restrictive than anything SPF or PRA do.
It's very interesting that while PayPal may be "too t
Stephen Farrell wrote:
Dave Crocker wrote:
Stephen Farrell wrote:
Would you please explain the basis for assessing that this topic got
sufficient discussion and that there was rough consensus on it?
See above "I mainly saw..."
Qualifiers are nice, but pointing out that they were used does
Dave Crocker wrote:
Stephen Farrell wrote:
Would you please explain the basis for assessing that this topic got
sufficient discussion and that there was rough consensus on it?
See above "I mainly saw..."
Qualifiers are nice, but pointing out that they were used does not
provide an expl
Stephen Farrell wrote:
Would you please explain the basis for assessing that this topic got
sufficient discussion and that there was rough consensus on it?
See above "I mainly saw..."
Qualifiers are nice, but pointing out that they were used does not provide an
explanation for an assessme
Dave Crocker wrote:
Stephen Farrell wrote:
The attached contains our view on the current list of SSP issues [1]
except
for those opened in the last week or so. (Sorry the formatting's a bit
crappy.)
...
Can you check that these seem ok, or comment where they don't?
...
1521Limit the
On Tue, 15 Jan 2008 22:54:17 -, Jim Fenton <[EMAIL PROTECTED]> wrote:
We then are left with the dilemma of what to do when there is more than
one author. One option would be to look up the practices of all of the
authors and combine them.
That seems like a good argument for choosing w
Jim Fenton wrote:
> I'd like to explain the basis for what's currently in the draft.
[...]
Thanks. I try to explain my issues with this approach: When
the former MARID WG tried to "unify" SPF and "CallerID" (an
XML-over-DNS predecessor of SenderID/PRA) some folks strongly
objected, because a n
65 matches
Mail list logo
