[ietf-dkim] What's a replay?

Forgive me my ignorance, but I don't understand what's meant by a replay. There are three things that I think of as a replay. None of them are affected by features like "user-level" keying. Furthermore, none of them are to me distinguishable from a forwarder (like .forward). So, obviously, I

Re: [ietf-dkim] DKIM Threat Assessment v0.02 (very rough draft)

On 9 Aug 2005, at 5:23 PM, Eric Allman wrote: I'm not sure that we aren't in agreement here. But I'm also not sure that we are. To toss my commentary in, I think we're within epsilon of agreement, for many epsilon. I find it helpful when I think of this to look at both sides of the pro

Re: [ietf-dkim] DKIM Threat Analysis v0.06

On 11 Aug 2005, at 2:25 PM, william(at)elan.net wrote: On Wed, 10 Aug 2005, SM wrote: Isn't a "Joe Job" messages that state false authorship in order to damage the reputation of a domain? Please define "joe job" and explain why you think this can or can not be considered subset of or equ

Re: [ietf-dkim] Not exactly not a threat analysis

1. DKIM makes it easier to detect sender forgery. The three important kinds of forgery are: * Pretending to be someone with a good or neutral reputation to avoid recognition as someone with a bad reputation (spam) * Pretending to be someone with a good reputation to take advantage of that repu

Re: [ietf-dkim] OT: DK credits

On 19 Feb 2006, at 3:16 AM, Frank Ellermann wrote: Hi, I put the Wikipedia entry for "domainkeys" on my watchlist, and edited some details like moving a link to Dave's DKIM page to the first position in the "external links" section. Russ Nelson added Eric, John, and himself to the intro as the

Re: [ietf-dkim] Supporting alternate algorithms

On 20 Feb 2006, at 1:34 PM, Hallam-Baker, Phillip wrote: Actually I think it is very clear what we will be using in 5 years time, either what we are using today or the NSA suite B with the possible replacement of the hash algorithm. I think it will take longer than five years, but it's stil

Re: [ietf-dkim] agenda item on upgrading hash algorithms?

On 20 Feb 2006, at 7:44 PM, Tony Hansen wrote: I don't like being a guinea pig, but that's what it feels like with the discussions on how to go about upgrading algorithms. I don't think we know enough yet to even know how to begin. This is a problem that a variety of protocols are going to go

Re: [ietf-dkim] Supporting alternate algorithms

On 20 Feb 2006, at 3:09 PM, Daniel Dreymann wrote: I concur. Last week I used the opportunity of the RSA conference to conduct an informal survey with many of the world's best known cryptographers. They have no evidence that SHA-256 is more than marginally better than SHA-1. The consensus

Re: [ietf-dkim] agenda item on upgrading hash algorithms?

On 22 Feb 2006, at 11:48 AM, Hector Santos wrote: Jon, Is there any issue in regards to the idea of having a signer/validator capability logic? I think I agree with you, Hector. Presently, the mails are coming in faster than I can read and respond to them so some of my earlier writing ha

Re: [ietf-dkim] Suggested alternate algorithm specification language, for now

On 22 Feb 2006, at 10:20 AM, Tony Hansen wrote: I vote for Dave's language to be added to ietf-dkim-base. I concur, this is a great way to deal with the issue. Jon ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/i

Re: [ietf-dkim] agenda item on upgrading hash algorithms?

On 22 Feb 2006, at 1:03 PM, Douglas Otis wrote: On Feb 22, 2006, at 11:11 AM, Jon Callas wrote: The only question facing us is whether we jump straight to SHA-256 now, or allow both. Jumping is cryptographically wiser as it gets us off the weak hash. Allowing both is engineeringly wiser

Re: [ietf-dkim] agenda item on upgrading hash algorithms?

On 23 Feb 2006, at 1:54 PM, Hallam-Baker, Phillip wrote: We know that 4096 bit keys will not fit into a standard DNS record. But Phill, we don't *need* 4096 bit keys before 2009. A DKIM key isn't a CA root key. It signs a message to take responsibility for it. The semantic lifetime of a g

Re: [ietf-dkim] agenda item on upgrading hash algorithms?

