gmane.ietf.dkim

Re: [Technical Errata Reported] RFC6376 (3192)

Dave Crocker — 2012-04-16T15:15:07


On 4/16/2012 8:10 AM, RFC Editor wrote:


My guess is that the existing notation for communicating inline to the RFC
editor is sufficient.  That is, I'd expect the real issue being one of getting
us all to tell you what not to format, rather than one of creating a new notation.

d/

Re: [Technical Errata Reported] RFC6376 (3192)

Dave Crocker — 2012-04-14T22:32:13

raises a small question of needing notes to the editor advising hands off for such segments.


/d

--

Dave Crocker
bbiw.net



-----Original Message-----
From: Barry Leiba <barryleiba< at >computer.org>
To: Barry Leiba <barryleiba< at >computer.org>
Cc: RFC Errata System <rfc-editor< at >rfc-editor.org>, "dcrocker< at >bbiw.net" <dcrocker< at >bbiw.net>, "tony+dkimov< at >maillennium.att.com" <tony+dkimov< at >maillennium.att.com>, "msk< at >cloudmark.com" <msk< at >cloudmark.com>, "stephen.farrell< at >cs.tcd.ie" <stephen.farrell< at >cs.tcd.ie>, "turners< at >ieca.com" <turners< at >ieca.com>, "john.hawthorn< at >gmail.com" <john.hawthorn< at >gmail.com>, "ietf-dkim< at >mipassoc.org" <ietf-dkim< at >mipassoc.org>
Sent: Sat, 14 Apr 2012 3:30 PM
Subject: Re: [Technical Errata Reported] RFC6376 (3192)

FWIW, the error was introduced by the RFC Editor, who surely used
double-space-between-sentences style, and didn't know that in that
particular case, the space matters.  And we didn't notice it in AUTH48
reviews.  Something we need to remember to check for, in the rare cases
where it does mat

Re: [Technical Errata Reported] RFC6376 (3192)

Dave Crocker — 2012-04-14T22:26:27

+1


/d

--

Dave Crocker
bbiw.net



-----Original Message-----
From: Barry Leiba <barryleiba< at >computer.org>
To: RFC Errata System <rfc-editor< at >rfc-editor.org>
Cc: "dcrocker< at >bbiw.net" <dcrocker< at >bbiw.net>, "tony+dkimov< at >maillennium.att.com" <tony+dkimov< at >maillennium.att.com>, "msk< at >cloudmark.com" <msk< at >cloudmark.com>, "stephen.farrell< at >cs.tcd.ie" <stephen.farrell< at >cs.tcd.ie>, "turners< at >ieca.com" <turners< at >ieca.com>, "barryleiba< at >computer.org" <barryleiba< at >computer.org>, "john.hawthorn< at >gmail.com" <john.hawthorn< at >gmail.com>, "ietf-dkim< at >mipassoc.org" <ietf-dkim< at >mipassoc.org>
Sent: Sat, 14 Apr 2012 3:25 PM
Subject: Re: [Technical Errata Reported] RFC6376 (3192)

I've checked this, and it's correct.  We copied the examples from 4871, and
made the editorial error of adding a space without changing the hash.  I'll
mark it as Verified if i hear no objections soon.

Barry

On Saturday, April 14, 2012, RFC Errata System wrote:

Re: [Technical Errata Reported] RFC6376 (3192)

Barry Leiba — 2012-04-14T22:30:33

FWIW, the error was introduced by the RFC Editor, who surely used
double-space-between-sentences style, and didn't know that in that
particular case, the space matters.  And we didn't notice it in AUTH48
reviews.  Something we need to remember to check for, in the rare cases
where it does matter.

Barry

On Saturday, April 14, 2012, Barry Leiba wrote:

Re: [Technical Errata Reported] RFC6376 (3192)

Barry Leiba — 2012-04-14T22:25:08

I've checked this, and it's correct.  We copied the examples from 4871, and
made the editorial error of adding a space without changing the hash.  I'll
mark it as Verified if i hear no objections soon.

Barry

On Saturday, April 14, 2012, RFC Errata System wrote:

