gmane.ietf.apps-discuss

Re: I-D Action: draft-ietf-appsawg-rfc5451bis-02.txt

John Levine — 2013-05-19T05:21:16

Mine does, but there probably aren't five people in the world other
than me using it.


Hmmn.  Let's say I have a mail server farm generating 5451 A-R headers
and the guy down the hall has a filtering/sorting/delivering farm
interpreting them.  Then someone shows up with 5451bis. I am a good
doobie and update my software to comply with 5451bis which, since I am
only using authentication schemes described in 5451, merely involves
adding /1 after the authserv-id.  I hear the sound of screaming from
the other end of the hall as the unexpected slash breaks the
filtering.

Frankly, I'd lose the slash.  Whether or not it was a mistake to leave
it out in the first place, adding it now only creates a gratuitous
incompatibility.

Re: Review of: draft-ietf-appsawg-malformed-mail-03

John R Levine — 2013-05-19T03:00:24

Well, since you asked.

I'm looking at the whole thing and I have to say I don't understand the 
point of sections 4 and 5.  I understand that Exchange and Outlook smash 
messages into an internal format and sort of reconstruct the original, 
sometimes, but I can't tell whether that's what you're referring to or 
something else.

I think sec 4 is trying to say mail software may have a variety of 
internal representations, but all we're talking about here are messages 
interchanged in what purports to be 5322 (or its predecessors) format.

Sec 5 appears to say that if you try to parse and unparse a message, you 
probably won't get back quite the same thing and particularly in the 
presence of DKIM signatures and the like, details matter, so don't do 
that. If you need multiple formats, retain the original so if you need to 
bounce or report something, you can report what you actually received.

If that's not what you mean, I'm totally confused.

This is more a question for Ned: in section 7, how much legitim

Re: I-D Action: draft-ietf-appsawg-rfc5451bis-02.txt

Murray S. Kucherawy — 2013-05-18T23:06:53

OK.



Seems to me adding "at least as an option" with respect to the SPF
implementations is probably sufficient.


I made that change on two premises:

1) I've yet to see a single implementation that includes a version number
in its output, though there are some that do look for it.  It seems to me
it's a safe change to make on that basis.

2) The way versioning is done at that point in the header field is
inconsistent with where it's done adjacent to the methods.  It's nicer on
the eyes and easier for parsers if they're done the same way.  I consider
this a bug in RFC5451.  I never opened an erratum for this before just
fixing it in the -bis draft, but I think I probably should have.

I'd hate to see this recycle at PS just for this change, so either I can
back it out, or we could call it a bug fixed in this draft and leave the
version alone.  Although you're correct that strictly speaking it's
incompatible, it only affects consumers regarding a currently unused
protocol feature.

Does anyone else have an

draft-snell-merge-patch-08 in Ruby

Steve Klabnik — 2013-05-18T19:58:09

Hey there!

James suggested that I post to this list, so here I am.

I'm a committer to Ruby on Rails, and Rails 4 is near a release. One
of the changes in Rails 4 is the usage of PATCH, which means I'm
checking up on various diff media types. Mark Nottingham brought my
attention to draft-snell-merge-patch as a simpler variant of
json-patch.

Anyway, I have a _mostly_ working implementation of the latest draft
as a gem, here: https://github.com/steveklabnik/json-merge_patch .
It's only missing the "Recursively apply rule 2" portion. Hopefully
I'll be finishing it off soon.

I'd say that overall this draft was super simple to implement,
especially given Ruby's (like many scripting languages) ease of
mapping JSON directly to its rich Hash and Array types in the language
core.

I may have one or two thoughts on the language of the spec, but I need
to re-read it and take some notes this time around.

- Steve

Re: Review of: draft-ietf-appsawg-malformed-mail-03

Ned Freed — 2013-05-18T17:39:04

This is looking good IMO, but of course I'd say that given how much of my
feedback has been incorporated into the doc.


I concur. Additional eyes are really needed on this.

Ned

Re: I-D Action: draft-ietf-appsawg-rfc5451bis-02.txt

Scott Kitterman — 2013-05-17T22:22:47

Comments:


I've also seen iprev in the wild and it's supported by the python authres 
module I helped develop.  We've also implemented DMARC based on the latest 
draft.  Iprev is in 5451, so I think it should be mentioned.


I think this overstates things with respect to SPF.  Most implementations have 
not adopted authres and even in the cases where they have, it's an option, not 
the default.

In the ABNF:

I believe the change from:

