Re: [dmarc-ietf] Document update

2013-10-16 Thread Murray S. Kucherawy
meaning to ask: which cutoff? (More broadly, are the remaining steps documented somewhere?) - Roland On 10/16/2013 08:56 AM, Murray S. Kucherawy wrote: Hi all, I'm planning to scrape this list for items that would be good to include in a revision to the draft and post it prior

Re: [dmarc-ietf] Section 12.2.2

2013-11-30 Thread Murray S. Kucherawy
-02 of the base draft in progress. Regarding outstanding issues, I have some things to bring to the list, starting here: On Fri, Aug 9, 2013 at 2:46 PM, Andreas Schulze s...@andreasschulze.dewrote: If nobody implemented http reporting yet we should consider removing it from the spec... Any

Re: [dmarc-ietf] [dmarc-discuss] DMARC URI size allowance

2013-11-30 Thread Murray S. Kucherawy
I don't see any action items here in terms of changes to the base draft. Am I correct in that assessment? I'll assume yes; someone should speak up if otherwise. -MSK On Wed, Aug 14, 2013 at 8:32 PM, Steven M Jones s...@crash.com wrote: Adding the [dmarc-ietf] list for spec considerations.

Re: [dmarc-ietf] Suggestion: handle null reverse path SPF alignment with RFC5322.From in different domain

2013-11-30 Thread Murray S. Kucherawy
Any other input on this point? DMARC currently only considers the SPF result if there is alignment between the return path and the From field. On Mon, Sep 2, 2013 at 3:42 PM, Raman Gupta rocketra...@gmail.com wrote: I encountered a use case recently with an auto-generated email with

Re: [dmarc-ietf] SRS helps SPF/DMARC

2014-02-14 Thread Murray S. Kucherawy
On Fri, Feb 14, 2014 at 9:56 AM, Vlatko Salaj vlatko.sa...@goodone.tkwrote: however, waking those SRS ppl up may rly require some authority figure. they are, kind of, happy with their protocol, and its stability and usage. do try, if u wish. at least i will be grateful. :)= It's kind of

Re: [dmarc-ietf] SRS helps SPF/DMARC

2014-02-14 Thread Murray S. Kucherawy
On Fri, Feb 14, 2014 at 1:51 PM, Vlatko Salaj vlatko.sa...@goodone.tkwrote: It may not be that ATPS solves any of your problems, but the ATPS community (small as it is) can similarly say that SRS doesn't solve theirs. well, i do not have any proposal on how to fix ATPS-induced DKIM

Re: [dmarc-ietf] DMARC's purpose

2014-04-14 Thread Murray S. Kucherawy
On Sat, Apr 12, 2014 at 9:23 AM, Miles Fidelman mfidel...@meetinghouse.netwrote: Well, let's see: - DMARC.org defines the DMARC Base Specification with a link to https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ - an IETF document - they published an information Internet draft,

Re: [dmarc-ietf] alignment and parsing logic as optionals

2014-04-18 Thread Murray S. Kucherawy
On Thu, Apr 17, 2014 at 1:42 PM, Vlatko Salaj vlatko.sa...@goodone.tkwrote: wrong conclusion, but i'm not gonna repeat myself. one example should be enough to everybody. I think if you want to get your ideas understood and thus adopted, you're going to have to set your patience and

Re: [dmarc-ietf] alignment and parsing logic as optionals

2014-04-18 Thread Murray S. Kucherawy
On Thu, Apr 17, 2014 at 10:01 AM, Joseph Humphreys jhumphr...@salesforce.com wrote: The alignment domain-list solution seems trivial to me, and it works without active support from the sender, which is nice. How does it work without active support from the sender? Doesn't the sender first

[dmarc-ietf] Comportment on this list

2014-05-29 Thread Murray S. Kucherawy
Colleagues, The IETF has some written guidelines about management of and conduct on mailing lists. In particular, the IETF's anti-harassment policy [1] and a number of RFCs [2] [3] [4] [5] and IESG statements [6] [7] form the body of the IETF's guidelines and procedures regarding mailing list

Re: [dmarc-ietf] send-to-a-friend, was Solution for

2014-05-29 Thread Murray S. Kucherawy
On Thu, May 29, 2014 at 10:58 AM, Brandon Long bl...@google.com wrote: There seem to be rather a lot, since it's a feature on most magazine and newspaper web sites. Since you mentioned the WSJ, they use the user's own address as the From: address (I just checked.) Some do the hack you

Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection

2014-05-29 Thread Murray S. Kucherawy
On Thu, May 29, 2014 at 1:28 PM, J. Gomez jgo...@seryrich.com wrote: I don't believe TPA-Label hits the mark between solving a big hurt and simple. IOW, it's too complicated for the amount of pain it would resolve. Just my opinion, take care, I'm of the same opinion as above. In my

Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)

