Franck Martin | 21 Jul 04:42 2014

Re: Error in RFC 5321 concerning SPF and DKIM



Toute connaissance est une réponse à une question.

> On Jul 20, 2014, at 16:36, Dave Crocker <dhc <at> dcrocker.net> wrote:
> 
>> On 7/20/2014 5:50 PM, Franck Martin wrote:
>> This specification does not deal with the verification of return
>>   paths for use in delivery notifications.  Recent work, such as that
>>   on SPF [29] and DKIM [30] [31], has been done to provide ways to improve traceability of the message.
> 
> 
> While they do do that, the sentence seems to me a non-sequitor and in
> particular has nothing to do with the return address, per se.
> 
> So my question is how it helps the SMTP specification reader to have a
> sentence like that and to have it there?
> 

I had the feeling that by removing the last sentence you were making too much of a change therefore the
rejection of the errata

Correcting the incorrect sentence may be acceptable for an errata

How is it helpful? By pointing people in a direction for further reading
_______________________________________________
ietf-smtp mailing list
ietf-smtp <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-smtp
(Continue reading)

Franck Martin | 20 Jul 23:50 2014

Re: Error in RFC 5321 concerning SPF and DKIM

Yes Dave is correct in saying this is erroneous, therefore an errata.

If you want to keep the SPF and DKIM reference, you could state:

This specification does not deal with the verification of return paths for use in delivery notifications. Recent work, such as that on SPF [29] and DKIM [30] [31], has been done to provide ways to improve traceability of the message.
Printed on recycled paper!

On Jul 20, 2014, at 9:39, Dave Crocker <dhc <at> dcrocker.net> wrote:

Hi folks.

I submitted an Errata on RFC 5321 that was rejected due to logic that is
proving a bit challenging to understand.

    http://www.rfc-editor.org/errata_search.php?eid=4055

So I thought I'd check with the SMTP, SPF and DKIM communities to get
some broader review for the substantive issue, before considering
alternative process paths.

Simply put:

    RFC 5321 has some text about SPF and DKIM that is
    simply wrong.

    Given the continuing community confusion about what
    SPF and DKIM do and do not do, I think that having
    the SMTP document perpetuate erroneous views is
    significantly problematic.

I've checked the archive of around the time the text was introduced.
Other that a brief exchange about the 'nature' of DKIM, I don't see any
messages on this topic.

I'd appreciate comments on the factual issues here.  I don't want to
discuss the Errata process.  Just the technical issues.

If folks think my characterization of the error is either correct or
incorrect, please say so and explain.  If you think it can be documented
better, please offer text!


(I've BCC'd the SPF and DKIM lists, to make sure that everyone there
sees this.  But please post any followups to the SMTP list.)


Thanks!

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
ietf-smtp mailing list
ietf-smtp <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-smtp
_______________________________________________
ietf-smtp mailing list
ietf-smtp <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-smtp
Scott Kitterman | 20 Jul 20:53 2014

Re: Error in RFC 5321 concerning SPF and DKIM

On Sunday, July 20, 2014 14:43:40 John C Klensin wrote:
> --On Sunday, 20 July, 2014 13:12 -0400 Scott Kitterman
> 
> <sklist <at> kitterman.com> wrote:
> >...
> >
> > I think your characterization of SPF is almost correct.  It
> > generally concerns  itself with only the domain part of the
> > message, but it can be used to check  authorization of the
> > local part as well (via macros).  If you add a caveat  before
> > validate in "does not validate the entire address" such as
> > (perhaps)  typically or usually, then I think it would be
> > correct.
> 
> Hi.
> 
> Speaking as editor of the hypothetical/ promised 5321bis, I
> appreciate Dave's bringing the issue here, at least separating
> it from what is or is not a valid erratum.
> 
> FWIW, my editing notes on the pre-5321 I-Ds indicate that the
> current text was not of my invention.   I think we should
> concentrate on the substantive issue rather than casting blame,
> so the person who offered the text on which people agreed
> (perhaps by not paying enough attention), will, at least insofar
> as it is within my power, remain anonymous for this discussion.
> 
> However, I note that Dave suggested that people send text.  I
> want to reinforce that.  I was convinced, and remain convinced
> that the spec if better with pointers to DKIM and/or SPF (and,
> when it is updated, to anything else that may be relevant).  I
> believe the consensus when 5321 was being developed was
> consistent with that conviction.  So, while I will obvious do
> whatever the group agrees on, my preference is to replace the
> bad sentence(s) with correct ones rather than dropping them.
> 
> Especially if we have gotten this wrong once, I would really
> appreciate very specific text and discussion of that text.
> Statements like the above are, IMO, useful in clarifying the
> issues but not really actionable where the text is concerned --
> I don't want to guess, either about what text should be written
> or about whether people have or have not agreed text as well as
> ideas.   So, please, send text that others can comment on and
> that I can eventually just past into the draft.

I think any reference to DKIM better belongs to a hypothetical 5322bis.  
Whatever it does, it's not related to the envelope.