On 25 Feb 2006, at 9:51 AM, Dave Crocker wrote: What I keep in mind is not so much what things look like today, but what they might look like 2-4 years from now, when Moore's law and many grad students have had a few more shots at us. What I am trying to keep in mind is specification la

Re: [ietf-dkim] Concentrate on the threats doc

On 14 Mar 2006, at 4:55 AM, Barry Leiba wrote: Hello? Is this microphone working? Testing... testing... Can you hear me? Repeating two things in particular: * If you have reviewed the threats doc and think it's ready, please say so explicitly. ...because: I particularly want to make sur

Re: [ietf-dkim] Straw poll on x=

So, if you care, please respond to this message, including the list, with one of: Get rid of "x=" ...or... Keep "x=" ...and no discussion. Keep "x=" ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.ht

Re: [ietf-dkim] Proposal: Do the semantics first, then straw poll

I'm somewhat similar to you, Phill, as I can equally support keeping or removing x=. I think that x= is basically a Good Thing. On the other hand, removing it wouldn't be so bad, either. I voted to keep in the straw poll primarily because it seems that we can't *just* remove it, we have to

Re: [ietf-dkim] Proposal: Do the semantics first, then straw poll

On 17 Apr 2006, at 1:39 PM, Douglas Otis wrote: On Apr 17, 2006, at 12:11 PM, Jon Callas wrote: x= is a good thing because many, many people will change their DKIM keys every time they change what mail server they're using. This key will have a years-long, if not decades-long life

Re: [ietf-dkim] Proposal: Do the semantics first, then straw poll

On 17 Apr 2006, at 2:58 PM, Paul Hoffman wrote: At 12:11 PM -0700 4/17/06, Jon Callas wrote: x= is a good thing because many, many people will change their DKIM keys every time they change what mail server they're using. This key will have a years-long, if not decades-long life. Usin

Re: [ietf-dkim] Attempted text for x=

On 19 Apr 2006, at 8:44 AM, Stephen Farrell wrote: Folks, We've decided to stick with the status quo and keep x= but we do seem to need some different text. I want to disagree with that. I don't believe we really considered just removing x=. When we had the straw poll, we were also talki

Re: [ietf-dkim] Attempted text for x=

On 19 Apr 2006, at 10:14 AM, Paul Hoffman wrote: What is the interoperability or harm-limiting purpose of verifiers checking x= values? If there is none, the sentence above needs to be a MAY. I don't want to torture people with my reasoning, but x= needs to be a MAY, but for possibly diff

Re: [ietf-dkim] "Best Before" vs. "expiration" date

On 24 Apr 2006, at 5:09 PM, Paul Hoffman wrote: Validating messages a priori does not do that. True, but does it hurt to do so? If a recipient validates a message that has "expired", what is the harm to the recipient? The advatage, of course, is that they are now sure where the message c

Re: [ietf-dkim] Notes from DKIM jabber meeting on 20 April 2006

On 21 Apr 2006, at 4:45 AM, Stephen Farrell wrote: Folks. I'd like to suggest we do this again in two weeks time in the same time slot. Any objections/thoughts? I have an objection and a thought. It's an ugly time for people on the left coast of the US who aren't morning people. Further

Re: [ietf-dkim] Relaxed body canonicalization

On 26 Jun 2006, at 11:41 AM, Michael Thomas wrote: I'd still like it left in and if it's unused or providing no value, to remove it at DS. I agree with Mike. There's plenty of time to drop it. If we get closer to DS and experience is showing we don't need it, it's easy to drop it. It i

Re: [ietf-dkim] Relaxed body canonicalization

On 27 Jun 2006, at 5:24 AM, Dave Crocker wrote: 1. Some people wouldn't see an important distinction between PS and DS since more-or-less everyone has to implement the PS and few features, once deployed, are totally deprecated. That might influence whether or not you think its useful to

Re: [ietf-dkim] The URL to my paper describing the DKIM policy options

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

Re: [ietf-dkim] The URL to my paper describing the DKIM policy options

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 mine), then it sucks to be me. That's the problem.

Re: [ietf-dkim] The URL to my paper describing the DKIM policy options

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 w

Re: [ietf-dkim] requirements

In short, it implies DKIM-BASE is based on a "Good Citizen" model where every "i is dotted" and every "t is crossed." But it lacks no security provisions for protecting against the most obvious of all DKIM failures - in this case as to relates the above statement - unauthorized signings.

