[ietf-dkim] Re: Measurement Results on Deployment Ratio of Domain Authentications

Kazu Yamamoto wrote: > Just FYI. Thanks, also discussed in... Bye, Frank ___ ietf-dkim mailing list http://dkim.org

[ietf-dkim] Re: now up on roundup tracker

Eliot Lear wrote: > It's not perfect It throws an error when I try to look at it, apparently it thinks that UAs MUST send an Accept-Language header field - that's not the case with my UA. > you shouldn't hear from the tool I got an ACK for the one message with "Subject: New Issue". If that was

[ietf-dkim] Re: New Issue: Threat-00 Limiting the scope of trust

Douglas Otis quoted: > ,--- > | 1. Introduction > | ... > | Once the attesting party or parties have been established, the > | recipient may evaluate the message in the context of additional > | information such as locally-maintained whitelists, shared reputation > | services, and/or third-party

[ietf-dkim] Re: New Issue: 4.2 needs new Attack Item: InconsistentSignature vs Policy Attacks

Hector Santos wrote: > 80-84% of all SPF policies seen by SMTP receivers are NEUTRAL > (relaxed) policies. Among these, atleast 60%, are Bad Actors > exploiting a RELAXED domain policy. It's not possible to "exploit" NEUTRAL, as it's by definion the same as NONE. What's so unusual with 60% spam

Re: [ietf-dkim] Can vendor's really say they have DKIM support yet?

From: "Mark Delany" <[EMAIL PROTECTED]> > Also, from a "marketing" perspective, the question we used to get in > the early days of DK was "who else?". One expects the same with > DKIM. Pointing to players that are investing the effort and producing > product, albeit with the risk of change, stri

Re: [ietf-dkim] New Issue: 4.2 needs new Attack Item: Inconsistent Signature vs Policy Attacks

Stephen Farrell wrote: > > Hi Jim, All, > > Does the following make sense? > > In section 4.1 we include a couple of vulnerabilities where an > exploit would depend on the DNS being poisoned or otherwise > containing bad values (e.g. 4.1.12). > > Since we're also proposing to use the DNS to store p

Re: [ietf-dkim] Can vendor's really say they have DKIM support yet?

Mark Delany wrote: On Wed, Feb 01, 2006 at 08:37:37PM +, Stephen Farrell allegedly wrote: If you choose to write code based on an Internet-Draft you are taking a risk that the specification changes before it becomes a standard. It's probably not the intent, but this could be read as disc

Re: [ietf-dkim] Can vendor's really say they have DKIM support yet?

On Wed, Feb 01, 2006 at 08:37:37PM +, Stephen Farrell allegedly wrote: > If you choose to write code based on an Internet-Draft you are > taking a risk that the specification changes before it becomes > a standard. It's probably not the intent, but this could be read as discouraging such activ

Re: [ietf-dkim] Can vendor's really say they have DKIM support yet?

On Feb 1, 2006, at 1:47 PM, Michael Thomas wrote: Frankly, the IETF isn't the police so this is a pretty moot point. But if you're interested in truth-in-advertising, making explicit that you abide by -base and/or -ssp would at least give an interested person the tools to make a better in

Re: [ietf-dkim] Can vendor's really say they have DKIM support yet?

Dave Crocker wrote: or the response. So just implementing http://mipassoc.org/dkim/specs/draft-allman-dkim-base-00-10dc.txt without SSP is considered a valid DKIM implementation? > Thanks for the response. So just implementing > http://mipassoc.org/dkim/specs/draft-allman-dkim-base-00-10d

Re: [ietf-dkim] Can vendor's really say they have DKIM support yet?

- Original Message - From: "Stephen Farrell" <[EMAIL PROTECTED]> To: Sent: Wednesday, February 01, 2006 3:37 PM Subject: Re: [ietf-dkim] Can vendor's really say they have DKIM support yet? > If you choose to write code based on an Internet-Draft you are > taking a risk that the specifi

Re: [ietf-dkim] Can vendor's really say they have DKIM support yet?

Folks, Without a policy statement DKIM asserts that the sending MTA sent this particular signed message. Hence DKIM provides a stable, validated identifier that declares its "responsibility" for the message. Having such a validated identifier permits various reputation and accountability

Re: [ietf-dkim] Can vendor's really say they have DKIM support yet?

