Jim Fenton wrote:
Hector Santos wrote:
With a signature existing, you will always need to check the SSP in order to
check for a Never Sign or We don't send mail from domain. Its Forged
expectation.
So you always need to check for SSP first.
So you mean with a valid signature
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 by the
Hector Santos wrote:
With a signature existing, you will always need to check the SSP in order to
check for a Never Sign or We don't send mail from domain. Its Forged
expectation.
So you always need to check for SSP first.
So you mean with a valid signature existing? If so, isn't that a
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 is going to change that.
R's,
John
On Jul 28, 2006, at 11:23 AM, 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
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 Jul 28, 2006, at 11:55 AM, John L wrote:
If you give your keys to untrustworthy third parties, all bets
are off. No amount of extra protocol goop is going to change that.
Scott has raised a different concern. An ISP may not restrict
what From is used when signing with the ISP's
On 28 Jul 2006, at 12:12 PM, Scott Kitterman wrote:
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,
Especially since one can achieve that same effect by having an SSP
that says I sign everything and then don't sign any email.
One can achieve the same effect perhaps but it's not as easy to
understand or explain:
Potential customer question: How do I communicate that I don't send mail?
I've always wondered why dkim is taking on the task of supporting
I don't send mail since the statement makes no reference to
signatures at all.
Here's my own view. DKIM is not only (or merely) the mechanics of
digital signature construction and verification. Signatures are just a
tool --
On Thu, Jul 27, 2006 at 03:02:55AM -0500, Arvel Hathcock allegedly wrote:
Especially since one can achieve that same effect by having an SSP
that says I sign everything and then don't sign any email.
One can achieve the same effect perhaps but it's not as easy to
understand or explain:
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 Jul 27, 2006, at 2:09 AM, Mark Delany wrote:
On Thu, Jul 27, 2006 at 03:02:55AM -0500, Arvel Hathcock allegedly
wrote:
Especially since one can achieve that same effect by having an
SSP that says I sign everything and then don't sign any email.
One can achieve the same effect perhaps
In [EMAIL PROTECTED] Steve Atkins [EMAIL PROTECTED] writes:
On Jul 26, 2006, at 12:13 PM, Hector Santos wrote:
[mention of the SPF record v=spf1 -all as a we never send email
notification]
MX 0 . seems to be the standard way of asserting that a domain
neither sends nor receives email.
On Jul 27, 2006, at 10:20 AM, Stephen Farrell wrote:
Douglas Otis wrote:
On Jul 27, 2006, at 2:09 AM, Mark Delany wrote:
So it could be an alias entry in SSP then. One is called I sign
all and the other is called I don't send. They both set the
same bit.
There is a slight difference
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
I sign nothing - If mail arrives with a DKIM sig I didn't send it
I sign only 3rd party - I
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
+1
SPF is vastly better than MX 0 .
People really should not do that sort of thing.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of wayne
Sent: Thursday, July 27, 2006 1:09 PM
To: IETF DKIM WG
Subject: Re: [ietf-dkim] The URL to my paper
Mark Delany wrote:
Besidewhich wont a UI hide the nitty gritty of what bits are set
where?
But you know, whatever. If people want a two-bit solution for a
one-bit problem. That's ok :-)
Well, no, It really isn't.
For example, it leads to multiple ways of doing the same thing, which at
Scott Kitterman wrote:
As we think through the definition of minimum, I think it important that we
consider the class of domains that are not supported by one or more dedicated
mail servers. ...
Is the concept of operations that these servers should sign using the
provider's key (so all
Scott Kitterman wrote:
On Thursday 27 July 2006 15:13, Dave Crocker wrote:
Scott Kitterman wrote:
As we think through the definition of minimum, I think it important that
we consider the class of domains that are not supported by one or more
dedicated mail servers. ...
Is the concept
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
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 question, but
the
protocols have to support getting a reliable answer to it.
It
Scott Kitterman wrote:
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
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
So it could be an alias entry in SSP then. One is called I sign all
and the other is called I don't send. They both set the same bit.
Besidewhich wont a UI hide the nitty gritty of what bits are set
where?
Hadn't thought of that along those lines. Yeah, that could work and I'm
perfectly
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
by joe
spammer (another one of their customers) with my name and a
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 by the vanity domain owner and mail sent by another customer of
isp.example.com
I
As an example, an ISP that has 10k business customers who potentially
will want signed mail a
Commercial.isp.com signing domain would assert
I only sign 3rd party
Using current software I would only sign customers that have been
pre-approved. If those customers SPAM for whatever reason, neglect 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
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 providers the new
provider aliases policy.foo.bar.com to
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
As an example, an ISP that has 10k business customers who potentially
will want signed mail a Commercial.isp.com signing domain would
assert I only sign 3rd party
It may well be true that you only sign third party mail, but I still
don't understand what use a recipient might make of that
Let's finish the DKIM signature spec, then see if we can agree to get
out the smallest version of SSP on which we can get reasonable
agreement (probably two bits, one for signs everything, the other for
sends no mail), then we can return to the grand plans.
+1
The more I ponder this topic
Arvel Hathcock wrote:
Let's finish the DKIM signature spec, then see if we can agree to get
out the smallest version of SSP on which we can get reasonable
agreement (probably two bits, one for signs everything, the other for
sends no mail), then we can return to the grand plans.
+1
Arvel Hathcock wrote:
The more I ponder this topic the more I'm inclined to believe that the
flags I sign everything and I don't send mail are the base concerns
that DKIM SSP must address. I'm optimistic that, if one isn't
fundamentally opposed to the entire SSP concept from the outset, we
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 Wed, Jul 26, 2006 at 04:30:15PM +0100, Stephen Farrell allegedly wrote:
I've always wondered why dkim is taking on the task of supporting
I don't send mail since the statement makes no reference to
signatures at all. Arguably, that's something that should be dealt
with by someone else, who
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 information
mx.isp.com would sign using jobob.com keys.
Now conversely
Stephen Farrell wrote:
I've always wondered why dkim is taking on the task of supporting
I don't send mail since the statement makes no reference to
signatures at all.
I suspect this is a good example of the confusion between describing the problem
domain DKIM is pursuing versus the
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 Jul 26, 2006, at 12:13 PM, Hector Santos wrote:
I've always wondered why dkim is taking on the task of supporting
I don't send mail since the statement makes no reference to
signatures at all. Arguably, that's something that should be dealt
with by someone else, who might also think
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 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 it. AFAIK, there is no standard that
describe that assertion.
[mailto:[EMAIL PROTECTED] On Behalf Of Scott Kitterman
Is the concept of operations that these servers should sign
using the provider's key (so all signatures for the domain
are 3rd party) or that the provider should manage multiple
keys to support per domain keys and sign the messages
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 it.
- Original Message -
From: Steve Atkins [EMAIL PROTECTED]
MX 0 . seems to be the standard way of asserting that a domain
neither sends nor receives email. Shoehorning the same assertion
into multiple different pseudo-standards simply leads to contradiction.
MX is about INBOUND. Not
Mark Delany wrote:
On Wed, Jul 26, 2006 at 04:30:15PM +0100, Stephen Farrell allegedly wrote:
I've always wondered why dkim is taking on the task of supporting
I don't send mail since the statement makes no reference to
signatures at all. Arguably, that's something that should be dealt
with
Hector,
Hector Santos wrote:
I don't see why people would pay any more attention to an SSP
statement of such than they do to SPF statements of it. Just the
opposite, shoehorning unneeded cruft into SSP makes it less likely
that people will pay any attention to it, I'd think.
Steve, the SPF
On Jul 26, 2006, at 1:04 PM, Hector Santos wrote:
- Original Message -
From: Steve Atkins [EMAIL PROTECTED]
MX 0 . seems to be the standard way of asserting that a domain
neither sends nor receives email. Shoehorning the same assertion
into multiple different pseudo-standards
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,
- Original Message -
From: Steve Atkins [EMAIL PROTECTED]
To: ietf-dkim@mipassoc.org
Sent: Wednesday, July 26, 2006 4:28 PM
Subject: Re: [ietf-dkim] The URL to my paper describing the DKIM policy
options
That's not a reason not to add support for this to SSP, though,
as long as you
[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 associated
with complexity and the possibility of
On Mon, 2006-07-24 at 22:27 -0700, Patrick Peterson wrote:
http://www.ietf.org/internet-drafts/draft-hallambaker-pcon-00.txt
I think this is a great idea and am surprised it didn't generate more
traffic on the list. It's not easy to cram needed new functionality into
a backward-compatible
Patrick Peterson wrote:
- Original Message -
From: Hallam-Baker, Phillip [EMAIL PROTECTED]
To: IETF-DKIM ietf-dkim@mipassoc.org
Sent: Wednesday, July 12, 2006 2:05 PM
Subject: [ietf-dkim] The URL to my paper describing the DKIM
policy options
I submitted the draft in both pdf and
CC'd to namedroppers for wider discussion.
There are two wildcard problems
1) Wildcards do not match a node if there is any data at the node
*.example.com TXT hello will not match if there is any record at
a.example.com
2) It is not possible to define a midpoint wildcard
57 matches
Mail list logo