Re: [ietf-dkim] The URL to my paper describing the DKIM policy options

On 28 Jul 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 domain.

Re: [ietf-dkim] The URL to my paper describing the DKIM policy options

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,

Re: [ietf-dkim] Lean vs. Fat 'requirements'

On 10 Aug 2006, at 6:55 AM, Dave Crocker wrote: Some of us believe, rather strongly, that this is a particularly important "bias" to the development of the requirements list. It occurs, to me, however, that it might not be clear whether there is working group consensus on it. I would be

Re: [ietf-dkim] Keys vs. Reputation

On 21 Aug 2006, at 10:48 PM, Douglas Otis wrote: When DKIM fails to offer a means to assure the validity of the 2822.From address, then an important goal has been missed. The use of a subdomain for signing removes an ability to indicate with the i= syntax that the 2822.From is assured to b

Re: [ietf-dkim] Keys vs. Reputation

Applying a signature and ensuring the 2822.From header can not be modified is not equal to having validated that the account sending the message represents the recipient of that 2822.From address or that this account's use of the 2822.From address is valid. Being included in the signatur

Re: [ietf-dkim] Keys vs. Reputation

Indeed the DKIM signature does not directly validate the 2822.From address. However there is a means for the signing domain to communicate an assurance of the 2822.From address through the use of the dkim-signature i= syntax. A similar assertion is equally plausible within the 2822.From p

Re: [ietf-dkim] Re: Delegating responsibility: a make vs. buy designdecision

On 24 Aug 2006, at 10:38 AM, Damon wrote: What do we do when there is no signature and no d= domain to work with? This is sort of hazy in my mind. You do anything you want to do. Perhaps more correctly, you do what you're doing now. If there's no signature, it's not a DKIM message.

[ietf-dkim] DKIM, privacy, and user authentication

There's something about DKIM that I think needs to be stated again, as it often gets lost. There is a potential problem that any sort of digital signature can become a tracking system. Email already has problems with not being as privacy-friendly as it should be in an ideal world. For examp

Re: [ietf-dkim] Re: Delegating responsibility: a make vs. buy designdecision

> What do we do when there is no signature and no d= domain to > work with? > This is sort of hazy in my mind. > You do anything you want to do. Perhaps more correctly, you do what you're doing now. If there's no signature, it's not a DKIM message. Jon Even if my policy states that it

Re: [ietf-dkim] Re: Delegating responsibility: a make vs. buy designdecision

On 24 Aug 2006, at 12:59 PM, Damon wrote: And I think after re-reading what you said.. that we are saying the same thing. So... I am just re-re-reiterating what Jon said. Color me red. No need to be red. These things are easy to get slightly confused on -- cf my confusion in another thre

Re: [ietf-dkim] DKIM, privacy, and user authentication

On 24 Aug 2006, at 3:12 PM, Dave Crocker wrote: Jon, et al, Not to distract from the primary points you are making -- and which I both agree with and am happy to see documented -- I think it worth clarification a particular issue. I am pretty sure it is actually what you meant: Thank y

Re: [ietf-dkim] user level ssp

On 6 Sep 2006, at 10:14 AM, Michael Thomas wrote: All of this talk about additional requirements for user level ssp ignores the basic question: should there be any requirements for user level SSP at all? If so, what are the use cases? I'm not terribly convinced that even that has consens

Re: [ietf-dkim] Using mailing list to work through open issues

On 5 Oct 2006, at 10:14 AM, Dave Crocker wrote: Folks, Although it's great fun to schedule a time for everyone to use jabber together, there is nothing preventing our conducting exactly the same style of process over email. I know that might sound revolutionary, but it used to work prett

Re: [ietf-dkim] Introducing myself

On 30 Oct 2006, at 1:42 PM, Charles Lindsey wrote: I'm going to cherry-pick a few things, particularly the ones I think I'm best suited to answer. 3.2 Tag=Value Lists INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" defined below (as "tag-value") only includes 7-b

Re: [ietf-dkim] New IANA considerations: standards track or just RFC?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 19, 2007, at 1:39 PM, Paul Hoffman wrote: > Maybe we want "RFC only", not "standards track only", particularly > so that people can create Experimental RFCs and have them be used > in an interoperable fashion as a way of determining whether