2014-05-30 Thread Murray S. Kucherawy
On Thu, May 29, 2014 at 8:44 PM, Scott Kitterman skl...@kitterman.com wrote: The reason there is no IETF working group is that the people behind DMARC were unwilling to entertain participation in a working group that had a charter that allowed for any chance of a change to the DMARC protocol.

Re: [dmarc-ietf] Comportment on this list

2014-05-30 Thread Murray S. Kucherawy
On Fri, May 30, 2014 at 11:25 AM, John Sweet sw...@secondlook.com wrote: On Fri, May 30, 2014 at 1:31 AM, Brandon Long bl...@google.com wrote: I think many of the folks on this list don't use email the way that the vast majority of people do. The longer I work in email, the less I feel as

Re: [dmarc-ietf] Yet another mailing list solution thread

2014-06-02 Thread Murray S. Kucherawy
On Mon, Jun 2, 2014 at 1:34 PM, Scott Kitterman skl...@kitterman.com wrote: There is a discussion about defining new codes for email authentication failures in progress on apps-discuss which may interest people interested in this particular topic.

[dmarc-ietf] Comportment again (was Re: confusing 3rd party support so it remains out)

2014-06-06 Thread Murray S. Kucherawy
On Fri, Jun 6, 2014 at 1:14 PM, Vlatko Salaj vlatko.sa...@goodone.tk wrote: i need DMARC alignment rigidity gone. and some wise ppl to accept it. well, we may lack that, i guess. Mr. Salaj, I recently sent a message to the list explaining that we require the discussions on this list to be

Re: [dmarc-ietf] Advice to MUA

2014-06-07 Thread Murray S. Kucherawy
On Sat, Jun 7, 2014 at 4:52 PM, J. Gomez jgo...@seryrich.com wrote: MUAs SHOULD display to the end user, in UTF8 (and punycode), in a non ambiguous font, the domain used for the assertion of the DMARC policy, as well as the result of this assertion. A non ambiguous font is a font where

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

2014-06-09 Thread Murray S. Kucherawy
On Sun, Jun 8, 2014 at 9:06 PM, Hector Santos hsan...@isdg.net wrote: Fundamentally, any From-Corruption (good term to use) concept is bad. 30 years of mail software/product/hosting development across multiple networks tells me so, it ethically burns inside me as wrong and I have strong

Re: [dmarc-ietf] Advice to MUA

2014-06-09 Thread Murray S. Kucherawy
On Mon, Jun 9, 2014 at 2:30 PM, J. Gomez jgo...@seryrich.com wrote: True, but at the same time UX is something that every user can talk about, as per se every user has experience with it. Every time I hear that UI is a black art to be refined only by ultra specialists, I shiver in fear,

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

2014-06-09 Thread Murray S. Kucherawy
On Mon, Jun 9, 2014 at 8:59 PM, Stephen J. Turnbull step...@xemacs.org wrote: [2] PGP can be worked around by placing the signed body in a separate MIME part from the header and/or footer parts, and DKIM could at least be adapted to decorated subjects using z= and footers using l=, although

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

2014-06-10 Thread Murray S. Kucherawy
On Tue, Jun 10, 2014 at 12:41 AM, Vlatko Salaj vlatko.sa...@goodone.tk wrote: introducing new ML requirements has already been characterised as not an ML solution. we have a few of them already, and all much simpler than any YADAs. The person on this list that actually represents a mailing

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

2014-06-10 Thread Murray S. Kucherawy
On Tue, Jun 10, 2014 at 7:13 AM, Franck Martin fra...@peachymango.org wrote: -- On Tue, Jun 10, 2014 at 6:58 AM, Franck Martin fra...@peachymango.org wrote: -- On Mon, Jun 9, 2014 at 11:52 PM, Franck Martin fra...@peachymango.org

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

2014-06-10 Thread Murray S. Kucherawy
On Tue, Jun 10, 2014 at 9:19 AM, Hector Santos hsan...@isdg.net wrote: The person on this list that actually represents a mailing list so far seems to like the idea, and has explained why to some extent. I think that's much more valuable feedback. More valuable than other feedback? [...]

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

2014-06-10 Thread Murray S. Kucherawy
Hi Alessandro, On Tue, Jun 10, 2014 at 8:14 AM, Alessandro Vesely ves...@tana.it wrote: First, weak signatures which are not part of a chain should be ignored by verifiers. An authentication chain can be defined as a set of valid DKIM signatures and possibly an SPF authentication of

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

2014-06-10 Thread Murray S. Kucherawy
On Tue, Jun 10, 2014 at 11:20 AM, Hector Santos hsan...@isdg.net wrote: It is more easier, more feasible, more safe, to just reject/discard the failed message (due to policy) at the backend and be done with it. In your opinion. It is the expert opinion of million of IETF-MAN-HOURS and

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

2014-06-10 Thread Murray S. Kucherawy
On Tue, Jun 10, 2014 at 12:16 PM, Vlatko Salaj vlatko.sa...@goodone.tk wrote: That, sir, is false, both as to fact and as to causality. The choice was among different varieties of pain, but no amount of preparation would have made the pain avoidable. that's a completely wrong assumption.

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