I'd be glad to help with this aspect of 5321bis where I agree some reference 
to SPF would make sense (for the purposes of Dave's erratum though I think 
removing the sentence in question is the best solution).

Scott K

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

Dave Crocker | 20 Jul 18:37 2014
Picon

Error in RFC 5321 concerning SPF and DKIM

Hi folks.

I submitted an Errata on RFC 5321 that was rejected due to logic that is
proving a bit challenging to understand.

     http://www.rfc-editor.org/errata_search.php?eid=4055

So I thought I'd check with the SMTP, SPF and DKIM communities to get
some broader review for the substantive issue, before considering
alternative process paths.

Simply put:

     RFC 5321 has some text about SPF and DKIM that is
     simply wrong.

     Given the continuing community confusion about what
     SPF and DKIM do and do not do, I think that having
     the SMTP document perpetuate erroneous views is
     significantly problematic.

I've checked the archive of around the time the text was introduced.
Other that a brief exchange about the 'nature' of DKIM, I don't see any
messages on this topic.

I'd appreciate comments on the factual issues here.  I don't want to
discuss the Errata process.  Just the technical issues.

If folks think my characterization of the error is either correct or
incorrect, please say so and explain.  If you think it can be documented
better, please offer text!

(I've BCC'd the SPF and DKIM lists, to make sure that everyone there
sees this.  But please post any followups to the SMTP list.)

Thanks!

d/
--

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Tony Finch | 17 Jun 13:05 2014
Picon

Re: DANE without DNSSEC (was: certificate pinning)

Brandon Long <blong <at> google.com> wrote:

> Right, I wasn't sure exactly why DANE requires DNSSEC.

The aim is to improve security. There's no point adding complexity if it
doesn't achieve anything.

Tony.
--

-- 
f.anthony.n.finch  <dot <at> dotat.at>  http://dotat.at/
Biscay: Northeast 5 or 6. Slight or moderate. Fair. Good.

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

John Levine | 16 Jun 21:07 2014

Re: DANE without DNSSEC (was: certificate pinning)

PS:

>The next problem with DANE is that it requires users to have an updated
>enough DNS server/client that provides tools for the new RR-Type, as
>opposed to the "overload the TXT record" mechanism that has been popular in
>the email world recently.  I know our code hasn't added support yet, though
>it looks like its in recent BIND implementations. ...

BIND and NSD have supported TLSA since 2012, and any reasonably recent DNS
cache should handle TLSA since it doesn't have any special semantics.  The
problem is more likely to be the web crudware that people use to provision
their DNS zones.

R's,
John

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

John Levine | 16 Jun 21:01 2014

Re: DANE without DNSSEC (was: certificate pinning)

In article <CABa8R6tMTzKKid8BrZH+tDc4sxzgtt2wL1coxvwQm6=gjN__Vg <at> mail.gmail.com> you write:
>Right, I wasn't sure exactly why DANE requires DNSSEC.

It was essentially a political decision, but one that is now cast in
concrete.  The rationale. as I understand it, is that to be a
reasonable replacement for CAs it needs a comparably strong chain of
authority.  DANE without DNSSEC would be a particularly egregious
example of the Internet's traditional security model of putting a ten
ton steel lock on a screen door.

>DANE requiring DNSSEC seems to be the perfect being the enemy of the good.

That, too.  Technically, there's nothing keeping you from publishing DANE
records in unsigned zones, although I don't know what libraries are likely
to do with them.

R's,
John

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

Brandon Long | 7 Jun 01:12 2014
Picon

certificate pinning

Now that more servers are offering STARTTLS, it would seem beneficial to move forward towards certificate validation.

