Steve Atkins | 1 Dec 02:54 2014

A trivial question about line lengths

RFC 5322 discusses line lengths both in terms of the maximum line length an MTA can be required to handle (998
bytes) but also a more conservative 78 character limit, driven by the requirement to support user
interfaces that are only 78 characters wide.

If I'm wrapping a header by breaking a line with "\r\n\t", and I'm trying to comply with the spirit of the RFC,
how many characters am I allowed to put on the continuation line?

Is it 77, as I have a single tab character already, and I'm allowed 78 total? Or is it 72, as in the glass
teletype world the RFC seems to live in the tab character will consume 8 display characters to the first tab
stop, leaving me another 72 before I run into the right edge of the screen?

Cheers,
  Steve

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

Franck Martin | 19 Sep 09:35 2014

Re: [dmarc-ietf] RFC 7372 on Email Authentication Status Codes

I thought we had extended SMTP codes for that. To bring meaning to the rejection. The only thing the client
MTA needs to know is what to do with the message when it is rejected.

I think that's what the xxx should express:
- don't try again
- try again in same or different session
- disconnect and try again later
- disconnect and try again on another MTA immediately
- ok
- ok continue
- ....

Toute connaissance est une réponse à une question.

> On Sep 19, 2014, at 9:28, Alessandro Vesely <vesely <at> tana.it> wrote:
> 
>> On Thu 18/Sep/2014 20:24:38 +0200 Christoph Kluge wrote:
>> 
>> But that isn’t the point.  The question is whether SMTP clients SHOULD also
>> expect a “policy code” in CONNECT and MAY act accordingly, and how this
>> is covered by said RFC.
> 
> Every upcoming authentication method has at some point considered the
> need to color its rejections with its own reply code.  For an older
> snippet on 550 vs 554, see:
> 
>   John C Klensin, [yam] Ambiguities in RFC 5321, 21 Nov 2009
>   http://www.ietf.org/mail-archive/web/yam/current/msg00186.html

> 
> My understanding is that SMTP reply codes serve to guide protocol
(Continue reading)

John C Klensin | 7 Sep 18:28 2014

draft-klensin-smtp-521code-02.txt

Hi.

To promote tidiness, I've just posted
draft-klensin-smtp-521code-02.txt.   It responds to an extended
discussion on the Apps-Discuss list and some on the IETF llst
about the new nullMX spec, error codes, and RFC 1846.  The scope
of the draft itself is intended to be quite narrow -- it updates
RFC 5321 by adding two codes, 521 and 556, to SMTP and defines
the uses for both.  In particular, it takes no stance on whether
dummy servers such as those proposed in 1846 or nullMX DNS
records should be used at all.

I've directed discussion toward this list on the theory that the
substance of the I-D is really an SMTP matter.  I assume the
draft will be handled as an individual submission.

best,
    john

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

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

Gmane