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 matter.

Barry

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

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) specification to allow for detailed reporting of message
   authentication failures in an on-demand fashion.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-marf-dkim-reporting/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-marf-dkim-reporting/ballot/

No IPR declarations have been submitted directly on this I-D.

_______________________________________________
marf mailing list
marf< at >ietf.org
https://www.ietf.org/mailman/listinfo/marf

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 Identified Mail (DKIM) allowing advertisement of third-party signature authorizations that are to be interpreted as equivalent to a signature added by the administrative domain of the message's author.  This document defines an Experimental Protocol for the Internet community.

EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community.  It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor< at >rfc-editor.org.  Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

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 Summary

  DKIM deliberately makes no binding between the DNS domain of the signer of a
  message and any other identity found in the message.  Despite this, there is an
  automatic human perception that an author domain signature (one for which the
  RFC5322.From domain matches the DNS domain of the signer) is more valuable or
  trustworthy than any other.  There is currently no protocol by which an ADMD can
  announce that DKIM signatures on its mail added by other ADMDs should also be
  considered trustworthy by verifiers.  This presents an experimental mechanism
  for doing so.

Working Group Summary

  This is an individual submission, but was discussed with the former DKIM
  participants, on the DKIM mailing list.  Note that there is NOT general
  agreement that this protocol is important, or even useful.  There is good
  consensus that experimentation is needed to determine utility, and this document
  sets up that experiment by proposing a protocol for it.

Document Quality

  ATPS has been prototyped, in preparation for this experiment, and is available
  in an open-source implementation.  Other implementations are expected as
  the experiment proceeds.

Personnel

  Barry Leiba is the Document Shepherd.
  Sean Turner is the responsible Area Director.


IANA Note

  The new registry should be nested under DKIM Parameters.

_______________________________________________
IETF-Announce mailing list
IETF-Announce< at >ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

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 Summary

  DKIM deliberately makes no binding between the DNS domain of the signer of a
  message and any other identity found in the message.  Despite this, there is an
  automatic human perception that an author domain signature (one for which the
  RFC5322.From domain matches the DNS domain of the signer) is more valuable or
  trustworthy than any other.  There is currently no protocol by which an ADMD can
  announce that DKIM signatures on its mail added by other ADMDs should also be
  considered trustworthy by verifiers.  This presents an experimental mechanism
  for doing so.

Working Group Summary

  This is an individual submission, but was discussed with the former DKIM
  participants, on the DKIM mailing list.  Note that there is NOT general
  agreement that this protocol is important, or even useful.  There is good
  consensus that experimentation is needed to determine utility, and this document
  sets up that experiment by proposing a protocol for it.

Document Quality

  ATPS has been prototyped, in preparation for this experiment, and is available
  in an open-source implementation.  Other implementations are expected as
  the experiment proceeds.

Personnel

  Barry Leiba is the Document Shepherd.
  Sean Turner is the responsible Area Director.


IANA Note

  The new registry should be nested under DKIM Parameters.

_______________________________________________
IETF-Announce mailing list
IETF-Announce< at >ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

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 responsibility for a message.  Based on
deployment experience with DKIM, this document provides guidance for
the use of DKIM with scenarios that include Mailing List Managers
(MLMs).  This memo documents an Internet Best Current Practice.

This document is a product of the Domain Keys Identified Mail Working 
Group of the IETF.

BCP: This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
   http://www.ietf.org/mailman/listinfo/ietf-announce
   http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor< at >rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

_______________________________________________
IETF-Announce mailing list
IETF-Announce< at >ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

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/rfc6376.txt

DomainKeys Identified Mail (DKIM) permits a person, role, or
organization that owns the signing domain to claim some
responsibility for a message by associating the domain with the
message.  This can be an author's organization, an operational relay,
or one of their agents.  DKIM separates the question of the identity
of the Signer of the message from the purported author of the
message.  Assertion of responsibility is validated through a
cryptographic signature and by querying the Signer's domain directly
to retrieve the appropriate public key.  Message transit from author
to recipient is through relays that typically make no substantive
change to the message content and thus preserve the DKIM signature.

This memo obsoletes RFC 4871 and RFC 5672.  [STANDARDS-TRACK]

This document is a product of the Domain Keys Identified Mail Working 
Group of the IETF.

This is now a Draft Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
   http://www.ietf.org/mailman/listinfo/ietf-announce
   http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor< at >rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

_______________________________________________
IETF-Announce mailing list
IETF-Announce< at >ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

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>