How do people feel about bringing the concept of certificate pinning from HTTP (http://tools.ietf.org/html/draft-ietf-websec-key-pinning-13) to SMTP?

I realize there's also DANE TLSA (RFC 6698), but that has a requirement on DNSSEC that may limit its deployment for some time to come.

translating the syntax in the http draft to smtp ehlo, I would imagine something like (on a second EHLO after the TLS session is started):

C: EHLO foo
S: 250-SIZE 35882577
S: 250-8BITMIME
S: 250-PKP PIN-SHA256=d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=
S: 250-PKP PIN-SHA256=LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=
S: 250-PKP MAX-AGE=259200
S: 250-ENHANCEDSTATUSCODES
S: 250 CHUNKING

alternative syntaxes:
S: 250-PKPPIN SHA256 d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=
S: 250-PKPEXPIRES 259200

Or one line:
S: 250-PKP MAX-AGE=259200 PIN-SHA256=d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM= 

Brandon

_______________________________________________
ietf-smtp mailing list
ietf-smtp <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-smtp
Murray S. Kucherawy | 7 May 23:32 2014
Picon

Registering email status codes for authentication failures

...and then promptly forgot about it.  Given that email authentication is front-and-center these days, is it worth updating it and then pushing it through?  Given its size, does anyone have thoughts about processing it through APPSAWG?

-MSK, not in any particular role this time
_______________________________________________
ietf-smtp mailing list
ietf-smtp <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-smtp
Alexey Melnikov | 29 Mar 17:36 2014

Registration request for smtp:// and submit:// URI schemes (draft-melnikov-smime-msa-to-mda-04)

Hi,
I wanted to use smtp:// URIs in X.509 URI subjectAltName values. My use 
case is returning such URIs in S/MIME certificates of S/MIME capable 
Mail Transfer Agents (MTAs). My colleague pointed out that smtp:// URIs 
are not registered with IANA (despite being used by several products, 
including at least one open source), so here is my attempt to register 
it. I am also registering submit:// URI scheme, which is a similar URI 
schemes, but for designating Mail Submission Agents.

SMTP URI registration

       URI scheme name: smtp

       Status: permanent

       URI scheme syntax:
       smtpuri = "smtp://" authority ["/" [ "?" query ]]
       authority = <defined in RFC 3986>
       query = <defined in RFC 3986>
       If :<port> is omitted from authority, the port defaults to 25.
       The query component is reserved for future extensions.

       URI scheme semantics:
       The smtp: URI scheme is used to designate SMTP servers (e.g.
       listener endpoints, S/MIME agents performing Domain signing), SMTP
       accounts.
       There is no MIME type associated with this URI.

       Encoding considerations:

       SMTP user names are UTF-8 strings and MUST be percent-encoded as
       required by the URI specification [RFC3986], Section 2.1.

       Applications/protocols that use this URI scheme name:
       The smtp: URI is intended to be used by applications that might
       need access to an SMTP server (for example email clients or MTAs
       can use smtp: URIs in configuration files)
       or for SMTP servers to describe their listener endpoints.
       A web browser can launch an email client application that can use
       the specified smtp: URI for account configuration or for showing
       SMTP server capabilities.
       These URIs can also be used in LDAP data stores for storing server or
       account configuration, as well as in X.509 certificates 
containing URIs.

       Interoperability considerations:
       Several implementations are already using smtp: URIs for server
       configuration in configuration files or APIs.

       Security considerations: Clients resolving smtp: URIs that wish to
       achieve data confidentiality and/or integrity SHOULD use the
       STARTTLS command (if supported by the server) before starting
       authentication, or use a SASL mechanism, such as GSSAPI, that
       provides a confidentiality security layer.

       Contact: Alexey Melnikov <alexey.melnikov <at> isode.com>

       Author/Change controller: IESG

       References: [[draft-melnikov-smime-msa-to-mda-04]] and [RFC5321].

SUBMIT URI registration

       URI scheme name: submit

       Status: permanent

       URI scheme syntax:
       submituri = "submit://" authority ["/" [ "?" query ]]
       authority = <defined in RFC 3986>
       query = <defined in RFC 3986>
       If :<port> is omitted from authority, the port defaults to 587.
       The query component is reserved for future extensions.

       URI scheme semantics:
       The submit: URI scheme is used to designate SMTP Submission
       servers (e.g. listener endpoints, S/MIME agents performing Domain
       signing), SMTP accounts.
       There is no MIME type associated with this URI.

       Encoding considerations:
       SMTP user names are UTF-8 strings and MUST be percent-encoded as
       required by the URI specification [RFC3986], Section 2.1.

       Applications/protocols that use this URI scheme name:
       The submit: URI scheme is intended to be used by applications 
that might
       need access to an SMTP Submission server (for example email
       clients) or for SMTP Submission servers to describe their listener
       endpoints.
       The submit: URI scheme is intended to be used by applications 
that might
       need access to an SMTP Submission server (for example email clients)
       or for SMTP Submission servers to describe their listener endpoints.
       A web browser can launch an email client application that can use
       the specified submit: URI for account configuration or for showing
       SMTP server capabilities.
       These URIs can also be used in LDAP data stores for storing server or
       account configuration, as well as in X.509 certificates 
containing URIs.

       Interoperability considerations:
       None.

       Security considerations: Clients resolving submit: URIs that wish
       to achieve data confidentiality and/or integrity SHOULD use the
       STARTTLS command (if supported by the server) before starting
       authentication, or use a SASL mechanism, such as GSSAPI, that
       provides a confidentiality security layer.

       Contact: Alexey Melnikov <alexey.melnikov <at> isode.com>

       Author/Change controller: IESG

       References: [draft-melnikov-smime-msa-to-mda-04]] and [RFC6409].

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

Paul Smith | 26 Mar 17:57 2014
Picon

Re: confirm 8bdfea7f026277ef3569cabfc9e9ce16d6648021 (fwd)


On 26/03/2014 16:54, John Levine wrote:
> Hi.  I certainly haven't been unsubscribing from lists.  Any idea
> what's going on?
Maybe someone was trying to get you off the list for some reason?

In which case... did you really want to post the confirmation request 
you got? - someone could actually unsubscribe you now (unless you edited 
the confirmation code before posting it)

-

Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

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


Gmane