2014-06-10 Thread Murray S. Kucherawy
On Tue, Jun 10, 2014 at 12:56 PM, Vlatko Salaj vlatko.sa...@goodone.tk wrote: u ppl keep repeating that. however, u never say what IS the reason. why don't u enlighten us, then? Instead of assuming the reason and thus making false accusations, you could've asked for the details first.

[dmarc-ietf] Moderation of Vlatko Salaj

2014-06-10 Thread Murray S. Kucherawy
Colleagues, Under the procedures of BCP 94, the list administrators have decided to moderate the access of Vlatko Salaj to the mailing list, effective immediately, until 10 July 2014. If Mr. Salaj posts anything, it will come to us first, and we shall permit the message to be posted only if, in

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

2014-06-10 Thread Murray S. Kucherawy
On Tue, Jun 10, 2014 at 12:56 PM, Vlatko Salaj vlatko.sa...@goodone.tk wrote: the story of my life... i'm always in minority, fighting for survival. It is entirely possible to fight for the minority without acting this way. It's unfortunate that you feel like your lifetime of frustration

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

2014-06-11 Thread Murray S. Kucherawy
On Wed, Jun 11, 2014 at 7:49 PM, Hector Santos hsan...@isdg.net wrote: On 6/11/2014 4:58 PM, Murray S. Kucherawy wrote: One thing that is missing (and there's a placeholder for it) is examples so you can see how it works. I'll make sure that's there for -01. Examples are good. Can we

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

2014-06-12 Thread Murray S. Kucherawy
On Wed, Jun 11, 2014 at 10:39 PM, Dave Crocker dcroc...@gmail.com wrote: The irony of your suggestion is that it requires having 'unupgraded' software reliably use the version number, given that they haven't needed to do that before either... Section 6.1.1 of DKIM makes it a MUST that

Re: [dmarc-ietf] Change the mailing list protocol, not DMARC.

2014-06-12 Thread Murray S. Kucherawy
On Thu, Jun 12, 2014 at 12:33 PM, Elizabeth Zwicky zwi...@yahoo-inc.com wrote: On 6/12/14, 9:36 AM, Terry Zink tz...@exchange.microsoft.com wrote: Franck Martin wrote: I found that to build the override list for mailing list, I could log DMARC rejected emails that contained a List-Id

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

2014-06-12 Thread Murray S. Kucherawy
On Thu, Jun 12, 2014 at 4:05 PM, Stephen J. Turnbull step...@xemacs.org wrote: Can't both the version bump issue and the token signature issue be ameliorated by incorporating the token signature in the DKIM-Delegate field? There's a protocol collision on the t= tag which would need to be

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

2014-06-14 Thread Murray S. Kucherawy
On Sat, Jun 14, 2014 at 12:35 PM, ned+dm...@mrochek.com wrote: Yes, you could do the equivalent of the version bump by changing the name of the header, but I don't see the point. If you're going to bump the version, you need to use the opportunity to solve the more general underlying

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

2014-06-15 Thread Murray S. Kucherawy
On Sat, Jun 14, 2014 at 11:53 PM, Stephen J. Turnbull step...@xemacs.org wrote: How about a new tag, shf= (special header fields). Ignored by legacy verifiers, as required; otherwise, contains a colon-separated list of fields that get special handling by verifiers. Special handling

Re: [dmarc-ietf] draft-levine-dkim-conditional-00

2014-06-16 Thread Murray S. Kucherawy
On Mon, Jun 16, 2014 at 1:17 PM, John Levine jo...@taugh.com wrote: Here's a draft that puts the forwarding thing into DKIM, with the dread version bump. It defines a general syntax for conditional signatures, with the forwarding signature the only condition defined so far. (Since you

Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version

2014-06-19 Thread Murray S. Kucherawy
On Thu, Jun 19, 2014 at 11:15 AM, Hector Santos hsan...@isdg.net wrote: While DKIM-BASE tried to clean up this separation of the author domain policy, it could not because of all the past existing ADSP or SSP references in the many DKIM related RFCs, see RFC6376, section 1.1. But

Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version

2014-06-19 Thread Murray S. Kucherawy
On Thu, Jun 19, 2014 at 12:36 PM, Douglas Otis doug.mtv...@gmail.com wrote: Our company has had extensive experience dealing with email spoofing. While reputation is able to deal with bulk spamming, it is ineffective at dealing with a phishing problem, the intent behind DMARC. It is a basic

Re: [dmarc-ietf] draft-levine-dkim-conditional-00

2014-06-19 Thread Murray S. Kucherawy
On Thu, Jun 19, 2014 at 2:51 PM, Ned Freed ned.fr...@mrochek.com wrote: I'm uneasy with an increase in version that isn't done in a complete replacement for RFC6376. We're not just registering a couple of new extension tags here. I would prefer that, if we do go decide to go down this

Re: [dmarc-ietf] The theory of DKIM versions

2014-06-19 Thread Murray S. Kucherawy
On Thu, Jun 19, 2014 at 4:20 PM, John R Levine jo...@taugh.com wrote: I'm uneasy with an increase in version that isn't done in a complete replacement for RFC6376. The problem may be that we don't agree about what DKIM versions mean. Here's what I would like them to mean: [...] Actually

[dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-01.txt

2014-06-20 Thread Murray S. Kucherawy
: New Version Notification for draft-kucherawy-dkim-delegate-01.txt To: Murray S. Kucherawy superu...@gmail.com, Dave Crocker dcroc...@bbiw.net A new version of I-D, draft-kucherawy-dkim-delegate-01.txt has been successfully submitted by Murray S. Kucherawy and posted to the IETF repository

Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-01.txt

2014-06-20 Thread Murray S. Kucherawy
On Fri, Jun 20, 2014 at 11:21 AM, John Levine jo...@taugh.com wrote: This looks an awful lot like my draft-levine-cdkim-00 and draft-levine-dkim-conditional-00 except that mine has more bits of DKIM in the cdkim signature so it can sign To and From to limit the range of spoofage. The

[dmarc-ietf] ***SPAM*** 8.001 (5) Re: ***SPAM*** 7.348 (5) Re: Re: Draft DMARC working group charter

2014-06-26 Thread Murray S. Kucherawy
On Thu, Jun 26, 2014 at 10:26 AM, Jim Fenton fen...@bluepopcorn.net wrote: The base specification relies on the ability of an email receiver to determine the organizational domain responsible for sending mail. An organizational domain is the basic domain name obtained through a public

Re: [dmarc-ietf] Draft DMARC working group charter

2014-07-02 Thread Murray S. Kucherawy
On Wed, Jul 2, 2014 at 1:45 AM, Alessandro Vesely ves...@tana.it wrote: My question about the stance toward DKIM tweaks[1] was never answered. To re-state, while preclusion is apparent for the organizational domain issue, it is not clear for DKIM. The charter says: The working group

Re: [dmarc-ietf] Draft DMARC working group charter

2014-07-02 Thread Murray S. Kucherawy
On Wed, Jul 2, 2014 at 9:59 AM, Douglas Otis doug.mtv...@gmail.com wrote: Agreed, as it seems such efforts have been excluded by the charter language. It would be a shame, since there needs to be a remedy permitting back-office services such as those offered by Intuit and the like. It seems

[dmarc-ietf] ATPS, TPA-Label, etc.

2014-07-20 Thread Murray S. Kucherawy
[Changing Subject: to a new thread and dropping i...@ietf.org, since this is not charter discussion] On Sun, Jul 20, 2014 at 12:27 AM, Douglas Otis doug.mtv...@gmail.com wrote: ATPS is not the lite version of TPA-Label. This is explained in

Re: [dmarc-ietf] p= ordering

2014-07-30 Thread Murray S. Kucherawy
On Tue, Jul 29, 2014 at 4:42 PM, Tomki Camp tc...@agari.com wrote: 5.2 has 'A DMARC policy record MUST comply with the formal specification found in Section 5.3 http://www.blackops.org/%7Emsk/dmarc/draft-dmarc-base.html#dmarc_abnf in that the v and p tags MUST be present and MUST appear in

Re: [dmarc-ietf] Start of DMARC WG + proposed milestones

2014-08-23 Thread Murray S. Kucherawy
On Sat, Aug 23, 2014 at 7:34 AM, Miles Fidelman mfidel...@meetinghouse.net wrote: I did notice the absence of anything related to process. How are we going to get to a document (that) captures all known interoperability issue between DMARC and indirect email flows? If this were an RFC,

Re: [dmarc-ietf] Milestones changed for dmarc WG (public suffix exclusion)

2014-08-29 Thread Murray S. Kucherawy
On Fri, Aug 29, 2014 at 12:37 PM, Tim Draegen t...@eudaemon.net wrote: Simply put, the public suffix concept is useful beyond what DMARC requires of it. The best that DMARC can do (as a piece of technology) is fully articulate 1 specific use case for the public suffix concept, and hope that

Re: [dmarc-ietf] Milestones changed for dmarc WG (public suffix exclusion)

2014-08-30 Thread Murray S. Kucherawy
On Fri, Aug 29, 2014 at 7:13 PM, Douglas Otis doug.mtv...@gmail.com wrote: While the PSL might be useful for offering some web related assertions, its current form is inappropriate for email policy. Those working on the web/email related issues might hope these common concerns will engender

Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider

2014-09-15 Thread Murray S. Kucherawy
Though I would never put such a thing in a standards document, OpenDKIM does have the capability to rewrite arriving header fields prior to signing/verifying to overcome things like this. Your ESP's verifier could be trained to ignore the added line prior to verifying, or better yet, do DKIM

Re: [dmarc-ietf] Indirect mail flows: DKIM signature breakage by cloud anti-virus/spam provider

2014-09-15 Thread Murray S. Kucherawy
How will most mail clients know not to display it if it's made part of the body? On Mon, Sep 15, 2014 at 4:39 PM, Terry Zink tz...@exchange.microsoft.com wrote: Having the Virus scanned by xxx defeats the purpose of advertising because most mail clients won't display it, and the point of

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

2014-09-17 Thread Murray S. Kucherawy
On Wed, Sep 17, 2014 at 1:43 AM, Sven Krohlas sven.kroh...@1und1.de wrote: RFC 7372 proposes to use a 550 response code for reverse DNS auth failures, see section 3.3. Reverse DNS checks are usually done early in the connection (like IP blocks) in the connection establishment stage of the

[dmarc-ietf] draft-kucherawy-dmarc-base haircut

2014-09-17 Thread Murray S. Kucherawy
Colleagues, As you know, the DMARC base draft is being processed via the Independent Stream. Procedurally it's ready to move forward toward publication, with the caveat that the prose in it needs a serious haircut. (There is also the option to split the document before publishing it, but I

Re: [dmarc-ietf] Modeling MLM behavior

2014-10-06 Thread Murray S. Kucherawy
On Mon, Oct 6, 2014 at 2:52 PM, Rolf E. Sonneveld r.e.sonnev...@sonnection.nl wrote: Can I get some clarification on the intent here? As worded, this paragraph suggests that we are looking to produce a model for MLMs to follow in a DMARC-aware world. I was under the impression that (a)

Re: [dmarc-ietf] Modeling MLM behavior

2014-10-06 Thread Murray S. Kucherawy
On Mon, Oct 6, 2014 at 4:15 PM, Hector Santos hsan...@isdg.net wrote: Murray, I think we need to make the distinction of two different concepts and acronyms; MLM Mailing List Manager and MLS Mail List Servers that serve the MLM market. There are some basic integration guidelines for both the

Re: [dmarc-ietf] Modeling MLM behavior

2014-10-07 Thread Murray S. Kucherawy
On Tue, Oct 7, 2014 at 1:41 PM, Tim Draegen t...@eudaemon.net wrote: The intention is to have something in place -- the MLM model -- that can be used to quickly identify issues that are related to DMARC interoperability with any given piece of MLM software. I read Alessandro's model as a way

Re: [dmarc-ietf] wiki vs. list?

2014-10-23 Thread Murray S. Kucherawy
On Thu, Oct 23, 2014 at 11:04 AM, Hector Santos hsan...@isdg.net wrote: I'm already lost of whats going on. It seems we are waiting of Murray. Its all Murray. Geez, Its all really Murray's framework to all this. Not a negative, but there has to be more. There is more. There has always been

Re: [dmarc-ietf] wiki vs. list?

2014-10-26 Thread Murray S. Kucherawy
On Sat, Oct 25, 2014 at 9:57 AM, Dave Crocker d...@dcrocker.net wrote: On 10/25/2014 12:34 PM, J. Gomez wrote: DMARC is a DKIM Policy Framework. According the marketing, it has gain widespread adoption especially among your list users domains. Isn't why you are here, to stop it? If by

[dmarc-ietf] draft-kucherawy-dmarc-base revision submitted

2014-10-28 Thread Murray S. Kucherawy
Colleagues, With apologies once again that it's taken so long, I have submitted the base draft again to the datatracker. It underwent what Eliot Lear calls a haircut, which is to say I spent a good chunk of time rearranging the material, consolidating redundant sections, removing unnecessarily

Re: [dmarc-ietf] draft-kucherawy-dmarc-base-04 issue

2014-11-02 Thread Murray S. Kucherawy
Just noticed that I never replied to this: On Fri, Aug 29, 2014 at 8:39 PM, Scott Kitterman skl...@kitterman.com wrote: Since this is the WG list, I'm not sure if this is still the right list for issues with the base spec or not, but here goes ... The definition of fo in Section 5.2, General

Re: [dmarc-ietf] draft-kucherawy-dmarc-base

2014-11-03 Thread Murray S. Kucherawy
On Sun, Nov 2, 2014 at 6:28 AM, Scott Kitterman skl...@kitterman.com wrote: On Sunday, November 02, 2014 01:42:49 Murray S. Kucherawy wrote: ... As was done with the DKIM deployment RFCs, the same has been done for DMARC. It seems neither DKIM nor DMARC follow the path of least

Re: [dmarc-ietf] draft-kucherawy-dmarc-base

2014-11-05 Thread Murray S. Kucherawy
On Wed, Nov 5, 2014 at 10:35 AM, Terry Zink tz...@exchange.microsoft.com wrote: Since SPF authorizes an often _shared_ outbound IP address, it has been accurately described as an authorization method. DMaRC permits a DKIM signature to be spoofed and still allow a message to be accepted

Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback

2014-11-07 Thread Murray S. Kucherawy
On Fri, Nov 7, 2014 at 10:06 AM, John Levine jo...@taugh.com wrote: 1) Evaluate all the domains you find, and if any of them have published DMARC policies, apply the strictest one ... Given the anti-phishing goals of DMARC, I don't see how anything else makes any sense. Or you could skip a

Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback

2014-11-07 Thread Murray S. Kucherawy
On Fri, Nov 7, 2014 at 8:57 PM, turnb...@sk.tsukuba.ac.jp wrote: Trent Adams writes: - It is important to note that identifier alignment cannot occur, and DMARC determination applied, with a message that is not valid per RFC 5322 [MAIL]. This is particularly true when a message has

[dmarc-ietf] draft-kucherawy-dmarc-base updated (-06)

2014-11-10 Thread Murray S. Kucherawy
I've posted an update to the base draft, based on recent feedback from Ned and others. Hopefully I've resolved all of the concerns (especially the major ones), as the ISE would like to send the draft to the IESG for conflict review in the next day or two. It also has to begin formal review of

Re: [dmarc-ietf] Indirect email flows

2014-11-12 Thread Murray S. Kucherawy
On Wed, Nov 12, 2014 at 2:22 PM, Franck Martin fra...@peachymango.org wrote: I'm just asking for this list to be set up exactly like the i...@ietf.org list. If Elizabeth ensures she emails in txt only, everything will be fine. i...@ietf.org is the outlier, actually. Every other IETF list

[dmarc-ietf] Jim Fenton's review of -04

2014-12-19 Thread Murray S. Kucherawy
Colleagues, draft-kucherawy-dmarc-base is nearing IESG conflict review, and it's been pointed out that a review from back in April has not been properly attended to. Could I get the WG (forgive me, co-chairs!) to comment on this so that I can see what changes might be appropriate here? Having

Re: [dmarc-ietf] draft-kucherawy-dmarc-base updated (-06)

2014-12-23 Thread Murray S. Kucherawy
Hi Rolf, getting back to your review (thanks for the nudge): On Wed, Nov 12, 2014 at 6:26 PM, Rolf E. Sonneveld r.e.sonnev...@sonnection.nl wrote: Abstract: This lack of cohesion has several effects: receivers have difficulty providing feedback to senders about authentication, senders

Re: [dmarc-ietf] DMARC and TEMP errors was: Re: Jim Fenton's review of -04

2014-12-23 Thread Murray S. Kucherawy
On Mon, Dec 22, 2014 at 3:18 PM, Scott Kitterman skl...@kitterman.com wrote: As I read -08 what to do in that case is undefined. There's a dangling pointer to 5.6.3. It's dangling because nothing in that section addresses the question of how to handle DKIM/SPF temporary errors. 5.6.3's

Re: [dmarc-ietf] Jim Fenton's review of -04

2014-12-23 Thread Murray S. Kucherawy
On Mon, Dec 22, 2014 at 10:44 AM, Scott Kitterman skl...@kitterman.com wrote: There was a recent thread on postfix-users about DMARC rejections when there are DNS errors that caused me to review -08 to see what it says on the matter. At the end of section 5.6.2, it says: Handling of

Re: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-04

2014-12-23 Thread Murray S. Kucherawy
Covering the stuff Dave didn't cover: On Wed, Apr 16, 2014 at 3:11 PM, Jim Fenton fen...@bluepopcorn.net wrote: Top of page 6: The receiver reports to the domain owner... The receiver actually sends reports to a report receiver designated by the domain owner. Fixed. 2.4 Out of Scope I

Re: [dmarc-ietf] Jim Fenton's review of -04

2014-12-23 Thread Murray S. Kucherawy
On Wed, Dec 24, 2014 at 2:13 AM, Franck Martin fra...@peachymango.org wrote: I think we should recommend something here, not sure if it needs to be normative. We do say to ignore the SPF policy when p!=none, though I think we can be normative on the lower layers. I see 2 options here:

Re: [dmarc-ietf] Jim Fenton's review of -04

2014-12-23 Thread Murray S. Kucherawy
On Wed, Dec 24, 2014 at 2:40 AM, Franck Martin fra...@peachymango.org wrote: -- *From: *Murray S. Kucherawy superu...@gmail.com *To: *Franck Martin fra...@peachymango.org *Cc: *dmarc@ietf.org, Scott Kitterman skl...@kitterman.com *Sent: *Tuesday, December 23

Re: [dmarc-ietf] Jim Fenton's review of -04

2014-12-24 Thread Murray S. Kucherawy
On Wed, Dec 24, 2014 at 4:09 AM, Scott Kitterman skl...@kitterman.com wrote: 5.6.2 promises 5.6.3 addresses the question and it doesn't. At the very least, 5.6.2 should be fixed not to over promise what 5.6.3 will provide. I'm not clear why you say it doesn't. 5.6.3 describes two options for

Re: [dmarc-ietf] Jim Fenton's review of -04

2014-12-24 Thread Murray S. Kucherawy
On Wed, Dec 24, 2014 at 4:04 AM, Scott Kitterman skl...@kitterman.com wrote: The draft strongly encourages DMARC implementers to ignore SPF policy, so I don't think assuming messages will be deferred due only due to SPF or DKIM results indicating a temporary DNS error is appropriate. If

Re: [dmarc-ietf] Jim Fenton's review of -04

2014-12-24 Thread Murray S. Kucherawy
On Wed, Dec 24, 2014 at 10:22 AM, Dave Crocker d...@dcrocker.net wrote: I disagree. DMARC operators all seem to apply this practice, so it's correct to say that if you play this game, you reject mail from non-existent domains. Essentially in this way DMARC is a profile of

Re: [dmarc-ietf] Jim Fenton's review of -04

2014-12-24 Thread Murray S. Kucherawy
On Wed, Dec 24, 2014 at 5:48 PM, Scott Kitterman skl...@kitterman.com wrote: Messages for which SPF and/or DKIM evaluation encounters a temporary DNS error have not received a definitive result for steps 3 and/or 4 above. If the message has not passed the the DMARC mechanism check

Re: [dmarc-ietf] Jim Fenton's review of -04

2014-12-24 Thread Murray S. Kucherawy
On Wed, Dec 24, 2014 at 11:23 AM, Dave Crocker d...@dcrocker.net wrote: The goal, as you state it, is at the level of seeking world peace. It is very laudable and and very, very broad. It covers vastly more than the scope of DMARC. DMARC is a specific bit of technology working towards that

Re: [dmarc-ietf] Jim Fenton's review of -04

2014-12-25 Thread Murray S. Kucherawy
On Thu, Dec 25, 2014 at 1:08 AM, Scott Kitterman skl...@kitterman.com wrote: I don't think it does. What I was trying to say is that if you already got an aligned pass from one method, you're done. It doesn't matter if they other one gets a DNS error, you already have a definitive result.

Re: [dmarc-ietf] Jim Fenton's review of -04

2014-12-25 Thread Murray S. Kucherawy
On Thu, Dec 25, 2014 at 10:15 PM, Dave Crocker dcroc...@gmail.com wrote: One could argue either way about the multi-valued From:, but at least it has an essential relationship to DMARC, since DMARC evaluates From:. If DMARC were required to handle multi-valued From:, it would alter DMARC

Re: [dmarc-ietf] draft-kucherawy-dmarc-base updated (-06)

2014-12-31 Thread Murray S. Kucherawy
On Mon, Dec 29, 2014 at 2:29 PM, Rolf E. Sonneveld r.e.sonnev...@sonnection.nl wrote: 3.1.3 Flow diagram The box titled 'User Mailbox' could give the impression that there's only one choice for delivery. However, quarantining can be done without delivery to a mailbox. I'd suggest to

Re: [dmarc-ietf] Jim Fenton's review of -04

2014-12-31 Thread Murray S. Kucherawy
OK, seriously, I hope I don't have to crack this open again. Conflict review is slated for the 1/8 telechat, and a flurry of last minute edits might not sit well with the IESG. We need to leave actual work, as much as at all possible, to the WG, and not to hacking on the ISE version. Diffs to

Re: [dmarc-ietf] -10 (was: Jim Fenton's review of -04)

2015-01-01 Thread Murray S. Kucherawy
On Thu, Jan 1, 2015 at 1:02 PM, Kurt Andersen kander...@linkedin.com wrote: I'm OK with the new wording, but would have liked to see the -09 statement about reporting temp errors carried over: When otherwise appropriate due to DMARC policy, receivers MAY send feedback reports regarding

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-19 Thread Murray S. Kucherawy
On Mon, Jan 19, 2015 at 6:30 AM, Tim Draegen t...@eudaemon.net wrote: No objection — please do use the WG’s tracker for these items. Anne’s thorough review will be picked up (and not rediscovered!) if we’ve got an obvious place to start from. Done for Anne's points, and I'll do so for Jim

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-19 Thread Murray S. Kucherawy
On Mon, Jan 19, 2015 at 6:43 AM, Tim Draegen t...@eudaemon.net wrote: DMARC implementations are already in the wild and deployed. Input to the existing specification will be largely based on working implementations. You might have your own reasons for waiting for this WG to review the DMARC

Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it

2015-01-21 Thread Murray S. Kucherawy
On Tue, Jan 20, 2015 at 6:14 PM, John Levine jo...@taugh.com wrote: Do people concur with this change, or something close to it? I'm OK with it, but to the meta-question, I realize the practical issues involved with yanking something out of the production queue, but in this case I wonder if

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-16 Thread Murray S. Kucherawy
Hello Anne, On Fri, Jan 16, 2015 at 4:41 PM, Anne Bennett a...@encs.concordia.ca wrote: Having just spent several hours poring over this document (-12), I might as well send my additional minor observations. I suspect that some of you will consider these items trivial, but they gave me pause

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-20 Thread Murray S. Kucherawy
On Tue, Jan 20, 2015 at 1:44 PM, Anne Bennett a...@encs.concordia.ca wrote: I apologize for my inadvertently poor timing; I was catapulted into all this last week when my parent domain (also my Organizational Domain) published an SPF record and a DKIM record, and we became concerned that they

Re: [dmarc-ietf] Comments on draft-ietf-dmarc-interoperability

2015-01-30 Thread Murray S. Kucherawy
at 4:05 PM, Franck Martin fra...@peachymango.org wrote: -- *From: *Murray S. Kucherawy superu...@gmail.com *To: *dmarc@ietf.org *Sent: *Friday, January 30, 2015 1:23:48 AM *Subject: *[dmarc-ietf] Comments on draft-ietf-dmarc-interoperability Thanks for putting

Re: [dmarc-ietf] RFC 7489 on Domain-based Message Authentication, Reporting, and Conformance (DMARC)

2015-03-18 Thread Murray S. Kucherawy
On Wed, Mar 18, 2015 at 1:19 PM, Tim Draegen t...@eudaemon.net wrote: Hi Murray Elizabeth, thanks for wrestling this through the process. The Working Group can now adopt this as input. /goes off to figure out which buttons need to be pushed =- Tim I have to resubmit it as

Re: [dmarc-ietf] Formal specification, URI

2015-03-15 Thread Murray S. Kucherawy
On Sun, Mar 15, 2015 at 11:53 AM, Alessandro Vesely ves...@tana.it wrote: This seems to be a bug: OLD: dmarc-uri = URI [ ! 1*DIGIT [ k / m / g / t ] ] ; URI is imported from [URI]; commas (ASCII ; 0x2c) and exclamation points (ASCII

Re: [dmarc-ietf] interoperability issues around gateway-transformation

2015-03-19 Thread Murray S. Kucherawy
There was one proposed: https://tools.ietf.org/html/draft-kucherawy-dkim-list-canon-00 This working group will be discussing this and other options before long. -MSK On Thu, Mar 19, 2015 at 1:45 PM, John Bucy jb...@google.com wrote: I was glad to see mention of content-transfer-encoding

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

2015-03-21 Thread Murray S. Kucherawy
On Fri, Mar 20, 2015 at 4:40 PM, Dave Crocker d...@dcrocker.net wrote: On 3/19/2015 12:52 PM, Murray S. Kucherawy wrote: And since the From field is the only one users really see every time, I'm not sure that declaring and supporting yet another no-seriously-this-is-the-author field would

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

2015-03-19 Thread Murray S. Kucherawy
On Wed, Mar 18, 2015 at 4:38 PM, Terry Zink tz...@exchange.microsoft.com wrote: If bulk email providers have shown no interest in promoting a solution, why do we think they'd latch onto this new non-aligned header field as a solution? +1. And since the From field is the only one users

Re: [dmarc-ietf] interoperability issues around gateway-transformation

2015-03-20 Thread Murray S. Kucherawy
? cheers john On Thu, Mar 19, 2015 at 6:28 PM, Murray S. Kucherawy superu...@gmail.com wrote: There was one proposed: https://tools.ietf.org/html/draft-kucherawy-dkim-list-canon-00 This working group will be discussing this and other options before long. -MSK On Thu, Mar 19, 2015 at 1

Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

2015-03-20 Thread Murray S. Kucherawy
On Fri, Mar 20, 2015 at 1:56 PM, J. Gomez jgo...@seryrich.com wrote: Why is it better for DMARC to be adapted to indirect email flows, instead of indirect email flows to be adapted to DMARC? What does provide more value to end users at large: indirect email flows to be kept old-style, or the

Re: [dmarc-ietf] Formal specification, URI

2015-03-16 Thread Murray S. Kucherawy
On Mon, Mar 16, 2015 at 3:51 AM, Alessandro Vesely ves...@tana.it wrote: Section 2.2 of RFC3986 lists semi-colon as a reserved character that has to be percent-encoded in these URLs. We don't need to repeat it here, I think. If the spec is going to be read by ignorants like me, it's

Re: [dmarc-ietf] Formal specification, URI

2015-03-16 Thread Murray S. Kucherawy
On Mon, Mar 16, 2015 at 12:57 PM, Steven M Jones s...@crash.com wrote: Just to be explicit, it also allows for multiple mailto: URIs - something that is seen in the wild, though perhaps not if one looks up a half dozen DMARC records at random. But at the end of January multiple mailto: URIs

Re: [dmarc-ietf] Formal specification, URI

2015-03-16 Thread Murray S. Kucherawy
On Mon, Mar 16, 2015 at 12:22 PM, Murray S. Kucherawy superu...@gmail.com wrote: Your question is Are they equivalent? I believe they are. Although it might be ideal to have a specification so tight that there's exactly one way to do something, in the end I don't think it's harmful to have

  1   2   3   4   5   6   7   8   9   >