On Tue, 01 Aug 2006 17:39:58 +0100 Stephen Farrell
[EMAIL PROTECTED] wrote:
John Levine wrote:
Scenario 3a:
1) A is a popular phishing target and prefers to suffer message
rejections for messages that don't carry a valid signature by A (or a
designated third party) than to have messages
On 2 Aug 2006 03:30:50 - John Levine [EMAIL PROTECTED] wrote:
There can be other policies but I require those two and am wondering why
there seems to be a tremendous pushback on this.
I think there is so much pushback on this because it is smething different.
You must have a very different
On Tue, 01 Aug 2006 17:29:21 -0700 Michael Thomas [EMAIL PROTECTED] wrote:
Is there any discovery related requirement here other than the must
complete
in deterministic number of steps one that we all seem to agree on?
Just a nit, I would have thought it would have been complete in no more
On Mon, 31 Jul 2006 10:02:07 -0400 (EDT) John L [EMAIL PROTECTED] wrote:
I have to say that the more discussion I see from advocates of SSP, the
less I think that anyone really understands what it's supposed to do.
So here's the main SSP axiom that I think should be self-evident, but
apparently
On Monday 31 July 2006 21:22, John Levine wrote:
I think this is the key issue then and we ought to focus on it. In
my view almost the entire point of a signing policy is constraining
whose signatures are considere authorized by the domain owner.
I'm assuming that when you say authorized,
On Thu, 27 Jul 2006 16:33:42 -0700 Jim Fenton [EMAIL PROTECTED] wrote:
Scott Kitterman wrote:
On Thursday 27 July 2006 14:00, [EMAIL PROTECTED] wrote:
My requirements
I sign all
I sign nothing
I sign only 3rd party
I sign all and 3rd party
I sign some mail
My Policy/Practice
I
On Thu, 27 Jul 2006 16:50:17 -0700 Jon Callas [EMAIL PROTECTED] wrote:
On 27 Jul 2006, at 4:01 PM, Scott Kitterman wrote:
To clarify, by me, I meant my domain. The problem is that in this
type of
scenario, there is no way to externally distinguish between mail
actually
sent
On Friday 28 July 2006 00:22, John Levine wrote:
Yes. What I want as a small domain owner is the ability to publish a
policy record that say that for mail sent (for some definition of sent
that we will probably have to argue about later) from my domain, the
domain(s) authorized to sign are
On Friday 28 July 2006 14:23, John Levine wrote:
Yes and what is another customer of the ISP submits mail using my From.
in virtually all cases today there is nothing to prevent that.
If you give your keys to untrustworthy third parties, all bets are
off. No amount of extra protocol goop
On Wednesday 26 July 2006 23:54, Hallam-Baker, Phillip wrote:
[mailto:[EMAIL PROTECTED] On Behalf Of Scott Kitterman
It might be useful (later, after the requirements discussion
is complete) to explore the feasibility of a common policy
record for the two for future revisions. The risk
On Thursday 27 July 2006 14:00, [EMAIL PROTECTED] wrote:
My requirements
I sign all
I sign nothing
I sign only 3rd party
I sign all and 3rd party
I sign some mail
My Policy/Practice
I sign all - every piece of mail purported to be from me must be signed
Must be signed by you are must
On Thursday 27 July 2006 17:57, Michael Thomas wrote:
Scott Kitterman wrote:
If I send mail through the mail server of isp.example.com and they sign
with my key, it matters a GREAT deal to me if they also sign other people
using my name with my key. This may be largely an operational
On Thursday 27 July 2006 18:31, Jon Callas wrote:
If I use isp.example.com and they sign messages with my name and a
key (theirs
or mine, doesn't matter) and they also sign messages actually sent
by joe
spammer (another one of their customers) with my name and a key
(again,
theirs or
On Thu, 27 Jul 2006 16:15:03 -0700 Jim Fenton [EMAIL PROTECTED] wrote:
Scott Kitterman wrote:
On Thursday 27 July 2006 18:31, Jon Callas wrote:
If I use isp.example.com and they sign messages with my name and a
key (theirs
or mine, doesn't matter) and they also sign messages actually sent
On Thursday 27 July 2006 22:51, [EMAIL PROTECTED] wrote:
Scott,
Perhaps an easier way, instead of you having to manage a DNS policy
record, you offload that to your provider
Policy.DKIM.foo.bar.com is a alias to dkim.provider.com who states the
policy you request. When changing outbound email
On Wednesday 26 July 2006 11:03, Arvel Hathcock wrote:
I think we've got a winner here -- and deliverable within a reasonable
time frame -- if we can keep the core requirements to a minimum.
As we think through the definition of minimum, I think it important that we
consider the class of
On Wednesday 26 July 2006 11:54, [EMAIL PROTECTED] wrote:
Scott,
I think that each domain would have a public key and the aggregator MTA
that is shared would sign on behalf of that domain
Jobob.com uses mx.isp.com to send mail
jobob.com would have a dns record containing public key
On Wednesday 26 July 2006 14:14, Michael Thomas wrote:
This is a really good instance of what the base level requirements are.
On the one hand we can say that the requirement is that an ISP signing
on behalf of a customer actually sign on behalf of the customer. That
is, the d=customer.com
On Wednesday 26 July 2006 15:26, Steve Atkins wrote:
MX 0 . seems to be the standard way of asserting that a domain
neither sends nor receives email.
It is a way that people do it. AFAIK, there is no standard that describe that
assertion.
Scott K
On Wednesday 26 July 2006 15:50, william(at)elan.net wrote:
On Wed, 26 Jul 2006, Scott Kitterman wrote:
On Wednesday 26 July 2006 15:26, Steve Atkins wrote:
MX 0 . seems to be the standard way of asserting that a domain
neither sends nor receives email.
It is a way that people do
On Wednesday 26 July 2006 16:28, Steve Atkins wrote:
There is no need to tie signing of email to this domain
sends no email. As such it's not something that _has_ to
be in SSP (unlike We send no non-signed email). If you
believe SSP has value you pretty much have to believe
the same of SPF,
On Wednesday 26 July 2006 16:36, Michael Thomas wrote:
Scott Kitterman wrote:
On Wednesday 26 July 2006 14:14, Michael Thomas wrote:
This is a really good instance of what the base level requirements are.
On the one hand we can say that the requirement is that an ISP signing
on behalf
On Wednesday 26 July 2006 15:58, Hallam-Baker, Phillip wrote:
SSP is not very relevant in this case as that spec is not on standards
track and DKIM is.
Last I checked, it was DKIM-base and DKIM-SSP and it's all supposed to be on
standards track. Has this changed?
Scott K
On Thursday 20 July 2006 11:51, Dave Crocker wrote:
Barry Leiba wrote:
Is the requirement that DKIM support both
822/2822 content (822 being the current standard) or is the intent
that DKIM is just required to support 2822 content?
I believe there are two parts to the answer to
On Wednesday 19 July 2006 21:23, John L wrote:
If you want your signatures to work, be sure the message you're signing is
as squeaky clean 2822 compliant as possible so as to give relay MTAs as
little incentive as possible to make helpful modifications. I realize
that we have existing
On Sat, 15 Jul 2006 08:10:50 -0700 Eric Allman [EMAIL PROTECTED]
wrote:
I have just submitted draft-ietf-dkim-base-04 to internet-drafts for
publication. An advance view can be found at
http://www.neophilic.com/~eric/DKIM/draft-ietf-dkim-base-04.txt
On Friday 14 July 2006 01:51, Mark Delany wrote:
Eric Allman wrote:
Folks OK with that?
-1
If a verifier has a verified email with a d= what is the fundamental
value-add on insisting that From: is a signed header? After all, a
minimalist verifier is going to query some database to ask
On Fri, 14 Jul 2006 13:46:34 -0600 Arvel Hathcock [EMAIL PROTECTED]
wrote:
1) I sign everything, for some value of everything
2) I don't send email at all.
I'm sorry I had to miss the meetings in Montreal.
I want to put forth my belief that, whatever form SSP ultimately takes,
being able
On Thursday 13 July 2006 17:17, Hector Santos wrote:
- Original Message -
From: Barry Leiba [EMAIL PROTECTED]
As chair, I see a growing consensus to do it that way. Let's try to
resolve this issue tout de suite, and move on. I'd like to hear from
people who think we should have
On Thursday 13 July 2006 18:09, Dave Crocker wrote:
Scott Kitterman wrote:
I think that a requirement to sign RFC 2822 required identity header
fields (From and Sender if present) makes a lot of sense. I expect that
if we don't make this a requirement in Base, then in operations
On Thursday 13 July 2006 23:19, Dave Crocker wrote:
Eric Allman wrote:
Folks OK with that?
+1
d/
+1
Scott K
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
On 04/26/2006 17:59, Douglas Otis wrote:
On Apr 26, 2006, at 12:32 PM, J.D. Falk wrote:
On 2006-04-25 08:51, Douglas Otis wrote:
Well vetted sources can be indicated by the signer with some type
of notation or semaphore.
So, the signer -- who is most often the sender -- indicates to
On 04/19/2006 23:51, Jim Fenton wrote:
Scott Kitterman wrote:
There is another potential issue with this approach if we get to a
dedicated RR type. While not an issue when using TXT, there are
resolvers that will fail to respond when queried with an unknown RR type
(no I don't know
On 04/20/2006 09:53, Douglas Otis wrote:
On Thu, 2006-04-20 at 07:53 -0400, Scott Kitterman wrote:
WRT your point, I agree. Perhaps we need to add another bit along the
lines of, If an email is deferred based on lack of response to the
query for the public key, the verifier SHOULD
On 04/20/2006 18:53, Michael Thomas wrote:
Scott Kitterman wrote:
On 04/19/2006 23:51, Jim Fenton wrote:
This points out another problem: if a verifier defers verification or
acceptance of a given message, it SHOULD maintain enough state so that
the message may be accepted after some number
Because if we put that in the spec then we've effectively gotten rid of x=
because no one would use it then and that's what he wants perhaps?
Scott K
On 04/19/2006 18:54, [EMAIL PROTECTED] wrote:
Why would a verifyer refuse a message that had a value for x=?
Verifiers MAY support checking of
On 04/14/2006 10:36, Hector Santos wrote:
In section 6.2 Get The Public Key, we have step #2
| 2. If the query for the public key fails to respond, the verifier
| SHOULD defer acceptance of this email (normally this will be
| achieved with a 451/4.7.5 SMTP reply code).
This
On 04/18/2006 14:18, Douglas Otis wrote:
On Apr 18, 2006, at 10:42 AM, Scott Kitterman wrote:
From a protocol design perspective, I think the right answer is to
design for the case where the receiving MTA/MDA will check the
signature and record a result that, if appropriate, an MUA can use
On 04/18/2006 15:43, Douglas Otis wrote:
On Apr 18, 2006, at 11:33 AM, Scott Kitterman wrote:
I would not say that we shouldn't include DKIM protection beyond
SMTP, but that whatever happens after delivery shouldn't distract
us from the primary use case.
Or the primary goal of offering
a reputation system of some limited kind and reputation
is out of bounds, I guess I don't understand what you think we are doing
here?
Scott Kitterman
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
On 03/09/2006 17:10, Dave Crocker wrote:
Folks,
There is now a list for pursuing the specific topic of the Auth-Results
specification.
The mailing list is [EMAIL PROTECTED]
To subscribe, go to:
http://mipassoc.org/mailman/listinfo/mail-vet-discuss
The list is intended for specific,
On 02/27/2006 10:58, Hallam-Baker, Phillip wrote:
[mailto:[EMAIL PROTECTED] On Behalf Of Scott Kitterman
Might it be useful to break the exact crypto algorithm out
into a separate (very short) RFC so that it can be revised as
necessary? Something like:
A validator MUST support
it becomes clear what the next
high strength hash algorithm is or if SHA-1 is determined to be broken to the
extent it should be deprecated.
None of this affects what has to be implemented now, but may make future
transitions easier.
Scott Kitterman
___
NOTE
On 02/23/2006 12:16, Douglas Otis wrote:
On Feb 22, 2006, at 7:52 PM, Douglas Otis wrote:
On Feb 22, 2006, at 6:47 PM, Hallam-Baker, Phillip wrote:
In rebuttal to Doug's point about not depending on the DNS
supporting longer key sizes, an ECDSA key that gives equivalent
strength to a 128
On 01/19/2006 15:50, Michael Thomas wrote:
Earl Hood wrote:
On January 19, 2006 at 03:10, Hector Santos wrote:
Sender-Signing Policy (SSP):
NONE (no policy)
o=? WEAK (signature optional, no third party)
o=~ NEUTRAL (signature optional, 3rd party allowed)
o=-
On 01/19/2006 17:50, Michael Thomas wrote:
Scott Kitterman wrote:
On 01/19/2006 15:50, Michael Thomas wrote:
Earl Hood wrote:
On January 19, 2006 at 03:10, Hector Santos wrote:
Sender-Signing Policy (SSP):
NONE (no policy)
o=? WEAK (signature optional, no third party)
o
I think we've wandered pretty far afield here and I'm not going to follow.
Don't take my lack of response for agreement.
Scott K
___
ietf-dkim mailing list
http://dkim.org
On 01/04/2006 14:20, Douglas Otis wrote:
I really hate it that we are debating SPF on the DKIM list, but it seems
unavoidable...
SPF and SSP will have similar problems. With SPF, you have pointed
out the RFC1123 5.3.6(a) issue that may cause those concerned with
the resulting disappearance
On Sun, 20 Nov 2005 16:14:48 -0800 Jim Schaad [EMAIL PROTECTED]
wrote:
Jim,
I have some comments on this draft that I would like to make.
...
F. Potential Extensions to the base document (I would prefer this to be
labeled as appendix rather than section of the document for clarity). This
On Sun, 20 Nov 2005 18:37:06 -0800 Douglas Otis [EMAIL PROTECTED]
wrote:
On Sun, 2005-11-20 at 14:49 -0500, Scott Kitterman wrote:
On 11/19/2005 14:50, Douglas Otis wrote:
You agree that SSP does not provide a mechanism to prevent spoofing
without reliance upon visual presentations
On Mon, 21 Nov 2005 07:50:25 -0800 Douglas Otis [EMAIL PROTECTED]
wrote:
On Mon, 2005-11-21 at 10:12 -0500, Scott Kitterman wrote:
SSP doesn't do what it doesn't do. SSP is not and does not pretend to
be
the ultimate solution to phishing. Your concern appears to be with
problems that SSP
On 11/19/2005 14:50, Douglas Otis wrote:
You agree that SSP does not provide a mechanism to prevent spoofing
without reliance upon visual presentations...
No. I said pretty much the exact opposite of that.
Scott K
___
ietf-dkim mailing list
Doug,
I haven't seen anyone else jumping on the bandwagon for your approach. Rather
than continue to bog down the discussion here, wouldn't it make more sense
for you to go off and develop your draft and then submit it as an individual
submission once DKIM-base is submitted?
Scott K
On Sat, 19 Nov 2005 07:27:10 -0800 Douglas Otis [EMAIL PROTECTED]
wrote:
On Fri, 2005-11-18 at 22:29 -0500, Scott Kitterman wrote:
That or the title of the thread is bogus.
I could equally say if we were trying your approach something like
Doug's
non-SSP security relies upon every MUA
On 11/16/2005 13:32, Douglas Otis wrote:
... Would that get the policy debate off the table?
-Doug
No.
Scott K
___
ietf-dkim mailing list
http://dkim.org
On 11/16/2005 16:32, Douglas Otis wrote:
On Nov 16, 2005, at 12:47 PM, Stephen Farrell wrote:
A claim made in the charter of detecting spoofing depends upon a
comparison of the signing-domain with the email-address domain.
There is no such absolute claim that I can see in the draft
On 11/13/2005 14:41, Tony Hansen wrote:
To get past the contentions around SSP, I'm wondering if we should
change the wording slightly, as follows.
Tony Hansen
[EMAIL PROTECTED]
Barry Leiba wrote:
-
DRAFT IETF WORKING
On 11/14/2005 18:25, Douglas Otis wrote:
On Nov 14, 2005, at 2:04 PM, Jim Fenton wrote:
Barry,
DESCRIPTION OF WORKING GROUP:
The Internet mail protocols and infrastructure allow mail sent
from one
domain to purport to be from another. While there are sometimes
legitimate
On 11/12/2005 11:07, Barry Leiba wrote:
Here it is, appended (not attached) below.
Barry
...
I like this. I think it is good.
Scott K
___
ietf-dkim mailing list
http://dkim.org
Doug,
I don't know that we're getting any closer to any kind of agreement. Given
the request to focus on the charter, let's just let this thread end (I hear
cheers in the distance I think).
Scott K
___
ietf-dkim mailing list
http://dkim.org
On 11/11/2005 18:10, Dave Crocker wrote:
Folks,
Having said all of that, I am at a complete loss as to much of this
debate. If SSP isn't formalized in this group then you can be certain
that bi-lateral or non-standard forms will emerge in parallel to
DKIM. Those select domain - and we
On 11/06/2005 17:35, Douglas Otis wrote:
On Nov 5, 2005, at 9:16 PM, Dave Crocker wrote:
However, the best way to gauge this probably is for you to specify
the text that you propose to have changed in the charter.
While there appears to be some support for imposing a requirement
that From
On 11/07/2005 20:37, Douglas Otis wrote:
DKIM without SSP can be better than with SSP. Take out the SSP
approach, and there should be fewer concerns with respect to
potential impact, while there would not be any benefit lost. If
anything there would be greater benefits as this approach
On Mon, 7 Nov 2005 19:01:40 -0800 Douglas Otis [EMAIL PROTECTED] wrote:
On Nov 7, 2005, at 6:24 PM, Scott Kitterman wrote:
On 11/07/2005 20:37, Douglas Otis wrote:
DKIM without SSP can be better than with SSP. Take out the SSP
approach, and there should be fewer concerns with respect
On 11/02/2005 13:19, Douglas Otis wrote:
...
...of no signature? This seems force the use of SSP and completely
ignore the reputation of the signing-domain, does it not?
That's a feature, not a bug.
Scott K
___
ietf-dkim mailing list
http://dkim.org
Doug,
I don't imagine we are ever going to agree on this.
I really don't understand your view of the world and I am pretty well
convinced I never will.
I do not think that adding another level of unpredictable heuristics to spam
filtering and calling it reputation is a particularly good
in detecting
falsehood seems more a question for philosophy rather than engineering. I
think it's a distraction that we should just dismiss.
Yes. Please.
Scott Kitterman
___
ietf-dkim mailing list
http://dkim.org
On 11/01/2005 15:41, Arvel Hathcock wrote:
I'm new to the IETF process but I've had the amazing good fortune of having
excellent guides. They've encouraged me to speak up when I've had
something to say and I want to pass that advice on to whomever might be
lurking on this list or who may be
On 11/01/2005 22:11, Douglas Otis wrote:
...
On a daily basis, our dynamic lists fluctuate in the millions,
What is the antecedent of 'our' in this message?
Scott K
___
ietf-dkim mailing list
http://dkim.org
On 10/28/2005 08:11 pm, Frank Ellermann wrote:
Stephen Farrell wrote:
If the above is possible, how should/can it be avoided?
Never ever sign anything that is already signed. Or at the
very minimum don't drop signatures.
It's the point of DKIM to find some accountable party as
near to
On 10/26/2005 07:24 pm, Douglas Otis wrote:
On Oct 26, 2005, at 3:32 PM, Scott Kitterman wrote:
No we should not.
Is there anything in this line of reasoning that isn't duplicative
of the last
time we went through your view on this in August?
At that time, if I recall, the problem
Doug,
So is it your view that DKIM roughly at it stands, with SSP and without your
Opaque identifier is fatally flawed and shouldn't go forward?
Scott K
___
ietf-dkim mailing list
http://dkim.org
No we should not.
Is there anything in this line of reasoning that isn't duplicative of the last
time we went through your view on this in August?
Scott Kitterman
___
ietf-dkim mailing list
http://dkim.org
' or 'lookalike' addresses in a phishing
attack.
Scott Kitterman
___
ietf-dkim mailing list
http://dkim.org
certainly said that it (meaning forgery protection) is the application
that's of most interest to me.
Scott Kitterman
___
ietf-dkim mailing list
http://dkim.org
It has been brought to my attention off-list that some consider my
postings here inappropriate. I'm sorry. That hadn't been my intent.
Scott Kitterman
___
ietf-dkim mailing list
http://dkim.org
Sender Signing Policy (I'm not saying
the current draft is perfect) for an uncertain, undesigned, and
undocumented automated abuse reporting infrastructure.
You get to call this 'simple' from a DKIM perspective only by declaring all
this complexity external to DKIM.
Scott Kitterman
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
takes.
Scott Kitterman
___
ietf-dkim mailing list
http://dkim.org
with or the one
without SSP or are you saying that's true of either one?
Scott Kitterman
___
ietf-dkim mailing list
http://dkim.org
that there are those who do not want SSP for reasons
that aren't clear to me. I'd rather get SSP in scope once and for all
and not have to have the scope arguement again after base is published.
Same starting line for both, not necessarily the same finish line.
Scott Kitterman
is a charter that just does that base
and defers SSP to some future effort. The charter needs to include both.
Scott Kitterman
___
ietf-dkim mailing list
http://dkim.org
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
personally have very little interest in. I am
curious if I'm alone in that regard? If that's all DKIM is for, then
I've got better ways to spend my spare time.
Thanks,
Scott Kitterman
___
ietf-dkim mailing list
http://dkim.org
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
surprising and difficult to fathom.
Scott Kitterman
___
ietf-dkim mailing list
http://dkim.org
already.
Scott Kitterman
___
ietf-dkim mailing list
http://dkim.org
blacklist if someone doesn't like my mail? What benifit is being
offered that I should risk that?
Scott Kitterman
___
ietf-dkim mailing list
http://dkim.org
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
in
the working group output, but that detailed designs aren't necessary.
Perhaps not even that. Perhaps the WG just does the SMTP part?
Scott Kitterman
___
ietf-dkim mailing list
http://dkim.org
of
SSP in the working group effort would define as the bad act that DKIM
will prevent in the absence of a sender policy of some kind.
Scott Kitterman
___
ietf-dkim mailing list
http://dkim.org
information, the question in my mind is what can you do with it?
Scott Kitterman
___
ietf-dkim mailing list
http://dkim.org
anything
useful.
Scott Kitterman
___
ietf-dkim mailing list
lt;http://dkim.orggt;
301 - 393 of 393 matches
Mail list logo