Re: [ietf-dkim] New IANA considerations: standards track or just RFC?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 23, 2007, at 4:21 PM, Jim Fenton wrote: > I generally agree with "RFC only", but haven't thought about all > eight of the registries that -base asks to have created. It's not > clear that we want to do this with all of them. For example,

Re: [ietf-dkim] ISSUE: tag l=2 and dealing with leading blank lines for SIMPLE c14n.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A quick note to add on to some things others have said. DKIM has features that are useful in some places but not in others. One of those is l=. It seems to me that some people think that DKIM is going to be used uniformly throughout an email syst

Re: [ietf-dkim] ISSUE: tag l=2 and dealing with leading blank linesfor SIMPLE c14n.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > > Bad actors will find signatures surviving as a result of the 'l=n' > parameter, can then add their malware which might be a very innocent > looking URI pointing to some provider's AUP. This message can then be > sent in bulk anywhere. The innocen

Re: [ietf-dkim] Deployment Scenario 7: Cryptographic Upgrade and Downgrade Attacks

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 23, 2007, at 12:09 PM, Dave Crocker wrote: > > Color me confused. I thought we agreed long ago that downgrade > attacks were not an issue for the problem DKIM addresses. > We did. Downgrade attacks are not an issue for the problem DKIM ad

Re: [ietf-dkim] Deployment Scenario 7: Cryptographic Upgrade and Downgrade Attacks

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 25, 2007, at 10:46 AM, Michael Thomas wrote: > I just don't get this: if hash B is broken, isn't the right thing to > do is just kill off any selectors with hash B? Why do I need > policy when simply invalidating the selector would work even >

Re: 1368 straw-poll : (was: Re: [ietf-dkim] Deployment Non-Scenario 7: Cryptographic Upgrade and Downgrade Attacks)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 26, 2007, at 3:30 AM, Stephen Farrell wrote: > > It seems to me that the exchange between John and Charles > below captures the crux of the issue. > > Option 1: If we agree with Charles (& Phill I guess) that > looking up SSP and then passing

Re: [ietf-dkim] Issue 1365: drop "never send mail"?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 27, 2007, at 2:28 PM, Hallam-Baker, Phillip wrote: > I thought we would be dropping this as out of scope, not redundant. > > What mechanism is there for 'never send mail today'? > You can say that you never send mail from a domain with SPF.

Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a huge fear that I am beating a dead horse down a rathole. I also fear that I no longer understand what's being discussed. However, I want to make a cryptographic observation. If you create a suitably-sized RSA key, throw away the private k

Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 6, 2007, at 2:55 PM, Steve Atkins wrote: > > Yup. I think everyone (mostly) understands this. The entertainment > arrives when you want to be able to have a single policy record > refer to a large number of subdomains via wildcard. I get the

Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 7, 2007, at 8:09 AM, Damon wrote: >> No, this doesn't change the semantics of DKIM-BASE. The DKIM-Base >> "ignore failures" philosophy is basically "an invalid signature is >> exactly the same as no signature at all: no better and no >> wo

Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 7, 2007, at 6:06 AM, Hector Santos wrote: > Jim Fenton wrote: > >> Jon Callas wrote: > >> >>> In short -- saying "I sign everything" with a non-existent or >>> bogus key is the same thing

Re: [ietf-dkim] Jim's issues - one more try

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > (1) Use of XPTR records for SSP. The idea here is to create a more > general policy mechanism that can be used by WS-* and such. There > were about 20 messages discussing this from 5 people. I'm not > reading a clear consensus on this. > >

Re: [ietf-dkim] The (really) latest SSP draft

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > So if he said i=subdomain.example.com, then surely the From/Sender > can be expected to be from that subdomain; and if he said > [EMAIL PROTECTED], then surely recipients can assume that > 'someone' had indeed played some part in sending it. >

Re: [ietf-dkim] Responsibility vs. Validity

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have to strongly disagree with many of the things said here. I am one of the original authors and designers, and while I don't speak for the other authors and designers, I believe that I can reasonably authoritatively say something about DKIM's