FW: [marf] Last Call: (Extensions to DKIM for Failure Reporting) to Proposed Standard

Murray S. Kucherawy — 2012-02-29T21:05:52

FYI, in case anyone wants to comment.

-----Original Message-----
From: marf-bounces< at >ietf.org [mailto:marf-bounces< at >ietf.org] On Behalf Of The IESG
Sent: Wednesday, February 29, 2012 6:58 AM
To: IETF-Announce
Cc: marf< at >ietf.org
Subject: [marf] Last Call: <draft-ietf-marf-dkim-reporting-11.txt> (Extensions to DKIM for Failure Reporting) to Proposed Standard

The IESG has received a request from the Messaging Abuse Reporting Format WG (marf) to consider the following document:
- 'Extensions to DKIM for Failure Reporting'
  <draft-ietf-marf-dkim-reporting-11.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf< at >ietf.org mailing lists by 2012-03-14. Exceptionally, comments may be sent to iesg< at >ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting.

Abstract

   This memo presents extensions to the DomainKeys Identified Mail
   (DKIM) specif

FW: RFC 6541 on DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures

Murray S. Kucherawy — 2012-02-29T19:22:39

FYI

-----Original Message-----
From: ietf-announce-bounces< at >ietf.org [mailto:ietf-announce-bounces< at >ietf.org] On Behalf Of rfc-editor< at >rfc-editor.org
Sent: Wednesday, February 29, 2012 10:59 AM
To: ietf-announce< at >ietf.org; rfc-dist< at >rfc-editor.org
Cc: rfc-editor< at >rfc-editor.org
Subject: RFC 6541 on DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures


A new Request for Comments is now available in online RFC libraries.

        
        RFC 6541

        Title:      DomainKeys Identified Mail (DKIM) Authorized 
                    Third-Party Signatures 
        Author:     M. Kucherawy
        Status:     Experimental
        Stream:     IETF
        Date:       February 2012
        Mailbox:    msk< at >cloudmark.com
        Pages:      16
        Characters: 31655
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-kucherawy-dkim-atps-16.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6541.txt

This experimental specification proposes a modification to DomainKeys Identifie

Governments and DKIM

Rolf E. Sonneveld — 2012-01-18T12:41:03

Hi, all