Dave Crocker wrote: or the response. So just implementing http://mipassoc.org/dkim/specs/draft-allman-dkim-base-00-10dc.txt without SSP is considered a valid DKIM implementation? > > Thanks for the response. So just implementing > http://mipassoc.org/dkim/specs/draft-allman-dkim-base-00-10

RE: [ietf-dkim] Can vendor's really say they have DKIM support yet?

Without a policy statement DKIM asserts that the sending MTA sent this particular signed message. That is a benefit of itself to clearly identify the sending party. A policy statement that is 1 I sometimes sign 2 I don't care who signs this 3 I always sign and don't want anyone else to sign Is in

Re: [ietf-dkim] Can vendor's really say they have DKIM support yet?

- Original Message - From: "Jeff Macdonald" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> > Dave, > Thanks for the response. So just implementing > http://mipassoc.org/dkim/specs/draft-allman-dkim-base-00-10dc.txt > without SSP is considered a valid DKIM implementation? For the list IETF r

Re: [ietf-dkim] Can vendor's really say they have DKIM support yet?

or the response. So just implementing http://mipassoc.org/dkim/specs/draft-allman-dkim-base-00-10dc.txt without SSP is considered a valid DKIM implementation? > Thanks for the response. So just implementing > http://mipassoc.org/dkim/specs/draft-allman-dkim-base-00-10dc.txt > without SSP is c

[ietf-dkim] touting the DKIM Supporters list

Folks, The list of organizations willing to be listed as supporting DKIM has grown considerably and interestingly. Take a look at . d/ -- Dave Crocker Brandenburg InternetWorking __

Re: [ietf-dkim] Can vendor's really say they have DKIM support yet?

On Wed, Feb 01, 2006 at 08:49:44AM -0800, Dave Crocker wrote: > > > Jeff Macdonald wrote: > >The standard isn't finalized yet, correct? So how can we have vendors > >say they have conforming implementations? > > > >I'm talking DKIM, not DK. > > The version of DKIM that was submitted to the IETF

[ietf-dkim] New Issue: Threat-00 Limiting the scope of trust

,--- | 1. Introduction | ... | Once the attesting party or parties have been established, the | recipient may evaluate the message in the context of additional | information such as locally-maintained whitelists, shared reputation | services, and/or third-party accreditation. The description of

Re: [ietf-dkim] now up on roundup tracker

I've configured a roundup server to help track issues. It's not perfect and the import has dates till now obviously wrong. You can get there by going to http://www.ofcourseimright.com/cgi-bin/roundup/ and clicking on "ietf-dkim". cool. i've added a link to it on the

Re: [ietf-dkim] Can vendor's really say they have DKIM support yet?

Jeff Macdonald wrote: The standard isn't finalized yet, correct? So how can we have vendors say they have conforming implementations? I'm talking DKIM, not DK. The version of DKIM that was submitted to the IETF was the result of an extensive, multi-vendor specification and development effor

[ietf-dkim] Can vendor's really say they have DKIM support yet?

The standard isn't finalized yet, correct? So how can we have vendors say they have conforming implementations? I'm talking DKIM, not DK. -- :: Jeff Macdonald | Principal Engineer, Messaging Technologies :: e-Dialog | [EMAIL PROTECTED] :: 131 Hartwell Ave. | Lexington, MA 02421 :: v: 781-372-19

Re: [ietf-dkim] New Issue: 4.2 needs new Attack Item: InconsistentSignature vs Policy Attacks

Stephen, When it is outlined this way, high potential and most probable to occur threats are minimized. If we want to learn from the past Atleast 80-84% of all SPF policies seen by SMTP receivers are NEUTRAL (relaxed) policies. Among these, atleast 60%, are Bad Actors exploiting a RELAXED d

[ietf-dkim] now up on roundup tracker

[this time from the right email address] Hi Everyone, I've configured a roundup server to help track issues. It's not perfect and the import has dates till now obviously wrong. You can get there by going to http://www.ofcourseimright.com/cgi-bin/roundup/ and clicking on "ietf-dkim". The defaul

Re: [ietf-dkim] Measurement Results on Deployment Ratio of Domain Authentications

Kazu Yamamoto (山本和彦) wrote: Hello, The following page contains how many domains under ".JP" have introduced DomainKeys/DKIM. http://member.wide.ad.jp/wg/antispam/stats/index.html.en Just FYI. --Kazu Yamamoto, IIJ That's excellent. Will be really interesting to (hopefully) watch