I did a quick read of -overview yesterday and on the whole liked it.
It's a bit rough, lots of spelling/grammar errors, obviously written
by different people, needs sections filled in, etc., but it seemed
like it covered the critical areas. I'll try to read it in more
detail soon.
However, t
Tony, thanks for doing the leg work.
I can see us going three directions here:
(1) Drop the references to 2822 and define at least the terminals
ourselves to allow UTF-8 characters. This makes us "EAI aware" and
gives a warning to DKIM implementers to think about the future, but
does separat
Eric Allman <[EMAIL PROTECTED]> writes:
> I did a quick read of -overview yesterday and on the whole liked
> it. It's a bit rough, lots of spelling/grammar errors, obviously
> written by different people, needs sections filled in, etc., but it
> seemed like it covered the critical areas. I'll try
Bill Oxley
Messaging Engineer
Cox Communications, Inc.
Alpharetta GA
404-847-6397
[EMAIL PROTECTED]
Number 1 below is partially true. I can send mail that appears to be
from someone else that cannot be tracked back to the actual originating
IP but appears to be from elsewhere, this is what
In our testing at Cisco, we are seeing a small but
significant number of failure mainly due to various system
bots that send naked CR's in a message. What I have found
is that at the very least, sendmail and Ironport handle
these two cases differently. Thus for the input:
testing 1\n
\r
\r
2 3\r
There's a glitch in the ABNF for s=. It refers to both "subdomain" and
"sub-domain". Both should be "sub-domain".
In section 3.6.2.1, we could reserve the use of _* labels as used in
leaves off of _domainkey for extensions related to DKIM.
Tony Hansen
[EMAIL PROTECTED]
___
> I thought that the Overview document was supposed to be a non-normative
> introduction (ok, "overview") of DKIM: motivations, context, how the
> pieces fit together, how it fits into the bigger picture. If I'm right,
> then
>
> (1) using "plain English" is just fine, and hence "reputation" do
I submitted the draft in both pdf and txt. Only the txt is shown, the more
readable pdf is attached.
http://www.ietf.org/internet-drafts/draft-hallambaker-pcon-00.txt
Considerations for Development of DKIM Policy Language.pdf
Description: Considerations for Development of DKIM Policy Language.
Phillip,
I like what I am reading here. I plan to read it over more this weekend and
provide some feedback. Maybe its time that I submit my own SSP variant DSAP
proposal:
http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-01.xml
http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-01
I'm not sure that Dave Crocker and I are in full agreement, but it's
close enough
that it should make people worry. Even though I've been thinking about
SSP for
a long, long time (IIM had the same concepts), it's not entirely clear
to me that
we know what problems we're trying to solve or whet
--On July 12, 2006 2:08:12 PM -0400 Dave Crocker <[EMAIL PROTECTED]>
wrote:
I thought that the Overview document was supposed to be a
non-normative introduction (ok, "overview") of DKIM: motivations,
context, how the pieces fit together, how it fits into the bigger
picture. If I'm right, then
(
On Jul 12, 2006, at 3:18 PM, Michael Thomas wrote:
I'm not sure that Dave Crocker and I are in full agreement, but
it's close enough
that it should make people worry. Even though I've been thinking
about SSP for
a long, long time (IIM had the same concepts), it's not entirely
clear to me
DKIM met twice at IETF-66, on Tuesday for an hour and Wed. for
two hours.
The WG chairs had asked for help from the DNS directorate about
whether or not DKIM needs to define a new RR or is ok to use the
current approach of a TXT record for the public key. The feedback
is that although there's som
...attached. Comments to me/Barry in the next week or two please.
Thanks,
Stephen.
Title: No title
IETF-66 DRAFT DKIM Meeting Notes
Charter: http://www.ietf.org/html.charters/dkim-charter.html
Chairs: Barry Leiba, Stephen Farrell
We met twice. Thanks to the jabber scribes!
Tuesday: 67
On Wed, Jul 12, 2006 at 08:10:58PM -, [EMAIL PROTECTED] allegedly wrote:
>
> DKIM met twice at IETF-66, on Tuesday for an hour and Wed. for
> two hours.
> in this case it appears to work. So the WG approach for base will
> be to include the TXT record definition and not to define a new
> RR f
Eric Allman wrote:
> In the spirit of using plain English, I think "reputation" is better,
> because that's the term that the press is using and hence what people
> know. However I agree with EKR that we need to be clear about what we
> really mean here, since after all the press often misuses t
Douglas Otis wrote:
On Jul 12, 2006, at 3:18 PM, Michael Thomas wrote:
I'm not sure that Dave Crocker and I are in full agreement, but it's
close enough
that it should make people worry. Even though I've been thinking
about SSP for
a long, long time (IIM had the same concepts), it's not
A few comments on my action items:
1308 (language recommending use of t=s): In the description of the
t=s flag, I've added "Use of this flag is RECOMMENDED unless
subdomaining is required."
DNS discussion: There's a note from Olafur suggesting that the
document add "do not use wildcards." I
For the same reason From: has to be signed --- they represent the
[fill in blank with your favorite word: author, originator, whatever]
of the message. I suppose we can legitimately ask why From: MUST be
signed though. In terms of interoperability it is not required, but
in terms of being use
Eric Allman wrote:
> section 3.6.2, Resent-From, and Resent-Sender MUST also be
included.
Why MUST these be signed?
Mike
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Resent-* should only be added by MUAs when someone is re-submitting a
message back into the MHS. Essentially Resent-From subsumes the role
of From when a message is re-submitted (ditto for Resent-Sender and
Sender). It's not quite this simple, since an MUA replying to a
resent message should
Eric Allman wrote:
For the same reason From: has to be signed --- they represent the
[fill in blank with your favorite word: author, originator, whatever]
of the message. I suppose we can legitimately ask why From: MUST be
signed though. In terms of interoperability it is not required, but
Eric Allman wrote:
Resent-* should only be added by MUAs when someone is re-submitting a
message back into the MHS. Essentially Resent-From subsumes the role
of From when a message is re-submitted (ditto for Resent-Sender and
Sender). It's not quite this simple, since an MUA replying to a
r
Huh? You've got me completely confused. DKIM should /never/ add
Resent-* fields. I don't see how that is stated or implied. I can
see how you might think that it has to include them in h= even if
they didn't already exist, so I've added "if included" to the text.
Resent-* may seem "quaint"
The draft has /always/ said that these header fields are to be
signed. From -03:
any header field that describes the role of the signer (for
example, the Sender or Resent-From header field if the
signature is on behalf of the corresponding address and that
address is
Eric Allman wrote:
Huh? You've got me completely confused. DKIM should /never/ add
Resent-* fields. I don't see how that is stated or implied. I can
see how you might think that it has to include them in h= even if they
didn't already exist, so I've added "if included" to the text.
I me
Eric Allman wrote:
The draft has /always/ said that these header fields are to be
signed. From -03:
any header field that describes the role of the signer (for
example, the Sender or Resent-From header field if the
signature is on behalf of the corresponding address and t
On Wed, Jul 12, 2006 at 05:42:53PM -0700, Michael Thomas allegedly wrote:
> Eric Allman wrote:
>
> >The draft has /always/ said that these header fields are to be
> >signed. From -03:
> >
> > any header field that describes the role of the signer (for
> > example, the Sender or Resen
Resent-From: and Resent-Sender: would be signed only if present in the
header. It's perfectly legit for a forwarding system to add them (and
expected according to the specs), and if that forwarding server then
signs the message, those headers MUST be treated in the same category as
From: and Sender
On Jul 12, 2006, at 10:44 PM, Mark Delany wrote:
On Wed, Jul 12, 2006 at 05:42:53PM -0700, Michael Thomas allegedly
wrote:
Eric Allman wrote:
The draft has /always/ said that these header fields are to be
signed. From -03:
any header field that describes the role of the signer (for
> To my mind, the spec currently stands mid-way, it sort-of protects
> obvious headers but cannot possibly protect all, so my druthers is
> that we actually remove all compulsion as to which headers are signed
> as it may well look truly quaint in five years time when other
> important originator h
On Wed, 12 Jul 2006, Eric Allman wrote:
For the same reason From: has to be signed --- they represent the [fill in
blank with your favorite word: author, originator, whatever] of the message.
I suppose we can legitimately ask why From: MUST be signed though. In terms
of interoperability it i
On Wed, Jul 12, 2006 at 08:48:21PM -0700, william(at)elan.net allegedly wrote:
>
> On Wed, 12 Jul 2006, Eric Allman wrote:
>
> >For the same reason From: has to be signed --- they represent the [fill in
> >blank with your favorite word: author, originator, whatever] of the
> >message. I suppose
I interpret this text differently. If the signer uses a signing address
that matches (for example) Resent-From, and wishes the verifier to see
that its role is as a resender, then it must sign Resent-From. But
suppose someone resends a message to a mailing list, which itself
signs. The list isn'
william(at)elan.net wrote:
>
> On Wed, 12 Jul 2006, Eric Allman wrote:
>
>> For the same reason From: has to be signed --- they represent the
>> [fill in blank with your favorite word: author, originator, whatever]
>> of the message. I suppose we can legitimately ask why From: MUST be
>> signed tho
- Original Message -
From: "william(at)elan.net" <[EMAIL PROTECTED]>
> So if message has Resent-From field would SSP check be done against From
> or Resent-From or both?
The verification is already done before the Resent-From was added.
i.e., Resent-* should not be in original mail.
-
- Original Message -
From: "Jim Fenton" <[EMAIL PROTECTED]>
To: "william(at)elan.net" <[EMAIL PROTECTED]>
>> So if message has Resent-From field would SSP check be done
>> against From or Resent-From or both?
> From. Always From, unless there is a valid signature where the
> signing add
37 matches
Mail list logo