on June 17th 2011 
(http://lists.opendkim.org/archive/opendkim/users/2011/06/1173.html) I 
sent a mail to the ietf-dkim list about an upcoming expert meeting in 
relation to the submission of DKIM for the  'Comply or Explain' 
standards list, used by the Dutch government and government agencies. As 
a followup I have another question.

Is anyone aware of initiatives or regulations initiated by or endorsed 
by or 'observed' by any government in the country you live? We have seen 
an announcement on this list in November 2010 by Tsuneki Ohnishi about a 
DKIM Japan initiative, where the Japanese government has a status of 
observer (see 
http://web.archiveorange.com/archive/v/8JY9w5vRl0ZInsYJI0OV). I'm 
looking for examples of other/similar initiatives by government 
(agencies) or with involvement of government (agencies) with the purpose 
to aid in the adoption of DKIM on a country or state level.

Thanks for any pointers or information,

/rolf

ATPS Testing

Hector Santos — 2012-01-10T11:08:22

As the first commercial package already supporting ATPS (and ACL which 
I now plan to finally submit an I-D for),  you can run test 
(auto-responder) against some email servers that support it. I will 
gather them from installed customer servers. In the mean time, here is 
our auto-responder email address:

      dkim-autorespond< at >isdg.net

And for those with OpenDKIM setups exploring this, we have a wizard at 
this URL to help prepare your records:

     http://www.winserver.com/public/wcadsp

DKIM WG Greylisting

Hector Santos — 2012-01-10T11:37:19

Now that this WG has not implemented greylisting:

wcSmtpQue version: 2.6
250-Begin Mail Queue Manager
#0001 Address : ietf-dkim< at >mipassoc.org
       Attempts: 4
       NextTime: 01/10/2012 06:44:28 AM
       Response: 451 (451 4.7.1 Greylisting in action, please come 
back later)
250 End Mail Queue Manager

and is causing delivery delays, maybe it can add logic to check for 
member's address and white list or support the SMTP extention for 
Greylist draft:

    http://tools.ietf.org/html/draft-santos-smtpgrey-01

To help alleviate the delivery delays and wasteful queuing/resend 
overhead of member's submissions.

FW: Document Action: 'DKIM Authorized Third-PartySigners' toExperimental RFC (draft-kucherawy-dkim-atps-16.txt)

Murray S. Kucherawy — 2012-01-09T22:17:57

Hi all,

This got approved by the IESG.  Note that it is slightly different than the last time it was discussed here, courtesy of some suggested changes during IESG evaluation.

OpenDKIM has already implemented the revised version and is thus available for interop testing if anyone wants to try this out.

-MSK

-----Original Message-----
From: ietf-announce-bounces< at >ietf.org [mailto:ietf-announce-bounces< at >ietf.org] On Behalf Of The IESG
Sent: Monday, January 09, 2012 2:01 PM
To: IETF-Announce
Cc: RFC Editor
Subject: Document Action: 'DKIM Authorized Third-Party Signers' to Experimental RFC (draft-kucherawy-dkim-atps-16.txt)

The IESG has approved the following document:
- 'DKIM Authorized Third-Party Signers'
  (draft-kucherawy-dkim-atps-16.txt) as an Experimental RFC

This document has been reviewed in the IETF but is not the product of an IETF Working Group.

The IESG contact person is Sean Turner.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-kucherawy-dkim-atps/




Technical Summ

FW: Document Action: 'DKIM Authorized Third-PartySigners' toExperimental RFC (draft-kucherawy-dkim-atps-16.txt)

Murray S. Kucherawy — 2012-01-09T22:17:57

Hi all,

This got approved by the IESG.  Note that it is slightly different than the last time it was discussed here, courtesy of some suggested changes during IESG evaluation.

OpenDKIM has already implemented the revised version and is thus available for interop testing if anyone wants to try this out.

-MSK

-----Original Message-----
From: ietf-announce-bounces< at >ietf.org [mailto:ietf-announce-bounces< at >ietf.org] On Behalf Of The IESG
Sent: Monday, January 09, 2012 2:01 PM
To: IETF-Announce
Cc: RFC Editor
Subject: Document Action: 'DKIM Authorized Third-Party Signers' to Experimental RFC (draft-kucherawy-dkim-atps-16.txt)

The IESG has approved the following document:
- 'DKIM Authorized Third-Party Signers'
  (draft-kucherawy-dkim-atps-16.txt) as an Experimental RFC

This document has been reviewed in the IETF but is not the product of an IETF Working Group.

The IESG contact person is Sean Turner.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-kucherawy-dkim-atps/




Technical Summ

Re: Last Call: (DKIM Authorized Third-Party Signers) to Experimental RFC

Barry Leiba — 2011-11-30T21:07:00

Nota bene:
Sean had this cross-posted to the ietf-dkim list to make sure the DKIM
folks saw it.  Please do NOT make last-call comments here; make them
on ietf< at >ietf.org, as the paragraph above says.

Barry, document shepherd

Re: WG Action: Conclusion of Domain Keys Identified Mail (dkim)

Stephen Farrell — 2011-10-04T16:54:47


On 09/26/2011 07:23 PM, Barry Leiba wrote:

Bit late 'cause I was away, but I second Barry's sentiment. I also
learned quite a bit (or think I did:-) along the way,

Thanks,
S.

Re: WG Action: Conclusion of Domain Keys Identified Mail (dkim)

Franck Martin — 2011-09-26T21:08:22

Well I did mainly [2]...

Crongrats to Barry and Stephen for handling us.

On 9/27/11 8:12 , "Dave CROCKER" <dhc< at >dcrocker.net> wrote:

Re: WG Action: Conclusion of Domain Keys Identified Mail (dkim)

Dave CROCKER — 2011-09-26T20:12:38

On 9/26/2011 11:23 AM, Barry Leiba wrote:


Tenacity is often underrated [1][2] but we've been nothing if not tenacious.

Congrats to us all.

d/



[1] Genius is 1% inspiration and 99% perspiration! / Thomas Edison
[2] Eighty percent of success is showing up / Woody Allen

Re: WG Action: Conclusion of Domain Keys IdentifiedMail (dkim)

Jim Fenton — 2011-09-26T18:51:20

Barry,

Thank you and Stephen for your leadership of this WG.

-Jim

On 9/26/11 11:23 AM, Barry Leiba wrote:

Re: WG Action: Conclusion of Domain Keys IdentifiedMail (dkim)

Barry Leiba — 2011-09-26T18:23:17

And with that, ends an era.  I want to thank everyone who worked hard
on getting the DKIM documents decided, written, and published.  I've
been pleased to chair this group for more than five and a half years.

Barry

Fwd: BCP 167, RFC 6377 on DomainKeys Identified Mail (DKIM) and Mailing Lists

Sean Turner — 2011-09-21T22:25:29

Thanks to all involved!

spt

-------- Original Message --------
Subject: BCP 167, RFC 6377 on DomainKeys Identified Mail (DKIM) and 
Mailing Lists
Date: Wed, 21 Sep 2011 12:10:39 -0700 (PDT)
From: rfc-editor< at >rfc-editor.org
To: ietf-announce< at >ietf.org, rfc-dist< at >rfc-editor.org
CC: ietf-dkim< at >mipassoc.org, rfc-editor< at >rfc-editor.org


A new Request for Comments is now available in online RFC libraries.

         BCP 167
         RFC 6377

         Title:      DomainKeys Identified Mail (DKIM) and
                     Mailing Lists
         Author:     M. Kucherawy
         Status:     Best Current Practice
         Stream:     IETF
         Date:       September 2011
         Mailbox:    msk< at >cloudmark.com
         Pages:      26
         Characters: 61792
         See Also:   BCP0167

         I-D Tag:    draft-ietf-dkim-mailinglists-12.txt

         URL:        http://www.rfc-editor.org/rfc/rfc6377.txt

DomainKeys Identified Mail (DKIM) allows an ADministrative Management
Domain (ADMD) to assume some responsibil

Fwd: RFC 6376 on DomainKeys Identified Mail (DKIM)Signatures

Sean Turner — 2011-09-21T22:24:35

Thanks to all those involved!

spt

-------- Original Message --------
Subject: RFC 6376 on DomainKeys Identified Mail (DKIM) Signatures
Date: Wed, 21 Sep 2011 12:10:23 -0700 (PDT)
From: rfc-editor< at >rfc-editor.org
To: ietf-announce< at >ietf.org, rfc-dist< at >rfc-editor.org
CC: ietf-dkim< at >mipassoc.org, rfc-editor< at >rfc-editor.org


A new Request for Comments is now available in online RFC libraries.


         RFC 6376

         Title:      DomainKeys Identified Mail (DKIM) Signatures
         Author:     D. Crocker, Ed.,
                     T. Hansen, Ed.,
                     M. Kucherawy, Ed.
         Status:     Standards Track
         Stream:     IETF
         Date:       September 2011
         Mailbox:    dcrocker< at >bbiw.net,
                     tony+dkimov< at >maillennium.att.com,
                     msk< at >cloudmark.com
         Pages:      76
         Characters: 176999
         Obsoletes:  RFC4871, RFC5672

         I-D Tag:    draft-ietf-dkim-rfc4871bis-15.txt

         URL:        http://www.rfc-editor.org/rfc/rf

Re: Doublefrom, ADSP and mailing lists in perspective,

Michael Deutschmann — 2011-08-14T02:18:18

"except-mlist" is no worse here than "unknown", which is what the vast
majority of domains will be publishing in the absence of the
"except-mlist" option.


For most domains, the sender benefits are not sufficient to motivate a
"discardable" or TPA deployment.

And with neither TPA, "discardable" nor "except-mlist" in common use,
paying attention to ADSP isn't worth an MX admin's time.  The sender loses
utterly.

---- Michael Deutschmann <michael< at >talamasca.ocis.net>