Re: [ietf-dkim] Responsibility vs. Validity

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The thing I find most disturbing is that I perceive an effort to turn DKIM into a user-level signing system. This is not the intent of DKIM. DKIM has never outright forbidden this -- heck, what consenting senders do in the privacy of their own dom

Re: [ietf-dkim] Responsibility vs. Validity

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > > If the i= tag does not "mean something", and the verifier cannot > make use > of it for any purpose, then what on earth is the point of having it > in the > standard in the first place? > It is there for the signer to relate the message back i

Re: [ietf-dkim] Tracing SSP's paradigm change

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It's been hard over the last few days to keep pace with all of the messages here, so my comments are on the basic notion that Dave had brought up. I agree wholeheartedly with his basic premise, that SSP started off being modest, and has grown in

Re: [ietf-dkim] Processing SSP issues in January using jabber/concalls....

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 11, 2007, at 9:36 AM, Michael Thomas wrote: > Stephen Farrell wrote: >> Dave Crocker wrote: >>> Stephen Farrell wrote: Only place we're a bit off is the 30 day notice period. If we want to be strict about that then I guess we can >>>

Re: [ietf-dkim] Re: NEW ISSUE: Simplify SSP decision tree

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 10, 2007, at 11:30 AM, Michael Thomas wrote: > Frank Ellermann wrote: >> Michael Thomas wrote: >> >> >>> Part of the problem is that "softfail" and "hardfail" don't make >>> much intuitive sense. >>> >> >> For SPF (and Sender ID) a SOFTFAIL is

Re: [ietf-dkim] Re: NEW ISSUE: replace use of term "suspicious"

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 9, 2007, at 11:26 PM, Frank Ellermann wrote: > Dave Crocker wrote: > >> With the use of language like "suspicious", SSP is making value >> judgement on messages that do not satisfy SSP's criteria, even >> though those message well might be ent

Re: [ietf-dkim] Re: Issue #1512: Re: making SSP useless in one short step

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 11, 2007, at 11:52 AM, John L wrote: >> SPP bankofamerica.com p=strict >> >> From: [EMAIL PROTECTED] >> DKIM-Signature: [EMAIL PROTECTED] >> DKIM-Signature: [EMAIL PROTECTED] >> Subject: Get a great rate today! >> >> >> >> You'd accept the me

Re: [ietf-dkim] NEW ISSUE: Signature semantics

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 9, 2007, at 9:23 AM, Dave Crocker wrote: > > >> 6. Signature Semantics >> DKIM was devised to provide a means of declaring an >> (organization's) identity >> that is taking "responsibility" for placing a message into the >> transit stream.

Re: [ietf-dkim] NEW ISSUE: Limit the application of SSP to unsigned messages

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 9, 2007, at 5:03 PM, Arvel Hathcock wrote: > The purpose of SSP is to detect unauthorized domain use. I disagree on this. The purpose of SSP is for the sender to give the receiver a hint as to what to do with messages that have broken sig

Re: [ietf-dkim] NEW ISSUE: Signature semantics

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 11, 2007, at 7:23 PM, John Levine wrote: >> The issue is mandatory end-user identification with i=. > > To make it more concrete, can we take this as a proposal to > change section 2.8 to remove references to the local-part? > > Yes, thank yo

Re: [ietf-dkim] NEW ISSUE: Discussion of query traffic overhead

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > > The comment you quote expresses rather a different concern: that the > additional traffic associated with lookup of messages with a valid > signature which is not an Originator Signature will be excessively > burdensome. Can you explain what will

Re: [ietf-dkim] Re: Issue 1530 - replace use of term "suspicious"

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 19, 2007, at 2:16 AM, Charles Lindsey wrote: > On Wed, 19 Dec 2007 06:27:55 -, Eliot Lear <[EMAIL PROTECTED]> wrote: > >> Bingo. We are wasting time on what I think is an extraordinary >> superficial issue. Jim's original term "Suspiciou

Re: [ietf-dkim] SHA256 not supported on Windows XP/2000/NT

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > > Microsoft SHOULD seriously consider, at the very least, provide > CALG_SHA_256 hashing support for the default CSP (Microsoft Base > Cryptographic Provider) on the widely adopted Windows XP operating > system. You're right, but if it were me

Re: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by first Author breaks email semantics

-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

Re: [ietf-dkim] No teleconference

-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

Re: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by first Author breaks email semantics

-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

Re: [ietf-dkim] ISSUE 1525 -- Clarification about posting by first Author

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > > 2) write a security consideration mentioning the reflection attack, > and > the likely mitigation that filtering software should view this as > out of the ordinary This is the way I think we should handle it. Charles Lindsey noted that mult

