ni
On Wed, Dec 31, 2014, 8:36 PM Murray S. Kucherawy
wrote:
> 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 deliver
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
Hi, Murray,
On 12/24/2014 06:45 AM, Murray S. Kucherawy wrote:
Hi Rolf, getting back to your review (thanks for the nudge):
On Wed, Nov 12, 2014 at 6:26 PM, Rolf E. Sonneveld
mailto:r.e.sonnev...@sonnection.nl>> wrote:
Abstract:
This lack of cohesion has several effects: recei
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, send
Apologies for the very late response, but since you asked me a direct question
about this I figured I owed you an answer.
"Murray S. Kucherawy" wrote:
> On Fri, Nov 7, 2014 at 8:57 PM, wrote:
> > Trent Adams writes:
> >
> > > -
> > > It is important to note that identifier alignment cannot
On Wed, Nov 12, 2014 at 1:26 PM, Rolf E. Sonneveld <
r.e.sonnev...@sonnection.nl> wrote:
> Hi, Murray,
>
Hello Rolf,
> I started earlier this week a review of -05. Please find below my
> comments, I think most if not all of them also apply to -06. I didn't have
> time to finish my review, but
Hi, Murray,
On 11/11/2014 02:52 AM, Murray S. Kucherawy wrote:
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 revie
On Mon, Nov 10, 2014 at 6:50 PM, Brandon Long wrote:
> I don't think his changes in 5.6.1 would change anything we do. We
> currently require a single From header with a single address with a valid
> domain on all messages (not restricted to DMARC). RFC 6854 as used for EAI
> downgrades shouldn
On 11/10/2014 5:52 PM, Murray S. Kucherawy wrote:
> I've posted an update to the base draft, based on recent feedback from
> Ned and others.
Tidbits...
Intro:
> Security terms used in this document are defined in [SEC-TERMS].
There's a Terminology section, so this really belongs there.
Franck Martin writes:
> So I'm curious to see some real world examples. If you could add
> them in the wiki may be?
(a) Of the ones I have ready access to, there are privacy concerns
with the email itself in many cases, and employer issues with all
of them (Japanese institutions don't l
- Original Message -
> From: "Stephen J. Turnbull"
> To: "Franck Martin"
> Cc: "Brett McDowell" , dmarc@ietf.org, "Scott
> Kitterman"
> Sent: Monday, November 10, 2014 11:05:23 AM
> Subject: Re: [dmarc-ietf] draft-kucherawy
On Sunday, November 02, 2014 01:44:16 AM Murray S. Kucherawy wrote:
> Just noticed that I never replied to this:
>
> On Fri, Aug 29, 2014 at 8:39 PM, Scott Kitterman
>
> 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 no
Franck Martin writes:
> Ps: Please don't summarize my experience to Linkedin, I had many
> other lives before that.
I have no choice but to make assumptions about the context in which
you collected your data, since you didn't describe it, and the data
collection context is required to assess th
[Excuse my broken mail system; until the tech staff return on Monday, it
looks like I'm stuck with a webmail interface where I can't change my From
to the subscribed address or break lines properly etc.]
> On Fri, Nov 7, 2014 at 8:57 PM, wrote:
>> Trent Adams writes:
>> > -
>> > It is import
Printed on recycled paper!
> On Nov 9, 2014, at 23:22, Stephen J. Turnbull wrote:
>
> Franck Martin writes:
>
>> I wish the mailbox-list syntax in the From would be deprecated for
>> the mailbox syntax, but it is unlikely to happen, may be when
>> RFC5322 gets revised (under Security, end to
Franck Martin writes:
> I wish the mailbox-list syntax in the From would be deprecated for
> the mailbox syntax, but it is unlikely to happen, may be when
> RFC5322 gets revised (under Security, end to end, IPv6 experience),
I don't understand why any of those experiences would cause RFC 5322
- Original Message -
> From: "Brett McDowell"
> To: "Scott Kitterman"
> Cc: dmarc@ietf.org
> Sent: Sunday, November 9, 2014 12:30:31 PM
> Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
> On Sun, Nov 9, 2014 at 2:58 PM, Scott Kitt
On Sun, Nov 9, 2014 at 2:58 PM, Scott Kitterman
wrote:
> >We would like to apply the most strict policy, but doesn't that
> >conflict
> >with the p=none policy, where Domain Owners can start gathering reports
> >
> >without having to bother about impact on the disposition of their mail?
> >
> >Fu
On November 9, 2014 1:44:11 PM EST, "Rolf E. Sonneveld"
wrote:
>On 11/08/2014 01:40 AM, J. Trent Adams wrote:
>
>[...]
>
>> 5.6.2. Determine Handling Policy
>>
>> To arrive at a policy disposition for an individual message, Mail
>> Receivers MUST perform the following actions or their semantic
>
Printed on recycled paper!
> On Nov 9, 2014, at 10:27, Rolf E. Sonneveld
> wrote:
>
> On 11/09/2014 04:03 PM, Tim Draegen wrote:
>>> On Nov 8, 2014, at 8:38 PM, Franck Martin wrote:
>>>
>>> There are no secret sauces. I thought it was clear this type of language on
>>> this list is frown u
On 11/08/2014 01:40 AM, J. Trent Adams wrote:
[...]
5.6.2. Determine Handling Policy
To arrive at a policy disposition for an individual message, Mail
Receivers MUST perform the following actions or their semantic
equivalents. Steps 2-4 MAY be done in parallel, whereas steps 5 and 6
require
On 11/09/2014 04:03 PM, Tim Draegen wrote:
On Nov 8, 2014, at 8:38 PM, Franck Martin wrote:
There are no secret sauces. I thought it was clear this type of language on
this list is frown upon as non constructive?
Just a point of clarification here. The original author was referring to decisi
uot;
>>> Cc: dmarc@ietf.org, superu...@gmail.com
>>> Sent: Friday, November 7, 2014 10:47:20 AM
>>> Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
>>>
>>>
>>>> For From: headers with address-free groups, recall that the
>>
On November 9, 2014 4:31:31 AM EST, Franck Martin
wrote:
>
>- Original Message -
>> From: ned+dm...@mrochek.com
>> To: "John Levine"
>> Cc: dmarc@ietf.org, superu...@gmail.com
>> Sent: Friday, November 7, 2014 10:47:20 AM
>> Subject: Re: [d
Trimming the CC list, as we're getting into spam-trap numbers of
mailboxes.
Rolf E. Sonneveld writes:
> The current effort to publish DMARC as informational RFC is mainly, to
> document the current specification 'as is', to be able to refer from
> other documents to a published spec. The con
> On Nov 8, 2014, at 8:38 PM, Franck Martin wrote:
>
> There are no secret sauces. I thought it was clear this type of language on
> this list is frown upon as non constructive?
Just a point of clarification here. The original author was referring to
decisions that receivers make when proces
On 11/9/2014 4:19 AM, Franck Martin wrote:
I'm not talking on how many mailboxes/domain there are in this header
It would be wrong to assume SMTP will reject messages based on possible
RFC5322 violations.
While SMTP implementations have been lenient, they have been lenient in a way
which is
On 11/8/2014 8:29 PM, Franck Martin wrote:
Note that an email with no RFC 5322 field is not valid, as well as one with
more than 1. This header is mandatory as well as the Date header. These are the
only 2 headers mandatory in an email.
So rejecting an email with no RFC 5322 or more than one
On Nov 9, 2014, at 1:19 AM, Franck Martin wrote:
> - Original Message -
>> From: "Douglas Otis"
>> To: "Franck Martin"
>>
>> Dear Franck,
>>
>>> Note that an email with no RFC 5322 field is not valid, as well as one with
>>> more than 1. This header is mandatory as well as the Date h
- Original Message -
> From: ned+dm...@mrochek.com
> To: "John Levine"
> Cc: dmarc@ietf.org, superu...@gmail.com
> Sent: Friday, November 7, 2014 10:47:20 AM
> Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
>
>
> > For From: headers
- Original Message -
> From: ned+dm...@mrochek.com
> To: "John Levine"
> Cc: dmarc@ietf.org, superu...@gmail.com
> Sent: Friday, November 7, 2014 10:47:20 AM
> Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
>
> > >What sort of remedy
- Original Message -
> From: "Douglas Otis"
> To: "Franck Martin"
> Cc: "Ned Freed" , dmarc@ietf.org, "Murray S.
> Kucherawy" , "Douglas Otis"
>
> Sent: Saturday, November 8, 2014 11:58:00 PM
> Subject: Re: [dma
On Nov 8, 2014, at 5:29 PM, Franck Martin wrote:
>> No, I think you've got it, but I'm not clear on how the paragraph you cited
>> doesn't say that. You have it exactly right: If From: is missing or so
>> mangled that it's not possible to get a domain out, then there's nothing to
>> which DK
On 11/7/2014 10:47 AM, ned+dm...@mrochek.com wrote:
>>> > >1) Evaluate all the domains you find, and if any of them have published
>>> > >DMARC policies, apply the strictest one ...
...
> That's fine if any of the domains have an associated DMARC record - of any
> sort. My concern is the case where
> >What sort of remedy would you suggest here? Off the top of my head, here
> >are some suggestions:
> >
> >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 els
Printed on recycled paper!
> On Nov 8, 2014, at 15:00, Rolf E. Sonneveld
> wrote:
>
>> On 11/08/2014 09:20 PM, Brett McDowell wrote:
>> I support making no change in dmarc-base-05 that might change how current
>> mailbox providers implement dmarc-base. But to the extent this collection
>>
See inline
Printed on recycled paper!
> On Nov 6, 2014, at 23:16, Murray S. Kucherawy wrote:
>
>> On Thu, Nov 6, 2014 at 11:06 AM, Ned Freed wrote:
>> In the step 7 in section 3.1.3, I think it would be helpful to add a sentence
>> about the determination of the organizational domain from
>> I occasionally see non-ASCII octets introduced by spam/virus checkers in
>> X-Spam-* fields in the header or in the (non-8-bit) message body, due to
>> copying message content into those contexts. The From field is perfectly
>> valid, however. Does that really mean that identifier alignment ca
On 11/08/2014 09:20 PM, Brett McDowell wrote:
I support making no change in dmarc-base-05 that might change how
current mailbox providers implement dmarc-base. But to the extent
this collection of contributors would like to see the
recommendations/requirements in section 5.6.1 updated to bette
I support making no change in dmarc-base-05 that might change how current
mailbox providers implement dmarc-base. But to the extent this collection
of contributors would like to see the recommendations/requirements in
section 5.6.1 updated to better harmonize with related RFC's, I support
Trent's
On Fri, Nov 7, 2014 at 8:57 PM, 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 a malformed
> >
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 a malformed
> or absent RFC5322.From field.
> -
I occasionally
On 11/6/14 12:06 PM, ned+dm...@mrochek.com wrote:
>
>
> I have a few comments on the base specification.
>
> In section 3.1.4, the paragraph
>
>It is important to note that identifier alignment cannot occur with a
>message that is not valid per [MAIL], particularly one with a
>malf
That's fine if any of the domains have an associated DMARC record - of any
sort. My concern is the case where none of them do, or when there
are no domains present.
In that case I agree with you, it's none of DMARC's business what happens.
For From: headers with address-free groups, recall tha
On Nov 7, 2014, at 10:32 AM, Murray S. Kucherawy wrote:
> On Fri, Nov 7, 2014 at 10:06 AM, John Levine 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 an
On Fri, Nov 7, 2014 at 10:06 AM, John Levine 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 step, say
>What sort of remedy would you suggest here? Off the top of my head, here
>are some suggestions:
>
>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
On Thu, Nov 6, 2014 at 11:16 PM, Murray S. Kucherawy
wrote:
> I have no absolutely problem with rejecting messages with From: fields
>
>> containing any sort of domain identifier that has any sort of attached
>> DMARC
>> policy because of how that From: field is constructed. But intruding on
>> l
On Thu, Nov 6, 2014 at 11:06 AM, Ned Freed wrote:
> In the step 7 in section 3.1.3, I think it would be helpful to add a
> sentence
> about the determination of the organizational domain from the author
> domain.
> Step 7 is also pretty large; you might want to consider breaking it up into
> subs
Thanks, this gives me something to do on the plane ride on Saturday.
On Thu, Nov 6, 2014 at 11:06 AM, Ned Freed wrote:
>
>
> I have a few comments on the base specification.
>
> In the step 7 in section 3.1.3, I think it would be helpful to add a
> sentence
> about the determination of the orga
I have a few comments on the base specification.
In the step 7 in section 3.1.3, I think it would be helpful to add a sentence
about the determination of the organizational domain from the author domain.
Step 7 is also pretty large; you might want to consider breaking it up into
substeps or some
I also support the -06 changes as you have explained them Murray.
Add me to the list of people speaking in opposition to the proposal what
would change "authentication" to "authorization".
Brett McDowell | br...@brettmcdowell.com | @brettmcdowell | +1 (413)
404-5593
On Tue, Nov 4, 2014 at 9:05 P
Douglas Otis writes:
> Since SPF authorizes an often _shared_ outbound IP address,
Not on my host, not ever -- I only have one IP address, and it *is*
mine (at least until my employer takes it away from me, but I trust
them to tell me if and when they do). What's your problem with that?
> bee
Scott Kitterman
Sent: Wednesday, November 5, 2014 1:54 PM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base
On Wednesday, November 05, 2014 06:35:32 PM Terry Zink wrote:
> > Since SPF authorizes an often _shared_ outbound IP address, it has been
> > accurately describe
On Wednesday, November 05, 2014 06:35:32 PM Terry Zink 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 solely
> > on the
t
yet complete. But the way I described it is how it will work.
-- Terry
From: Murray S. Kucherawy [mailto:superu...@gmail.com]
Sent: Wednesday, November 5, 2014 12:51 PM
To: Terry Zink
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base
On Wed, Nov 5, 2014 at 10:35 A
On Nov 5, 2014, at 10:35 AM, Terry Zink 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 solely on the basis of
On Wed, Nov 5, 2014 at 10:35 AM, Terry Zink
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 solely on the basis of
Cc: dmarc@ietf.org; Murray S. Kucherawy; Douglas Otis
Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base
On Nov 3, 2014, at 9:04 PM, Stephen J. Turnbull wrote:
> Douglas Otis writes:
>
>> After all, DMARC permits the weakest authorization as a basis for
>> acceptance,
On Nov 3, 2014, at 9:04 PM, Stephen J. Turnbull wrote:
> Douglas Otis writes:
>
>> After all, DMARC permits the weakest authorization as a basis for
>> acceptance, so it would be misleading to describe DMARC results as
>> having been *authenticated*.
>
> Well, no, it isn't necessarily misleadi
Murray S. Kucherawy writes:
> Maybe I'm the only one, but I think that while the RFC4949
> definitions are fairly cut-and-dry when one talks about pure
> cryptography and authorization systems, they seem more murky when
> applied to the email space.
I think this is going to be true of the use
On Tue, Nov 4, 2014 at 3:48 PM, Murray S. Kucherawy
wrote:
> So if anyone feels comfortable making comments on whether or not such an
> -06 would be ready for publication (i.e., -05, which is public, plus the
> above changes), please say so on this list so the ISE can see them. Any
> other feedb
On Mon, Nov 3, 2014 at 9:04 PM, Stephen J. Turnbull
wrote:
>
> Well, no, it isn't necessarily misleading. According to RFC 4949,
> authentication = identification + verification, while authorization is
> a permission to do something. For example, in DKIM "d=" identifies
> the Signing Domain and
Douglas Otis writes:
> After all, DMARC permits the weakest authorization as a basis for
> acceptance, so it would be misleading to describe DMARC results as
> having been *authenticated*.
Well, no, it isn't necessarily misleading. According to RFC 4949,
authentication = identification + veri
On Sun, Nov 2, 2014 at 6:28 AM, Scott Kitterman
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
> > astonishment.
> Not q
On Nov 1, 2014, at 2:09 AM, Stephen J. Turnbull wrote:
> Douglas Otis writes:
>
>> As such, using the terms authenticates and authentication should
>> not be used when referring to DKIM or SPF results. Nothing is
>> being authenticated.
>
> I'm confused. The sending domain is being authentic
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
> astonishment.
Not quite. There was an actual DKIM working group that produced standards
Just noticed that I never replied to this:
On Fri, Aug 29, 2014 at 8:39 PM, Scott Kitterman
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 Record Format,
On Fri, Oct 31, 2014 at 4:45 PM, Douglas Otis wrote:
> Was:
>However, there has been
>no single widely accepted or publicly available mechanism to
>communicate domain-specific message authentication policies, or to
>request reporting of authentication and disposition of received m
Douglas Otis writes:
> As such, using the terms authenticates and authentication should
> not be used when referring to DKIM or SPF results. Nothing is
> being authenticated.
I'm confused. The sending domain is being authenticated, as well as
as much content as is signed (none for SPF, at le
https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/
Dear Murray,
Nice work as this is a great improvement.
The introduction properly states the function of DKIM or SPF is to detect and
block unauthorized email.
Neither DKIM nor SPF determines:
1) valid RFC5322 structure
2) intended m
Murray,
You've clearly put a lot of work into updating this document, and there
are a substantial number of changes. That means it deserves this
group's serious attention. You've given me my homework assignment, I
can say...
Eliot
On 10/29/14, 9:37 PM, Murray S. Kucherawy wrote:
> On Tue, Oct
On Tue, Oct 28, 2014 at 3:44 PM, Murray S. Kucherawy
wrote:
> Since we're past the I-D deadline, the ISE or Pete will have to approve
> its addition to the datatracker, so it will magically appear at some point
> soon, and then move forward in the publication process.
>
It's now available in the
On Tue, Oct 28, 2014 at 4:09 PM, Brett McDowell
wrote:
> Thanks Murray. That was a really important step. You continue to carry
> the bulk of the email security standardization load on your shoulders, and
> it is greatly appreciated!
>
Hi Brett,
Thanks for your support.
I was going to say "I
Thanks Murray. That was a really important step. You continue to carry
the bulk of the email security standardization load on your shoulders, and
it is greatly appreciated!
Cheers,
-Brett
On Tue, Oct 28, 2014 at 6:44 PM, Murray S. Kucherawy
wrote:
> Colleagues,
>
> With apologies once again
On 8/30/14 4:17 PM, Franck Martin wrote:
On Aug 30, 2014, at 7:12 AM, Tim Draegen wrote:
On Aug 29, 2014, at 11:39 PM, Scott Kitterman 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 ...
Rig
Dave Crocker writes:
> That is, perhaps start by asking the question on:
>
>http://www.dmarc.org/mailman/listinfo/dmarc-discuss
Last I heard that list was deprecated in favor of this one. It
certainly has been mostly inactive for quite a long time.
Murray? Franck?
On Aug 30, 2014, at 7:12 AM, Tim Draegen wrote:
> On Aug 29, 2014, at 11:39 PM, Scott Kitterman 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 ...
>
> Right list. Just to set precedent, any thoughts on
On 8/30/2014 7:12 AM, Tim Draegen wrote:
> On Aug 29, 2014, at 11:39 PM, Scott Kitterman 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 ...
>
> Right list.
...
While this might be a reasonable list for
On Saturday, August 30, 2014 10:12:32 Tim Draegen wrote:
> On Aug 29, 2014, at 11:39 PM, Scott Kitterman 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 ...
>
> Right list. Just to set precedent, any t
On Aug 29, 2014, at 11:39 PM, Scott Kitterman 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 ...
Right list. Just to set precedent, any thoughts on this issue will be captured
in the WG's issue tracker. On
81 matches
Mail list logo