authres-header = "Authentication-Results:" [CFWS] authserv-id
[ CFWS version ]

to:

authres-header = "Authentication-Results:" [CFWS] authserv-id
[ [CFWS] "/" [CFWS] authres-version ]

is an incompatible change and if you really want to make it, you should bump 
the version number.  I checked and with authres, your example is mis-parsed.

Authentication-Results: example.org/1; none

In this example, the authserv-id is "example.org", but authres, using the RFC 
5451 ABNF parses this and determines the authserv-id is "example.org/1"

If you want to make this change, I th

Full review of draft-ietf-appsawg-xml-mediatypes (was: Re: Getting 3023bis, a.k.a. draft-ietf-appsawg-xml-mediatypes, moving)

Martin J. Dürst — 2013-05-17T10:59:12

I have finally completed a full review of 
draft-ietf-appsawg-xml-mediatypes-00. Here are my findings:

Technically, this document is in good shape. It describes actual 
practice that's widely established.

But I'm sorry to say that this document is pretty much unreadable, in 
particular for those who we want to read it. The reason for this is that 
it contains a huge amount of historical ballast and (for most readers) 
unnecessary justifications.

I think it should not be too difficult to remedy this problem, and it 
will help the average reader, which which I mean somebody who wants to 
publish or consume an XML document, or define a Mime type with a +xml 
suffix.

I'll try to point out the main changes that I'd start with below; I may 
be able to give more help, but next week looks busy.

On 2013/05/01 21:13, "Martin J. Dürst" wrote:


Removing the current Appendix A and pointing to it in RFC 3023 is the 
first and biggest step. I didn't realize this, but currently, RFC 3023 
is listed as normative, whic

Re: Review of: draft-ietf-appsawg-malformed-mail-03

Murray S. Kucherawy — 2013-05-17T07:07:37

I've posted a new version of the draft based on all the recent feedback.
Thanks to those that gave some!

With it refreshed and with all the new content, I'd love to have some more
reviews of it in its current form.

-MSK, hatless


On Wed, May 15, 2013 at 6:33 PM, John R Levine <johnl< at >taugh.com> wrote:

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

Re: Review of: draft-ietf-appsawg-malformed-mail-03

Murray S. Kucherawy — 2013-05-17T02:22:15


The document doesn't talk about what end users should be shown.  It's all
about filters and other handling agents.  There's some specific text in
there that talks about "internal representations" and such; see Section 4.



The MSA is not in scope here, other than the fact that the document
mentions that MSAs need to be more strict.  This is all about MTAs and
filters.



See above.

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

Re: Review of: draft-ietf-appsawg-malformed-mail-03

Franck Martin — 2013-05-17T01:47:35

8.1.5. Unbalanced Quotes

Not sure I agree with that, we should avoid to place a domain name in the display part.

should be interpreted as:
To: "Joe" <joe< at >example.com>

8.5. Header Field Counts

I see option 1 at the MTA level
option 2 at the MSA
for an MUA, it has to deal with an invalid message, I think 3 could apply, but then the MUA only renders the message why should it alter it, especially if the message will be rendered by different MUA.


8.6. Missing Header Fields
I see it differently...

If the email comes from a MSA then add the fields, if the email comes from another MTA, reject the email.

Re: WGLC on draft-ietf-appsawg-rfc5451bis-00

Murray S. Kucherawy — 2013-05-16T23:54:21

What does the reply encode that downstream agents need?  If I know that, I
can suggest something more in line with how A-R was designed to operate.
_______________________________________________
apps-discuss mailing list
apps-discuss< at >ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

Re: APPSDIR review of draft-housley-rfc2050bis-01

Russ Housley — 2013-05-16T21:21:29

Tobias:

Thanks for the review.  Really, the delegation id to the RIRs. which in turn use the ICANN ASO to establish global policy.

Thanks again,
  Russ


On May 16, 2013, at 4:56 PM, Tobias Gondrom wrote:


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

APPSDIR review of draft-housley-rfc2050bis-01

Tobias Gondrom — 2013-05-16T20:56:18

Hi,

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).
Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-housley-rfc2050bis-01
Title: The Internet Numbers Registry System
Reviewer: Tobias Gondrom
Review Date: May-16

Status: Informational

Summary: I believe the draft is ready for publication.

Review:
0. The document is well written and I very much like that the document
is short and concise.

Comments:
1. One of two key sentences I took from the document is that its
self-described scope is "only documenting" the status quo. See Section
1: "does not propose any changes...., but it does provide information
about the current... system".
When reading this, one question the reader might consider is whether t

