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
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
On Mon, Nov 10, 2014 at 6:50 PM, Brandon Long bl...@google.com 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
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
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:
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
to
Printed on recycled paper!
On Nov 9, 2014, at 23:22, Stephen J. Turnbull step...@xemacs.org 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
[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, turnb...@sk.tsukuba.ac.jp wrote:
Trent Adams writes:
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 the
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 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
- Original Message -
From: Stephen J. Turnbull step...@xemacs.org
To: Franck Martin fra...@peachymango.org
Cc: Brett McDowell brettmcdow...@gmail.com, dmarc@ietf.org, Scott
Kitterman skl...@kitterman.com
Sent: Monday, November 10, 2014 11:05:23 AM
Subject: Re: [dmarc-ietf] draft
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
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
Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
On Nov 8, 2014, at 5:29 PM, Franck Martin fra...@peachymango.org 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
- Original Message -
From: ned+dm...@mrochek.com
To: John Levine jo...@taugh.com
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 would you suggest here? Off
- Original Message -
From: ned+dm...@mrochek.com
To: John Levine jo...@taugh.com
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
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 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
On Nov 8, 2014, at 8:38 PM, Franck Martin fra...@peachymango.org 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
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
On November 9, 2014 4:31:31 AM EST, Franck Martin fra...@peachymango.org
wrote:
- Original Message -
From: ned+dm...@mrochek.com
To: John Levine jo...@taugh.com
Cc: dmarc@ietf.org, superu...@gmail.com
Sent: Friday, November 7, 2014 10:47:20 AM
Subject: Re: [dmarc-ietf] draft
@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
motivation
for this was EAI downgrades at delivery time. The un-downgraded
message had a normal From
On 11/09/2014 04:03 PM, Tim Draegen wrote:
On Nov 8, 2014, at 8:38 PM, Franck Martin fra...@peachymango.org 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
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
Printed on recycled paper!
On Nov 9, 2014, at 10:27, Rolf E. Sonneveld r.e.sonnev...@sonnection.nl
wrote:
On 11/09/2014 04:03 PM, Tim Draegen wrote:
On Nov 8, 2014, at 8:38 PM, Franck Martin fra...@peachymango.org wrote:
There are no secret sauces. I thought it was clear this type of
On Sun, Nov 9, 2014 at 2:58 PM, Scott Kitterman skl...@kitterman.com
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
- Original Message -
From: Brett McDowell brettmcdow...@gmail.com
To: Scott Kitterman skl...@kitterman.com
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 Kitterman
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 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
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 cannot
Printed on recycled paper!
On Nov 8, 2014, at 15:00, Rolf E. Sonneveld r.e.sonnev...@sonnection.nl
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
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 none of
On Nov 8, 2014, at 5:29 PM, Franck Martin fra...@peachymango.org 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
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 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
On Nov 7, 2014, at 10:32 AM, Murray S. Kucherawy superu...@gmail.com wrote:
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
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
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
On Nov 3, 2014, at 9:04 PM, Stephen J. Turnbull step...@xemacs.org 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
] draft-kucherawy-dmarc-base
On Nov 3, 2014, at 9:04 PM, Stephen J. Turnbull step...@xemacs.org 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
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
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 basis
On Tue, Nov 4, 2014 at 3:48 PM, Murray S. Kucherawy superu...@gmail.com
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.
Murray S. Kucherawy writes:
I have only two changes pending for an -06 based on the feedback I've
received and an observation of my own, namely:
1) Several editorial changes that don't alter the meaning of the technical
work at all; and
I'm happy with the editorial state of the
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
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 +
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
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
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
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
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
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 superu...@gmail.com
wrote:
Colleagues,
With
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
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 29, 2014, at 11: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 ...
Right list. Just to set precedent, any thoughts on this issue will be captured
in the WG's
On 8/30/2014 7:12 AM, Tim Draegen wrote:
On Aug 29, 2014, at 11: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 ...
Right list.
...
While this might be a
On Aug 30, 2014, at 7:12 AM, Tim Draegen t...@eudaemon.net wrote:
On Aug 29, 2014, at 11: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 ...
Right list. Just to
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, allows both
values of 0 and 1 to be specified. It was suggested to me offlist that
this
might not be
58 matches
Mail list logo