Re: [ietf-dkim] Seriously.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > > > 1. Perform SSP checks on the domains of all From addresses in the > message, with the exception of addresses having valid Author > Signatures. If any of the checks result in a Non-Compliant > (formerly Suspicious) result, then the message

Re: [ietf-dkim] Seriously.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > > > I'm expecting that non-DKIM software will "squint at the message" > anyway. SSP is an input to that process. By "Throw your hands up > in the air," I gather you mean, "the result of the SSP check is > indeterminate," and yes, that is an o

Re: [ietf-dkim] Re: Seriously.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 23, 2008, at 11:27 AM, Frank Ellermann wrote: > Jon Callas wrote: > >> E.g. the syntax @ is legal. > > Not under RFC 2821 rules intentionally demanding > "at least one dot" - to get rid of @ > constructs,

Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt and ASP

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 1, 2008, at 5:32 PM, J D Falk wrote: > Wietse Venema wrote: > >> In my opinion, as one of the authors listed on the ASP draft, SSP-02 > is >> close enough in spirit to ASP that I could live with either. > > As another author, +1. Same here. I

Re: [ietf-dkim] DKIM slashdotted

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Section 3.2.2 says that OpenPGP modifies the body > of an email. Is that still necessarily the case ? I'm not sure I know what that means. Jon -BEGIN PGP SIGNATURE- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFHsOL1sTe

Re: [ietf-dkim] Re: ISSUE 1547: SSP-02: MX Record publishing mandate to reduce DNS overhead for SSP Discovery and to detect fraudulent messages

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd like to add a big -1 to mandating publishing MX, conflating DKIM and SMTP and so on. Jon -BEGIN PGP SIGNATURE- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFHs1BPsTedWZOD3gYRAsftAKC6GbS3EfXP+8j1dKpe2o8uSwGYsACgjEfs SE8m

Re: [ietf-dkim] Issue 1550 - the name of the document (remains open *briefly*); there's still,disagreement on "Author"

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 11, 2008, at 5:47 PM, MH Michael Hammer (5304) wrote: > > After reading Wietse's comment I'm wondering if (taking the long view) > we should consider calling it Administrative Domain Signing Policy. > +2^n-1. While I'm at it, I also like Fro

Re: [ietf-dkim] Practices protocol naming poll (Closing issue 1550)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [*] ADSP - Administrative Domain Signing Practices (**) [ ] ADSP - Author Domain Signing Practices [ ] ASP - Author Signing Practices [*] FroDo - From Domain Signing Practices [ ] SPAD - Signing Practices of Author Domains [ ] SSP - Sender Signing Pr

Re: [ietf-dkim] subdomain strawpoll

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 delete -BEGIN PGP SIGNATURE- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFIGo6msTedWZOD3gYRApXWAJ4j6AiG8Z3u61RPL2aI2Q8jobtjDQCgurA3 jonh0UTH4TS257JMJ2pKDCU= =nTJU -END PGP SIGNATURE- _

Re: [ietf-dkim] Consensus check: Domain Existence Check

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > > > b. Modify, i.e. keep, but with a different set of records. It was > suggested that the current NXDOMAIN is incorrect, and that MX, A, and > records for the domain should be queried, with the existence of > any of these records indicating a

Re: [ietf-dkim] Not an issue: multiple From headers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > My theory is that DKIM only applies to valid 2822 messages, and it's > not a substitute for a sanity check for all the screwy things one > can send in a non-conformant message. Perhaps it would be a good > idea someday to > collect experience

Re: [ietf-dkim] Progressing ADSP (Was: Re: New Version Notification for draft-ietf-dkim-ssp-06 (fwd))

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > It might be no harm if folks who do think ADSP should > go ahead would respond to this saying so. I +1 Jon -BEGIN PGP SIGNATURE- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFI2HIasTedWZOD3gYRAn4ZAKC4GG6eIkYfDOOg2oDWHWdnC