Re: WGLC on draft-ietf-appsawg-rfc5451bis-00

Alessandro Vesely — 2013-05-16T15:22:15

That's not a client IP, but the return value of the lookup.  Passing
that value to downstream filters is the whole point of adding this
header field, otherwise it would have to be looked up again.  Details
such as DKIM's key length, IMHO, are often in a comment because they
are of minor importance, not because they are not a visible part of
the message.)

The policy.txt is important as it contains a domain name.  Albeit A-R
is not intended to be restricted to domain-based authentication,
that's by far the most common case, a granularity that was settled
many years ago.  By indicating a "somewhat responsible" entity, the
method is semantically consistent with that strategy.

Re: WGLC on draft-ietf-appsawg-rfc5451bis-00

Murray S. Kucherawy — 2013-05-16T14:27:00

To be consistent with the other registered methods, the policy.ip and
policy.txt things wouldn't be included.  A-R is meant to provide results
and return details of what visible parts of a message were evaluated (e.g.,
header fields, SMTP properties).  The client IP isn't one of those, nor is
resulting text.
_______________________________________________
apps-discuss mailing list
apps-discuss< at >ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

Re: WGLC on draft-ietf-appsawg-rfc5451bis-00

Alessandro Vesely — 2013-05-16T13:24:54

One is the DNS White List (dnswl) method, used by Courier (mentioned
in Appendix E).  It writes:

  Authentication-Results: wmail.tana.it;
      dnswl=pass dns.zone=list.dnswl.org
      policy.ip=127.0.9.1
      policy.txt="ietf.org http://dnswl.org/s?s=1703"

Since it was me who suggested to use Authentication-Results, I think
it's up to me to register that.  I'm waiting for this I-D to get
published so as to avail of Designated Expert rather than IETF review.

Re: Review of: draft-ietf-appsawg-malformed-mail-03

John R Levine — 2013-05-16T01:33:54

Yup.  They may have fixed it by now, haven't checked lately since the
procmail rule is harmless either way.

Regards,
John Levine, johnl< at >taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

Re: Review of: draft-ietf-appsawg-malformed-mail-03

Ned Freed — 2013-05-15T20:32:59


FWIW, I agree completely with everything you said, and I hope it's reflected
in what I wrote.



NYT? Wow. I hadn't noticed they were one of the places that does it. The
example I usually think of is one of the sources of political spam^H^H^H^H
legitimate bulk mail which seems to do it intermittently. But that's
nowhere near as good as example as the NYT.

Another amusing thing one of these bulk email generators does is put out
multiparts marked with a quoted-printable CTE. (The multipart is not, in fact
encoded, although there have been other cases in the past where it was.) I
don't know if this one is worth calling out in the doc or not.

Ned

Re: Review of: draft-ietf-appsawg-malformed-mail-03

John Levine — 2013-05-15T20:26:13

Way better than what I sent.


I use Alpine which is one of the very few MUAs that take Murray's
advice and ignore MIME headers if the MIME-Version is missing.  It is
a pain in the patoot, since it is invariably wrong.  I ended up using
procmail to add the missing header to mail from known screwups like
the NY Times so I could read it properly.

R's,
John

Re: Review of: draft-ietf-appsawg-malformed-mail-03

Ned Freed — 2013-05-14T17:07:28

Great!




This is going to take a lot more than three paragraphs to do properly. I'd
suggest something like this (apologies in advance - this is *very* rough, but
I'm in the middle of an office move and don't have time right now to wordsmith
the text the way I normally would):

--

8.7 Missing or incorrect charset information

MIME provides the means to include textual material employing charsets other
than US-ASCII. Such material is required to have an identifiable charset.
Charset identification is done using a charset parameter in the content-type
header field, a charset label within the MIME entity itself, or the charset
may be implicitly specified by the content-type [RFC 6657].

It is unfortunately fairly common for required charset information to be
missing or incorrect in textual MIME entities. As such, processing agents
should perform basic sanity checks, e.g.,

(1) US-ASCII is 7bit only so 8bit material is necessarily not US-ASCII.
(2) UTF-8 has a very specific syntactic structure that other 8bit

Re: Call for Adoption: draft-snell-merge-patch

James M Snell — 2013-05-15T01:34:46

FYI... A ruby implementation by Steve Klabnik...
  https://github.com/steveklabnik/json-merge_patch

- James

On Fri, May 3, 2013 at 2:10 PM, Murray S. Kucherawy <superuser< at >gmail.com> wrote: