All of those clarifications were also filed as errata. All of the ones
that were ratified by the working group should be incorporated as part
of a 4871+5672bis. In other words, yes, that's definitely one of the
tasks that should be part of moving the document forward.
Tony Hansen
On 10/26/09 9:40 PM, Dave CROCKER wrote:
Murray S. Kucherawy wrote:
Specifically, it's clear to me, from WG
conversations and hallway track at MAAWG and elsewhere, that more guidance is
needed in terms of how DKIM results get interpreted in certain contexts such
as mailing lists
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Barry Leiba
Sent: Wednesday, September 30, 2009 9:01 AM
To: IETF DKIM WG
Subject: [ietf-dkim] DKIM charter update proposal
Pasted below is my proposal for an updated DKIM
It occurs to me that there are a bunch of technical clarifications to
the spec that (I think) Tony wrote up after the connectathon a year or
so ago. If we want to move to DS, would it be worth a pass over 4871
to incorporate them? I don't think there have been any more recently,
so this would
Murray S. Kucherawy wrote:
Specifically, it's clear to me, from WG
conversations and hallway track at MAAWG and elsewhere, that more guidance is
needed in terms of how DKIM results get interpreted in certain contexts such
as mailing lists and other third-party signing. Even if the
Murray S. Kucherawy wrote:
I'd invite the people that have been involved in those conversations to state
specifically what areas draft-ietf-dkim-deployment could cover to close these
gaps.
I seek one thing:
Codify the semantics regarding ADSP implementation vs Forwarder DKIM
On 10/24/2009 11:40 PM, SM wrote:
At 20:19 24-10-2009, Scott Kitterman wrote:
Where I disagree is that we have a sufficient basis to declare it stable.
The interoperability issues have been addressed in the implementation
I use. There are still some quirks which are MTA related.
I think
It's fairly easy to demonstrate interoperability of protocols, but
usefulness is much more difficult. DKIM is an infrastructure protocol,
designed to provide a basis for other mechanisms, such as domain-based
reputation, to operate. Those other mechanisms are as yet nascent; how
does one
It's fairly easy to demonstrate interoperability of protocols, but
usefulness is much more difficult. DKIM is an infrastructure protocol,
designed to provide a basis for other mechanisms, such as domain-based
reputation, to operate. Those other mechanisms are as yet nascent; how
does one
Barry Leiba wrote:
I think dormant will work, if this is the route we decide to take.
But I think we won't be completely dormant, anyway, if we're gathering
data and reviewing the informational documents, and perhaps updating
them.
I think it would be nice if we had (if already done,
I think dormant will work, if this is the route we decide to take.
But I think we won't be completely dormant, anyway, if we're gathering
data and reviewing the informational documents, and perhaps updating
them.
I think it would be nice if we had (if already done, reestablish) a
foundation
On 24/10/2009, at 15:13, Barry Leiba
barryleiba.mailing.li...@gmail.com wrote:
My opinion is that N1 is arguable, but that N2 and N3 are not the
case, and that we shouldn't resist advancing DKIM base to DS for
reasons N2 and N3. My opinion is also that, while N1 might be true,
the
On Sat, 24 Oct 2009 18:13:41 -0400 Barry Leiba
barryleiba.mailing.li...@gmail.com wrote:
As I see it, the reasons to go to DS would be
Y1. to progress a fairly stable standard along a defined track, and
Y2. to review it and perhaps clean it up a little along the way, and
Y3. to get broader
Barry Leiba wrote:
Coming back to this: I've still seen very little direct input on the
charter proposal. JD likes it. Dave made some specific comments,
which I responded to; there've been no other comments on what Dave's
said. There've been no other specific proposals for changes to the
Jim Fenton wrote:
It's fairly easy to demonstrate interoperability of protocols, but
usefulness is much more difficult. DKIM is an infrastructure protocol,
designed to provide a basis for other mechanisms, such as domain-based
reputation, to operate. Those other mechanisms are as yet
- Barry Leiba barryleiba.mailing.li...@gmail.com wrote:
Coming back to this: I've still seen very little direct input on the
charter proposal. JD likes it. Dave made some specific comments,
which I responded to; there've been no other comments on what Dave's
said. There've been no
Jim Fenton wrote:
Good question. I wasn't proposing that we judge usefulness at all; I
was responding to suggestions from others that measuring usefulness be
included in the charter.
Well, I can certainly understand producing documents that discuss efficacy (and
maybe even how to achieve
Dave CROCKER wrote:
Jim Fenton wrote:
It's fairly easy to demonstrate interoperability of protocols, but
usefulness is much more difficult. DKIM is an infrastructure protocol,
designed to provide a basis for other mechanisms, such as domain-based
reputation, to operate. Those other
On 10/23/2009 05:08 PM, Dave CROCKER wrote:
Jim Fenton wrote:
Good question. I wasn't proposing that we judge usefulness at all; I
was responding to suggestions from others that measuring usefulness be
included in the charter.
Well, I can certainly understand producing documents that
Jim Fenton wrote:
Dave CROCKER wrote:
Jim,
This appears to be imposing criteria that go considerably beyond the
IETF's requirements for Draft.
From the standpoing of IESG process, how is this legitimate?
Good question. I wasn't proposing that we judge usefulness at all; I
was
On Fri, 23 Oct 2009 16:54:52 -0700 Dave CROCKER d...@dcrocker.net wrote:
Jim Fenton wrote:
It's fairly easy to demonstrate interoperability of protocols, but
usefulness is much more difficult. DKIM is an infrastructure protocol,
designed to provide a basis for other mechanisms, such as
Comments are inline.
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Barry Leiba
Sent: Sunday, October 18, 2009 11:55 AM
To: IETF DKIM WG
Subject: Re: [ietf-dkim] DKIM charter update proposal
Coming back to this: I've
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Daniel Black
Sent: Sunday, October 18, 2009 6:00 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] DKIM charter update proposal
I think supporting data collection
On Oct 19, 2009, at 10:07 AM, Murray S. Kucherawy wrote:
I think supporting data collection by those deploying it would be
facilitated
by getting http://tools.ietf.org/html/draft-kucherawy-dkim-reporting-05
to a
RFC would be good. Eventually we should come back to data collection
later
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Steve Atkins
Sent: Monday, October 19, 2009 10:42 AM
To: IETF DKIM WG
Subject: Re: [ietf-dkim] DKIM charter update proposal
I'd be fine with doing that through this WG
Steve Atkins wrote:
It's a DKIM thing. If it's going to be done, this group is the group
to do it.
Backdooring it through another group is, at best, not going to be as
effective I don't think.
Adding to the responses already posted: It legitimately touches two possible
working
Hi Barry,
At 15:16 18-10-2009, Barry Leiba wrote:
As Stephen says, the intent has always been to roll 5671 into 4871.
That was one reason we wanted to get 5672 done as quickly as possible,
so that the six-month timer wouldn't get in our way. By the time
we're ready to have 4871bis out as DS, if
Coming back to this: I've still seen very little direct input on the
charter proposal. JD likes it. Dave made some specific comments,
which I responded to; there've been no other comments on what Dave's
said. There've been no other specific proposals for changes to the
text.
Franck suggested
Barry Leiba wrote:
Coming back to this: I've still seen very little direct input on the
charter proposal. JD likes it. Dave made some specific comments,
which I responded to; there've been no other comments on what Dave's
said. There've been no other specific proposals for changes to the
At 08:54 18-10-2009, Barry Leiba wrote:
Coming back to this: I've still seen very little direct input on the
[snip]
The previously chartered deliverables for the DKIM working group
have been completed:
There has been a lot of discussion of these deliverables after the
RFCs were
SM wrote:
At 08:54 18-10-2009, Barry Leiba wrote:
* Collect data on the deployment and interoperability of the
Author Domain Signing Practices protocol (RFC 5617), and
determine if/when it's ready to advance on the standards track.
Update it at Proposed Standard or advance it to
On Sun, 18 Oct 2009 11:54:47 -0400 Barry Leiba
barryleiba.mailing.li...@gmail.com wrote:
Some have opined that it's even too early to consider taking the base
DKIM protocol to Draft Standard; let's make sure we have consensus on
that point, one way or the other.
I'm going to re-iterate my point
On Oct 18, 2009, at 1:52 PM, Scott Kitterman wrote:
On Sun, 18 Oct 2009 11:54:47 -0400 Barry Leiba
barryleiba.mailing.li...@gmail.com wrote:
Some have opined that it's even too early to consider taking the base
DKIM protocol to Draft Standard; let's make sure we have consensus on
that
(shaking head)
No need to do that, nor say that.
Is there a reason why my suggestions are off the table?
Namely, codify the existing specification and specifically adding
simple text that imply:
Forwarders SHOULD|MUST NOT break ADSP domain messages.
or
Forwarders SHOULD|MUST
I'm going to re-iterate my point for this perspective. We do not yet have
a broad experience base with deployment of DKIM by large, heterogeneous
organizations. This is a hard problem for them because they first have to
get their outbound mail architecture under control.
My view is that
Barry Leiba wrote:
Namely, codify the existing specification and specifically adding
simple text that imply:
Forwarders SHOULD|MUST NOT break ADSP domain messages.
or
Forwarders SHOULD|MUST take into account ADSP Domains
before stripping and resigning or signing ADSP domain
On Monday 19 October 2009 02:54:47 Barry Leiba wrote:
Coming back to this: I've still seen very little direct input on the
charter proposal. JD likes it. Dave made some specific comments,
which I responded to; there've been no other comments on what Dave's
said. There've been no other
On Mon, 05 Oct 2009 14:37:56 +0100, MH Michael Hammer (5304)
mham...@ag.com wrote:
In light of the comments by Bill Oxley and my belief that the ability of
a domain to designate signing by a specified 3rd party is useful, I'd
like to see this included in the update. I believe this would be
Scott Kitterman wrote:
If advancing DKIM/ADSP along the standards heirarchy is all that's on the
table, I think it should wait.
Effective rollout of DKIM in large hetrgenous organizations is complex and
takes time. I think it's better to pause for a while and give broad
operational
Thanks Dave,
Let's give it a day or two more to see if anyone else has
suggested changes then Barry I will think about folding
in your suggestions.
Cheers,
S.
Dave CROCKER wrote:
Barry Leiba wrote:
Description of Working Group:
The Internet mail protocols and infrastructure allow mail
Folks,
To make life a little easier for us all, (well, mainly Barry
and I:-), could you please keep this thread to discussion of
the proposed charter update.
And where you've thoughts on that, specific alternate
text would be appreciated.
Thanks,
Stephen.
PS: I see John L. has done the right
I'm going to reply to this point in both threads, so people who just
read the charter thread see it. Please continue any discussion of it
over in the gathering data thread.
On Wed, Sep 30, 2009 at 2:01 PM, Franck Martin fra...@genius.com wrote:
Seems to me something is missing: gather data to
applies those signatures. Taken together, these will assist
receiving domains in detecting (or ruling out) certain forms of
spoofing as it pertains to the signing domain.
I suggest replacing the last sentence with something more generic, to avoid
the
debate about how much any of this
: Re: [ietf-dkim] DKIM charter update proposal
Folks,
To make life a little easier for us all, (well, mainly Barry
and I:-), could you please keep this thread to discussion of
the proposed charter update.
And where you've thoughts on that, specific alternate
text would be appreciated
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Barry Leiba
Sent: Monday, October 05, 2009 6:56 AM
To: Franck Martin
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] DKIM charter update proposal
DKIM might or might not get
Stephen Farrell wrote:
Scott Kitterman wrote:
If advancing DKIM/ADSP along the standards heirarchy is all that's on the
table, I think it should wait.
Effective rollout of DKIM in large hetrgenous organizations is complex and
takes time. I think it's better to pause for a while and
Steve Atkins wrote:
A more interesting question is how domain based authentication helps
domain reputation based systems reduce false positives in spam
filters, or how domain based feedback loops help ISPs and mailers
avoid sending unwanted email. DKIM itself doesn't do either of those,
it's
Franck Martin wrote:
I do not see where is the issue? I 3rd party sign emails and I have not
faced any problems with that (Am I missing something?) The providers
that check DKIM all include a dkim=pass in the mail headers.
Franck,
Thats because receivers have yet to support and honor
Franck,
Let me clarify that if your system was checking the ADSP record and
skipping or avoid 3rd party signing of domains with
DKIM=DISCARD|ALL, then IMO, your system would be protocol consistent
and behaving correctly.
Blind resigning could cause problems, such as:
1) Receivers rejecting
On Oct 2, 2009, at 7:56 PM, bill.ox...@cox.com bill.ox...@cox.com
wrote:
while I have enjoyed participasting in this WG I would like to
discuss the ability of an ISP to sign on behalf of an entity that we
provide all services for.
You can do that today, in several ways.
This has
On Oct 3, 2009, at 2:02 PM, bill.ox...@cox.com bill.ox...@cox.com
wrote:
I would like cox.comhttp://cox.com/ to sign on behalf of a
customer a.comhttp://a.com/ to z.comhttp://z.com/ so
a checker would lookup a.comhttp://a.com/ and see that the
cox.comhttp://cox.com/
is the
On Oct 3, 2009, at 2:02 PM, Bill Oxley wrote:
I would like cox.com to sign on behalf of a
customer a.com to z.com so a checker would lookup
a.com and see that the cox.com is the authorized
signer on behalf of z.com
Steve Atkins responded:
If a receiver receives an email with a
I would like cox.comhttp://cox.com/ to sign on behalf of a customer
a.comhttp://a.com/ to z.comhttp://z.com/ so
a checker would lookup a.comhttp://a.com/ and see that the
cox.comhttp://cox.com/ is the
authorized signer on behalf of z.comhttp://z.com/
On Oct 3, 2009, at 12:16 PM, Steve Atkins
Eliot Lear wrote:
Hi Murray,
On 10/1/09 10:27 PM, Murray S. Kucherawy wrote:
How can one forget that which was never true to begin with?
The working group and its antecedents, as far as I'm aware, have always been
pretty adamant about the fact that reducing spam has never been one of
Franck Martin wrote:
Seems to me something is missing: gather data to establish if DKIM
specifications have in any way alleviated any misuse of the email system, in
particular but not limited to spam, phishing attacks and fraud.
What would that prove, or disprove?
--
J.D. Falk
Return Path
Subject: Re: [ietf-dkim] DKIM charter update proposal
Franck Martin wrote:
Seems to me something is missing: gather data to establish if DKIM
specifications have in any way alleviated any misuse of the email system, in
particular but not limited to spam, phishing attacks and fraud.
What would
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Franck Martin
Sent: Thursday, October 01, 2009 12:56 PM
To: J.D. Falk
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] DKIM charter update proposal
Is the goal of a spec
On Oct 1, 2009, at 12:56 PM, Franck Martin wrote:
Is the goal of a spec, the writing of the spec itself, or to tackle
a higher goal?
Are we forgetting the original objectives of DKIM, which was to
reduce spam?
That wasn't a goal for DKIM. Rather the goal of DKIM was to provide
- Steve Atkins st...@wordtothewise.com wrote:
On Oct 1, 2009, at 12:56 PM, Franck Martin wrote:
Is the goal of a spec, the writing of the spec itself, or to tackle
a higher goal?
Are we forgetting the original objectives of DKIM, which was to
reduce spam?
That wasn't a
Barry Leiba wrote:
Please comment on it. If you like it, please say so.
I like it.
--
J.D. Falk
Return Path Inc
http://www.returnpath.net/
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
If advancing DKIM/ADSP along the standards heirarchy is all that's on the
table, I think it should wait.
Effective rollout of DKIM in large hetrgenous organizations is complex and
takes time. I think it's better to pause for a while and give broad
operational experience more of a chance to
To: IETF DKIM WG ietf-dkim@mipassoc.org
Sent: Thursday, 1 October, 2009 4:00:55 AM GMT +12:00 Fiji
Subject: [ietf-dkim] DKIM charter update proposal
Pasted below is my proposal for an updated DKIM WG charter. Stephen
has reviewed it and agrees, and now it's the working group's turn.
I've kept two
Barry Leiba wrote:
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 reasons for doing this, it has become a
source of general confusion, as well as a
In [EMAIL PROTECTED] Jim Schaad [EMAIL PROTECTED] writes:
Additionally it will include the impact
of receiving domains that are not using DKIM ( what is an example attack
or problem).
I can think of several examples of where a *receiver* who
I propose striking the entire paragraph.
And I propose ignoring that proposal. Can we move on now?
--
Arvel
___
ietf-dkim mailing list
http://dkim.org
Stephen,
-Original Message-
From: Stephen Farrell [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 17, 2005 2:36 AM
To: Jim Schaad
Cc: 'Barry Leiba'; 'IETF DKIM WG'
Subject: Re: [ietf-dkim] DKIM Charter Comments
Hi Jim,
Jim Schaad wrote:
I have the following comments
Doug,
I've read your mail twice now and I honestly cannot see
what's there that really needs to be addressed in terms
of potential changes to the charter.
Meanwhile, and for the n-th time: the whole of SSP is
in-play for the wg to address - and its been
explicitly acknowledged that the wg
Dave Crocker [EMAIL PROTECTED] writes:
Eric,
communities
very often want things to remain unchanged when they bring them
to IETF. I'm saying that it's not appropriate to nail that down
in the charter.
...
So the issue does not warrant marginalization as merely being due to
the
Eric Rescorla wrote:
I guess your concern is how high the bar is to change. Does the
charter make it too high or practically impossible, in your view? If
so, what changes do you suggest that alleviate those concerns?
I propose striking the entire paragraph.
Suppose that we did. What would
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 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
charter [1].
The charter still offers
In [EMAIL PROTECTED] [EMAIL PROTECTED] writes:
Even if deployed I would be looking at a way to get it out of
my network.
Why?
If you look at new installs of SPF it is stalled since
Microsoft announced.
I *have* looked, and I see no such stall in new SPF records?
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
I have the following comments on the draft charter:
1. The second paragraph has the sentence:
The DKIM working group will also produce security requirements to guide
their efforts, and will analyze the impact on senders and receivers who are
not using DKIM, particularly any cases in which mail
Barry Leiba wrote:
The parenthetical seems to be a bit misplaced, and might fit better
to the use of the word legitimate. This might read more easily if
broken into two sentences.
Actually, the content and placement of the parenthetical is due to an
attempt to correct a misunderstanding
wayne wrote:
Why the three months between the SSP I-D and the DNS recourse record?
Can't we just use a TXT RR clone the way SPF did?
The main reason is so that we don't have to b64 encode the public
key. Beyond that, it may well be just a drop in TXT clone of the
rest.
Mike
On Nov 14, 2005, at 5:24 PM, Dave Crocker wrote:
It would seem consensus may have been reach by those convinced
that since many abusive messages spoof the email-address, limiting
the use of an email-address therefore prevents abusive messages.
3. If you aren't, then how is your lengthy
PROTECTED]
To: [EMAIL PROTECTED]
Cc: IETF DKIM pre-WG ietf-dkim@mipassoc.org
Sent: Tuesday, November 15, 2005 1:32 PM
Subject: Re: [ietf-dkim] DKIM charter
On Nov 14, 2005, at 5:24 PM, Dave Crocker wrote:
It would seem consensus may have been reach by those convinced
that since many abusive
Santos
Sent: Tuesday, November 15, 2005 3:02 PM
To: Douglas Otis; [EMAIL PROTECTED]
Cc: IETF DKIM pre-WG
Subject: Re: [ietf-dkim] DKIM charter
Doug, I have no doubt you believe in all this and there are many valid
points. But I think it is over blown and I don't wish to get into my
opinions
the use of email-addresses. The
charter should take a long view and be sensitive to disruptions
created by email-address constraints, rather than offering
justifications. Never should these
Doug,
1. The charter does not constrain email addresses.
2. Dkim does not create or specify any
Dave Crocker wrote:
5. At some point, the question becomes one of worrying about
the DOS potential of your constantly posting lengthy notes
that regurgitate the same points that continue to fail to
gain support.
But, of course, that is just my own perspective.
(No Dave, I'm fairly
On Nov 15, 2005, at 2:55 PM, Stephen Farrell wrote:
Dave Crocker wrote:
5. At some point, the question becomes one of worrying about
the DOS potential of your constantly posting lengthy notes
that regurgitate the same points that continue to fail to
gain support.
I have a tendency to
Barry Leiba [EMAIL PROTECTED] writes:
Since experimentation resulted in significant Internet deployment of these
specifications, the DKIM working group will make every reasonable attempt to
keep changes compatible with what is deployed, making incompatible changes
only when they are necessary
I'm generally comfortable with this charter, but not really with this.
necessary for the success of the specifications seems like a very
high bar to clear. While I appreciate that there's a desire by many members
of the WG to avoid making incompatible changes (hence this language),
to the
Dave Crocker [EMAIL PROTECTED] writes:
I'm generally comfortable with this charter, but not really with this.
necessary for the success of the specifications seems like a very
high bar to clear. While I appreciate that there's a desire by many members
of the WG to avoid making incompatible
Eric,
Yes, I appreciate that it's intentional. And indeed, communities
very often want things to remain unchanged when they bring them
to IETF. I'm saying that it's not appropriate to nail that down
in the charter.
I'm sorry. I think you missed my point about the consensus on the charter
Eric,
communities
very often want things to remain unchanged when they bring them
to IETF. I'm saying that it's not appropriate to nail that down
in the charter.
...
So the issue does not warrant marginalization as merely being due to
the original constituency.
I heard objections to
Eric, a couple of incompatible changes have already been identified that
have been deemed to be necessary for the success of the
specifications. So the barrier has already been broken. While your
concerns are valid in theory, I don't think they will be a problem in
practice.
Tony Hansen
On Tue, Nov 15, 2005 at 06:10:36PM -0800, Eric Rescorla allegedly wrote:
Barry Leiba [EMAIL PROTECTED] writes:
Since experimentation resulted in significant Internet deployment of these
specifications, the DKIM working group will make every reasonable attempt to
keep changes compatible with
On Wed, Nov 16, 2005 at 01:20:33AM -0500, Tony Hansen allegedly wrote:
Eric, a couple of incompatible changes have already been identified that
have been deemed to be necessary for the success of the
specifications. So the barrier has already been broken. While your
concerns are valid in
Hi Eric,
Mark Delany wrote:
On Tue, Nov 15, 2005 at 06:10:36PM -0800, Eric Rescorla allegedly wrote:
Barry Leiba [EMAIL PROTECTED] writes:
Since experimentation resulted in significant Internet deployment of these
specifications, the DKIM working group will make every reasonable attempt to
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
Barry,
This is very good, and entirely acceptable IMO. I have a few
suggestions for what they're worth; take them or leave them as you please.
Barry Leiba wrote:
-
DRAFT IETF WORKING GROUP CHARTER
8 Nov 2005
Domain Keys
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
reasons for doing this, it has become a source of
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
At this stage of the game, with substantial consensus on the current
wording, I think we should be making only small, surgical changes than
complete changes in wording.
The ability for the message to be signed by a different domain is
covered by the wording in the first paragraph, ...that
On Nov 14, 2005, at 4:04 PM, Jim Fenton wrote:
At this stage of the game, with substantial consensus on the
current wording, I think we should be making only small, surgical
changes than complete changes in wording.
It would seem consensus may have been reach by those convinced that
Doug,
It would seem consensus may have been reach by those convinced that
since many abusive messages spoof the email-address, limiting the use of
an email-address therefore prevents abusive messages.
1. Are you attempting to declare the existing consensus invalid?
2. If you are, what
The parenthetical seems to be a bit misplaced, and might fit better to
the use of the word legitimate. This might read more easily if broken
into two sentences.
Actually, the content and placement of the parenthetical is due to an
attempt to correct a misunderstanding followed by awkwardness,
Thank you. I looked at the text here, and there are only two places
where we say policy, and I can't see a good way to turn either of
those directly into declaration without changing what they mean.
The first says, and to publish 'policy' information about how it
applies those signatures. I
1 - 100 of 110 matches
Mail list logo