Re: [ietf-dkim] First cut on certificate extensions draft

ing DNS signaling as a means of driving deployment of S/MIME and PGP for encryption. I don't think that DKIM+OpenPGP buys you anything that you do not get with either DKIM or OpenPGP by itself - otherwise I am sure Jon Callas (ccd) would have proposed it. But being able to use th

Re: [ietf-dkim] DKIM does not claim content is correct

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> > > With DKIM i=, it becomes possible to convey a stable identifier > (though of > course there's no guarantee that the identifier is stable, leading > to John's > t= suggestion.) Without DKIM (or something like it), as we know, any > potential

Re: [ietf-dkim] RFC4871bis

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> > > Colo(u)r me dumb/confused/take-your-pick, but is i= effectively the > moral equivalent of IDENT (RFC1413)? Yes. Jon -BEGIN PGP SIGNATURE- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFJghG4sTedWZOD3gYRAiHzAKCXCTEzn0

Re: [ietf-dkim] draft Errata on RFC 4871

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 29, 2009, at 6:14 AM, pasi.ero...@nokia.com wrote: > > While considering this, I tried to find exactly such documentation, > but I did not find much. > > draft-rfc-editor-errata-process-02 has the following text: > > We note that allowing te

Re: [ietf-dkim] summarizing my understanding of the errata discussion & a proposal

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > > Statements that imply the i= value is always OPAQUE prevents its > utilization for highlighting purposes with respect to identity > assurances, even when there is an exact match and this value could be > said to not be opaque. This also seems to co

Re: [ietf-dkim] New version - draft-ietf-dkim-rfc4871-errata-01

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> > > There is a difference between being able to use the d= signing > domain versus > having deep knowledge about the underlying intent behind encoding > choices for it. > > You know my name is David. You do not know why my parents chose > tha

Re: [ietf-dkim] Status and direction

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Barry, I think that we're dealing with a false dichotomy between a straw man and beating a dead horse with a red herring. 4871 is in my opinion as an author clear about i=. You have but to read it and the informative notes. One might think it's a

Re: [ietf-dkim] Status and direction

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 13, 2009, at 9:47 PM, DKIM Chair wrote: > Jon says... >> 4871 is in my opinion as an author clear about i=. You have but to >> read it and >> the informative notes. One might think it's amorphous, but it's at >> least an >> explicit amorph

Re: [ietf-dkim] Consensus call on d=/i= clarification

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (a) The erratum I-D [1] is ready to go. Process it. +1 Jon -BEGIN PGP SIGNATURE- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFJmni/sTedWZOD3gYRArmUAKDkfWhOePM/9vfmEBhwgEx99ugLcACeK5mB CtNpHnXJL1A9S7fbOk2wC/U= =OZPd -EN

Re: [ietf-dkim] [Fwd: New Version Notification for draft-fenton-dkim-reputation-hint-00]

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > But i= isn't opaque, not as a whole anyway. It has the syntax of an > email address, and the domain part of that address MUST be the same > as or a subdomain of the d= value. > I think I want to say just a few things about "opaque" as a term o

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 30, 2009, at 10:15 AM, Dave CROCKER wrote: >> k: Key type >> >> Much the same as h=, with the added issue that there's only one >> possible key type right now, and if there were a need for k= in the >> future it could be added in the same R

Re: [ietf-dkim] RFC4871bis - whether to drop -- h: Acceptable hash algorithms

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 30, 2009, at 10:15 AM, Dave CROCKER wrote: > Folks, > > > In: > > > > Steve Atkins posted a list of suggested DKIM features to drop. > > This note is intended to anchor a discussio

Re: [ietf-dkim] RFC4871bis - whether to drop -- SHA1 support

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 30, 2009, at 10:17 AM, Dave CROCKER wrote: > Folks, > > > In: > > > > Steve Atkins posted a list of suggested DKIM features to drop. > > This note is intended to anchor a discussio

Re: [ietf-dkim] RFC4871bis - whether to drop -- x: Signature expiration

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 1, 2009, at 8:33 AM, Siegel, Ellen wrote: > > >>> DKIM-Signature Header tags >>> >>> x: Signature expiration >>> >>> Expiration is a fairly common feature in signing specifications. But >>> DK and DKIM are different in that the public ke

  1   2   >