On Mon, Jul 20, 2020 at 1:59 AM Laura Atkins
wrote:
> There was a research project done by an inbox provider and a major
> supporter of DMARC presented at a MAAWG meeting a few years ago. They tried
> adding trust indicators to the message list but found no statistically
> significant behavioral
On Mon, Jul 20, 2020 at 1:42 AM Alessandro Vesely wrote:
> On Sun 19/Jul/2020 20:13:46 +0200 Murray S. Kucherawy wrote:
> > On Sun, Jul 19, 2020 at 3:14 AM Alessandro Vesely
> wrote:
> >
> >>> Still unresolved, IMHO, is Dave's point about whether the RFC5322.F
On Sun, Jul 19, 2020 at 11:33 AM Dave Crocker wrote:
> On 7/19/2020 11:08 AM, Murray S. Kucherawy wrote:
>
> gain: There is quite a bit of experience demonstrating that providing
>> trust indicators to end users does not produce reliable -- ie, useful --
>> decision-making
On Sun, Jul 19, 2020 at 3:14 AM Alessandro Vesely wrote:
> > Still unresolved, IMHO, is Dave's point about whether the RFC5322.From
> > domain truly matters.
>
> While the opinions of big players are relevant, you yourself mentioned
> that
> they tend to follow DMARC design.
Sorry, I said
On Sun, Jul 19, 2020 at 5:40 AM Dave Crocker wrote:
> On 7/18/2020 5:16 PM, Murray S. Kucherawy wrote:
> > At some point in the past, Gmail decided to show the email address
> > only unless that address was in the recipient's contact list,
>
>
> btw, I just logged in
On Sun, Jul 19, 2020 at 8:04 AM Dave Crocker wrote:
> On 7/18/2020 9:23 PM, Murray S. Kucherawy wrote:
>
> On Sat, Jul 18, 2020 at 6:32 PM Dave Crocker wrote:
>
>> If end users do not reliably make trust decisions based on /any/ of the
>> information in the rfc5
On Sat, Jul 18, 2020 at 6:32 PM Dave Crocker wrote:
> If end users do not reliably make trust decisions based on /any/ of the
> information in the rfc5322.From field, then how is this question
> important. It seems to be seeking precise data about something that
> isn't even secondary.
>
Brandon Long, if you're watching:
On Fri, Jul 17, 2020 at 2:01 PM Dave Crocker on behalf of Kurt Andersen <
jo...@taugh.com> wrote:
> In article you write:
> >> I'd counter by personal anecdote that we have had to undertake
> >> security remediations because of messages which were forwarded by
On Sat, Jul 18, 2020 at 10:17 AM Jim Fenton wrote:
> Yes, the issues of cousin domains, homoglyphs, etc. are thrown out there
> as reasons why DMARC is "irrelevant" to solving problems such as spam or
> phishing. It doesn't solve spam but it does have an impact on phishing, if
> only to push the
On Wed, Jul 8, 2020 at 1:08 PM Dotzero wrote:
>
> That seems to imply DKIM, which relies on DNS and cryptography, is LESS
>> heavyweight than reversing text transformations, which relies only on the
>> local CPU and memory and probably arithmetic. I'm not sure I agree.
>>
>
> Once you reverse
I'm sorry, I got that backwards. What I meant to say is:
On Wed, Jul 8, 2020 at 9:04 AM Murray S. Kucherawy
wrote:
> On Wed, Jul 8, 2020 at 1:21 AM Dotzero wrote:
>
>> At what overhead cost? You have to hold the connection open while
>> reversing the tran
On Wed, Jul 8, 2020 at 1:21 AM Dotzero wrote:
> At what overhead cost? You have to hold the connection open while
> reversing the transformations or you are not in a position to reject (vs
> accepting then rejecting). There are folks currently holding the connection
> while evaluating the DKIM
On Mon, Jul 6, 2020 at 10:12 AM Dave Crocker wrote:
> Perhaps, like some others, I'm not understanding this correctly, but I
> think the proposal has nothing at all to do with what the recipient sees.
> Rather, I've understood this as an attempt to reverse additions made by a
> Mediator, with
On Mon, Jul 6, 2020 at 11:18 AM John Levine wrote:
> In article you write:
> >
> >It occurs to me that discussion about how this latest proposal might or
> >might not have similarities to ARC should encourage everyone making a
> >proposal to add commentary that gives a full sense of end-to-end
On Mon, Jul 6, 2020 at 8:43 AM Doug Foster
wrote:
> · Mailing list M sends a message to User A with a request to
> ensure that the inbound gateway will accepts its message. The message
> contains attachments needed to define and justify the request.I
> envision an XML attachment
On Mon, Jul 6, 2020 at 7:31 AM John R Levine wrote:
> > That isn't a new attack though, given spammers sign their email already.
> > This way you have (in theory) two good signatures: one from the author
> for
> > the "safe" form of the message, and one for the spam that got bolted on,
> > and
On Mon, Jul 6, 2020 at 1:49 AM Alessandro Vesely wrote:
> For multipart messages, transformations may need to replace boundaries.
> In
> that case, the "restricted patch" to undo the transformation may require
> more
> data than it is convenient to store in a DKIM tag.
>
Replace why? It might
On Sun, Jul 5, 2020 at 9:51 PM Jim Fenton wrote:
> That was basically the argument against the l= parameter in DKIM
> signatures. We did end up keeping l= because it only has effect if the
> signer uses it and the verifier accepts its use, although it was widely
> expected that it would not be
On Sun, Jul 5, 2020 at 7:42 PM John Levine wrote:
> I wrote the Sympa ARC code which is entwined with the DKIM code so
> that would probably be me. Honestly, this looks like a lot more work
> than ARC to get a result likely to be worse in practice than ARC.
>
Interesting; I had the opposite
On Sun, Jul 5, 2020 at 8:35 PM Hector Santos wrote:
> 1) Curious, are these Mail List Server (MLS) developers active
> participants of the WG list? Lurkers? Was there a consideration to
> include a MLS developer participant that is active in the WG? I'm sure
> you are aware SSI (Santronics
On Sun, Jul 5, 2020 at 3:48 PM Jeremy Harris wrote:
> On 05/07/2020 23:39, Murray S. Kucherawy wrote:
> > Any opinion on the whole thing generally?
>
> Certainly worthy of discussion. I wonder if it needs tying
> to ARC rather than, or in addition to DKIM?
>
I think it so
On Sun, Jul 5, 2020 at 3:31 PM Jeremy Harris wrote:
> On 05/07/2020 22:56, Murray S. Kucherawy wrote:
> > https://tools.ietf.org/html/draft-kucherawy-dkim-transform-01
>
> Substansive:
>
> section 6, on footers:
> - Is not a common boundary marker a signature-marker, name
-- Forwarded message -
From:
Date: Sun, Jul 5, 2020 at 2:46 PM
Subject: New Version Notification for draft-kucherawy-dkim-transform-01.txt
To: Murray S. Kucherawy
A new version of I-D, draft-kucherawy-dkim-transform-01.txt
has been successfully submitted by Murray Kucherawy and posted
Emphatically hatless:
On Fri, Jun 26, 2020 at 4:42 AM Douglas E. Foster <
fost...@bayviewphysicians.com> wrote:
> Two weeks ago, John Levine reminded us that DMARC v1 was already deployed
> and this effort was to perfect the wording. Suddenly, we have a small but
> powerful group insisting
On Tue, Jun 23, 2020 at 4:08 PM Douglas E. Foster
wrote:
> A few issues remain:
>
> How does the incoming filter prove that the message is really from the list,
> rather than someone spoofing the list? Since the RFC5321 M and the
Was there supposed to be more to this line?
-MSK
On Sun, Jun 21, 2020 at 6:07 PM John Levine wrote:
> In article
> you
> write:
> >Apart from Mailman, what would be a reasonable set of MLMs to
> >approach? I don't need a universal set here, just enough to get us to
> >at least what we are pretty sure would be 80% or better of the active
>
On Sat, Jun 20, 2020 at 1:24 PM Dave Crocker wrote:
> Perhaps if the effort were viewed as a staged sequence, over an extended
> time. Staging along the lines of:
>
> Document a modest number of highly common 'patterns' of mailing list patterns.
> * Get reasonable community support (rough
On Fri, Jun 19, 2020 at 5:54 PM Dave Crocker wrote:
> > I wish in hindsight I'd tried it
> > anyway as an experiment, with maybe a couple of senders, receivers,
> > and mailing lists as participants.
>
> While I can imagine devising something that would look appealing, I
> believe it would have
On Fri, Jun 19, 2020 at 5:09 PM John Levine wrote:
> >There's a chance that it is possible to specify a small range of
> >modifications and arrange a style of signing that could survive them.
> >So for originating and mediating sites that conform to that range, a
> >'preserved' original
On Thu, Jun 18, 2020 at 3:24 PM Jim Fenton wrote:
> We need to consider not just what's a useful correlation today, but what
> will continue to be so. As soon as the {spammers, phishers, etc.} catch
> on that they can achieve alignment at will, it will cease to be a useful
> correlation. History
On Sun, Jun 14, 2020 at 7:09 AM wrote:
> Thanks for you honesty. Then the relevant question is whether open and
> interoperable standards still matter, or if they should be replaced by
> proprietary web apps one feature at a time.
Both have been around for a long time now and I've seen no
On Fri, Jun 12, 2020 at 5:02 PM Jim Fenton wrote:
> About a year ago, I had suggested [1] that the reporting and policy
> mechanisms of DMARC be split, and was, I think, the only one supporting
> that idea. There were quite a few comments along the line of, "it's not
> broken, so why should we go
On Sun, Jun 7, 2020 at 11:04 PM Douglas E. Foster <
fost...@bayviewphysicians.com> wrote:
> Stan Kalisch asks: And you propose the average user can understand, much
> less take the time to understand, the substance?
>
> Yes. I believe users are worried about spam, and want to make
>
On Sun, Jun 7, 2020 at 6:58 AM Douglas E. Foster <
fost...@bayviewphysicians.com> wrote:
> 1) The original assertion, that DMARC creates a conflict with prior
> specifications, appears to be undefended and incorrect. For From
> Addressing, It merely establishes some boundaries that the sender
On Tue, Jun 2, 2020 at 11:01 AM Dave Crocker wrote:
> Your comment implies that what is displayed to the user is important in
> anti-abuse efforts, but there is no data to support that view, and some
> significant data to support the view that that's wrong. (cf, the
> extensive literature
On Fri, May 15, 2020 at 1:16 PM Scott Kitterman
wrote:
> If this were a green field effort and we were trying to decide on a report
> format, I would probably think JSON was a great choice, but it's not.
> Trying
> to support multiple formats is going to be a lot of work for little to no
> real
On Fri, May 15, 2020 at 11:27 AM Seth Blank wrote:
> https://trac.ietf.org/trac/dmarc/ticket/49
>
> The penultimate paragraph of
> https://tools.ietf.org/html/rfc7489#section-6.3 states:
>
> the "v" and "p" tags MUST be present and MUST
>appear in that order.
>
> While the v= tag pretty
Apologies:
On Wed, Apr 15, 2020 at 8:39 PM Murray S. Kucherawy
wrote:
> +1. If even a small number of people (and the GenART review itself might
> be enough) thinks it's in need of this kind of improvement, I would be
> surprised if the IESG sends it back to the working group for
On Wed, Apr 15, 2020 at 8:31 PM Seth Blank wrote:
> On Wed, Apr 15, 2020 at 7:45 PM Scott Kitterman
> wrote:
>
>> > I think you are very close to an Abstract/Introduction that is clearly
>> > comprehensible to people who are not familiar with DMARC.
>>
>> Considering this is an extension to
(Reducing Ccs)
That seems like it paints a much clearer picture, which is what Dale was
after. A great start!
On Thu, Apr 9, 2020 at 12:54 PM Todd Herr wrote:
> Having reviewed the comments, I'm wondering if perhaps the following draft
> rewrite of the Abstract section might be a first step
On the process questions raised:
On Wed, Apr 1, 2020 at 12:06 AM Qin Wu via Datatracker
wrote:
> Minor issue:
> This document provide two registries, one is update of DMARC Tag Registry
> with
> one new element, requested from IANA, the other is DMARC PSD registry
> maintained by [psddmarc.org]
On Mon, Mar 30, 2020 at 4:21 PM John R Levine wrote:
> > Does someone have a fix in mind that could be submitted as an erratum?
> The
> > intent was indeed to make the authserv-id either a plain old ASCII domain
> > name or an A-label which doesn't need quoting. I missed that RFC 6532
> >
On Mon, Mar 30, 2020 at 2:23 PM John Levine wrote:
> In article <
> caba8r6ttpateyprsgbwkafzvz4u8v8sn1vptpmlqcia2_+5...@mail.gmail.com> you
> write:
> >-=-=-=-=-=-
> >
> >Hmm, we didn't include this in RFC 8616 either, I could imagine that it
> >should be punycoded also, though it really depends
On Wed, Mar 18, 2020 at 6:17 PM John Levine wrote:
> >The issue PSD is attempting to address is mail sent as a nonexistent
> >subdomain. For example, irs.gov doesn't have a subdomain called
> >auditors.irs.gov, so irrespective of any irs.gov DMARC policy, I could
> send
> >email as
On Sun, Mar 15, 2020 at 5:49 AM Dave Crocker wrote:
> On 3/11/2020 8:36 PM, Murray S. Kucherawy wrote:
>
> Since we're mentioning a tree walk here, I believe we are ripe for a
> reopening of that debate.
>
> That's a shame. Besides created additional general cost, it creates
As we're in AD Review now, I'll let Alexey decide.
On Wed, Mar 11, 2020 at 7:05 PM Scott Kitterman
wrote:
> If the chairs are up for it, I'd like to publish a revision to the draft
> that
> fixes the typo mentioned on the list two weeks ago and adds mil to the
> list of
> participating PSDs
On Fri, Feb 7, 2020 at 10:22 AM Murray S. Kucherawy
wrote:
> We have some personnel changes to announce. First, we would like to thank
> Tim Wicinski for stepping in to co-chair DMARC with me. Going forward he
> will be focusing on his duties with DNSOP and other IETF work and
On Sat, Mar 7, 2020 at 3:49 AM Alessandro Vesely wrote:
> On Sat 07/Mar/2020 05:49:42 +0100 Tim Wicinski via Datatracker wrote:
> > Tim Wicinski has requested publication of draft-ietf-dmarc-psd-07 as
> Experimental on behalf of the DMARC working group.
> >
> > Please verify the document's state
On Sat, Feb 29, 2020 at 3:43 PM Scott Kitterman
wrote:
> I think the only thing that might be missing is explicitly importing the
> term
> organizational domain from RFC 7489. I think it wouldn't hurt to add it,
> but
> I don't think it's needed. As early as the second sentence of the
>
ix" is
> https://tools.ietf.org/html/rfc8499#page-28
>
> Which could assist in the Public Suffix Domain definition here.
> If this makes sense, I can offer some suggested text
>
> On Sat, Feb 29, 2020 at 2:06 PM Murray S. Kucherawy
> wrote:
>
>> It occurs to me o
gt; is typically in charge of document shepherding/judging consensus.
>
> Best Regards,
> Alexey
>
> > Thanks
> >
> > --
> > HLS
> >
> > On 2/7/2020 1:22 PM, Murray S. Kucherawy wrote:
> > > Colleagues,
> > >
> > > We have so
It occurs to me on review that this draft refers to Organizational Domain,
and probably some other terms, without defining them or expressly importing
them from RFC7489. In particular Section 2.3 refers to the OD with no
prior definition.
Maybe: Insert a new Section 2.2 (pushing others down)
You could email the author(s) directly.
On Fri, Feb 28, 2020 at 12:57 AM Martijn van der Lee wrote:
> Chapter 5 of the current draft contains a typo in the word “sucessful”
> (sic).
>
>
>
> p.s. Is there any other way of reporting such inconsequential issues other
> than bothering the entire
On Wed, Feb 5, 2020 at 3:02 AM Craig Schwartz wrote:
> First, while I know you've said the needs of external actors won't weigh
> on your decision about moving forward, I would like to mention that
> having a stable reference for PSD DMARC will help us with working towards
> policy changes that
On Thu, Feb 6, 2020 at 10:44 AM Alessandro Vesely wrote:
> +1, albeit I don't think DMARCbis arrives so quickly
>
I don't actually think there's much stopping us from beginning the work on
DMARCbis now. Seth has dutifully been collecting those and putting them in
the group's tracker for a
Colleagues,
We have some personnel changes to announce. First, we would like to thank
Tim Wicinski for stepping in to co-chair DMARC with me. Going forward he
will be focusing on his duties with DNSOP and other IETF work and is still,
of course, welcome to participate here. For the next couple
On Tue, Feb 4, 2020 at 1:44 PM Dotzero wrote:
> On Tue, Feb 4, 2020 at 4:26 PM Murray S. Kucherawy
> wrote:
>
>>
>>
>> I think what Dave proposed about PSL separation from DMARC is entirely
>> appropriate and pragmatic, and in fact probably easy enough: DM
On Tue, Feb 4, 2020 at 1:20 PM Scott Kitterman wrote:
> I agree on DMARCbis. I don't think advancing this draft has a significant
> effect on that. Worst case, if DMARCbis is done before we can reach any
> conclusions about PSD DMARC, then we publish DMARCbis without PSD DMARC in
> it.
>
I
On Tue, Feb 4, 2020 at 12:25 PM Dotzero wrote:
> I am not against experiments, but having reread the entire thread starting
> from Dave's post in August, I believe his concerns are valid.
>
I want to say again that I make no assertion that any of Dave's claims are
invalid. The main thing I
On Mon, Feb 3, 2020 at 4:24 PM Craig Schwartz wrote:
> Hi Murray,
>
> << of needing this work but not knowing how to engage; you either give your
> feedback on the list or privately to the chairs or Area Directors, or you
> are along for whatever ride results. Please indicate, as soon as
Dave,
On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker wrote:
> Nothing I've worked on at the IETF with such a label is something I would
> necessarily stand behind as Internet-scalable.
>
> Such as?
>
RFC 6541 comes to mind. To the best of my knowledge, it's an experiment
that never even ran.
On Mon, Dec 9, 2019 at 8:44 AM Dave Crocker wrote:
> The IETF does not typically -- or, as far as I recall, ever -- promote
> specifications known not to scale. (While I think of this concern as
> foundational to the IETF, it's a bit odd that nothing like it is
included in the IETF's "Mission
On Mon, Nov 11, 2019 at 2:21 PM Dave Crocker wrote:
>
> * add text to the PSD draft making it clear that what it's describing is
> an experiment whose outcome will be taken only as feedback to the revision
> of the standard (i.e., this is not intended to be the final form of
> anything), and it
On Mon, Nov 18, 2019 at 7:49 AM Дилян Палаузов
wrote:
> who is going to work on DMARCbis document and is it realistic to finish it
> with a year?
>
Are you volunteering too?
-MSK
___
dmarc mailing list
dmarc@ietf.org
On Mon, Nov 18, 2019 at 7:49 AM Дилян Палаузов
wrote:
> who is going to work on DMARCbis document and is it realistic to finish it
> with a year?
>
We haven't started the process of selecting editor(s) for it, but if anyone
wants to volunteer, please do.
-MSK
On Mon, Nov 11, 2019 at 2:21 PM Dave Crocker wrote:
> On 11/10/2019 11:34 PM, Murray S. Kucherawy wrote:
>
> * add text to the PSD draft making it clear that what it's describing is
> an experiment whose outcome will be taken only as feedback to the revision
> of th
On Mon, Nov 11, 2019 at 1:23 AM Alessandro Vesely wrote:
> >> That's not what the RFC Editor erratum system is for. The document
> >> reflects what the WG intended to publish at the time, so this isn't an
> >> erratum, it's a new change to the specification.
>
> Yes, as DE you could change it
On Mon, Nov 11, 2019 at 7:54 AM John Levine wrote:
> In article dx...@mail.gmail.com> you write:
> >Just to be clear: The policy for changes to that registry is "Expert
> >Review", but since the action that put it there was a document with IETF
> >consensus, I'm pretty hesitant about just
On Sun, Nov 10, 2019 at 10:30 PM Murray S. Kucherawy
wrote:
> On Mon, Oct 21, 2019 at 7:54 AM Alessandro Vesely wrote:
>
>> On Wed 07/Aug/2019 17:16:29 +0200 Murray S. Kucherawy wrote:
>> >
>> >> If the definition of ptype smtp were "a parameter of t
On Thu, Sep 5, 2019 at 1:22 PM Dave Crocker wrote:
> > 1. The change to DMARC should be limited to permitting the query for the
> > organization domain to be anywhere in the DNS tree, including a TLD.
> > Within DMARC this would not look like 'extra' mechanism.
> >
> > 2. The mechanism that
On Mon, Oct 21, 2019 at 7:54 AM Alessandro Vesely wrote:
> On Wed 07/Aug/2019 17:16:29 +0200 Murray S. Kucherawy wrote:
> >
> >> If the definition of ptype smtp were "a parameter of the SMTP session
> used
> >> to relay the message" it would be p
On Tue, Aug 13, 2019 at 7:02 PM Dave Crocker wrote:
> Review of:DMARC (Domain-based Message Authentication, Reporting, and
>Conformance) Extension For PSDs (Public Suffix Domains)
> I-D: draft-ietf-dmarc-psd-06
> Reviewer: D. Crocker
> Review Date: 12 August
On Wed, Aug 7, 2019 at 6:46 AM Freddie Leeman wrote:
> I've been digging through the DMARC pre-IETF drafts and IETF drafts and
> came to the following conclusion:
>
Seems to me the working group has a choice to make here, somewhere between
"reinforce the XML specification as published" and
On Sat, Aug 3, 2019 at 8:40 AM Alessandro Vesely wrote:
> That's much better. If the definition of ptype smtp were "a parameter of
> the
> SMTP session used to relay the message" it would be perfect. I'd propose
> that
> policy.iprev be deprecated and smtp.remote-ip used instead.
>
Given that
On Sat, Aug 3, 2019 at 8:28 AM Alessandro Vesely wrote:
> IOW, dnswl=pass means the sender was whitelisted.
>
If that's the case, why do downstream agents need "policy.ip" at all?
-MSK
___
dmarc mailing list
dmarc@ietf.org
On Sat, Aug 3, 2019 at 12:02 AM Scott Kitterman
wrote:
> Policy is an indication of sender preference, not a directive the receiver
> must follow. I think the definition is fine. If the sender prefers
> failing messages be quarantined, then they should use that policy. They
> won't get what
er and receiver disagree, as a light substitute to
> the failure reports.
>
> Greetings
> Дилян
>
>
> On Fri, 2019-08-02 at 13:01 -0700, Murray S. Kucherawy wrote:
> > On Fri, Aug 2, 2019 at 10:52 AM Дилян Палаузов <
> dilyan.palau...@aegee.org> wrote:
> >
On Fri, Aug 2, 2019 at 10:52 AM Дилян Палаузов
wrote:
> I mean an enhanced status code, as at
>
> https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml
> .
>
RFC7372 registered some for exactly this purpose (though not specific to
DMARC). Its Security
On Fri, Aug 2, 2019 at 3:00 AM Alessandro Vesely wrote:
> Let me note that Section 3 of rfc8601, /The "iprev" Authentication Method/,
> does not contain the term "policy".
>
Wow. I'm amazed I got away with that.
But it is clear from the things in the registry that that's how you do it.
My
On Thu, Aug 1, 2019 at 9:32 AM Alessandro Vesely wrote:
> Let me narrate a use case. Courier-MTA can be configured to reject on SPF
> -all
> early in the SMTP dialogue, except if whitelisted. It writes SPF as well
> as
> dnswl results in the header, but does not interpret the policy.ip.
>
On Wed, Jul 31, 2019 at 9:40 PM Scott Kitterman
wrote:
> Can we discuss this choice? I know this has been implemented already, so
> I'm
> at least slightly reluctant to do the semi-standard lets rename existing
> stuff
> dance that the IETF often does, but I really don't like this. There isn't
On Wed, Jul 31, 2019 at 7:58 AM Freddie Leeman wrote:
> 0: Generate a DMARC aggregate report for every message, regardless of its
> alignment.
>
1: Generate a DMARC aggregate report if any underlying authentication
> mechanism produced something other than an aligned "pass" result.
>
> d:
On Mon, Jul 29, 2019 at 12:38 PM Scott Kitterman
wrote:
> I'd like to add the option to record DMARC results in an A-R header field
> for
> consumption by a downstream processor. I think it would be something like
> this:
>
> Authentication-Results: mail-router.example.net; dmarc=pass
>
On Tue, Jul 30, 2019 at 7:29 AM Дилян Палаузов
wrote:
> if policy quarantine will be kept, I propose including this text in the
> specification:
>
> Messages, subject to the quarantine policy, directed to a single recipient
> that does not support the concept of
> quarantining, can be either
On Sun, Jul 28, 2019 at 6:37 AM Tim Wicinski wrote:
> From our end user point of view, I'm against abolishing quarantine, even
> with its current shortcomings.
>
Why's that?
-MSK, also hatless
___
dmarc mailing list
dmarc@ietf.org
Thanks for this, much better. Some additional feedback.
Please note (everyone) that I'm offering these as clarifying contributions
to text; I'm not prescribing or proscribing anything. If the text I'm
proposing isn't worthy of consensus, please speak up.
On Sat, Jul 27, 2019 at 1:45 PM Scott
On Wed, Jul 24, 2019 at 4:45 PM Steve Atkins
wrote:
> > It's interesting that the industry has decided to interpret "p=reject;
> pct=0" the way we intended "p=quarantine; pct=100".
>
> It's semi-explicitly defined that way in the RFC, isn't it?
>
If so, we should fix it because (a) I don't
OK, I see what you're getting at.
It's interesting that the industry has decided to interpret "p=reject;
pct=0" the way we intended "p=quarantine; pct=100".
As for your proposal:
On Wed, Jul 24, 2019 at 12:52 PM Дилян Палаузов
wrote:
> And then, for p=none or any equivalent form of it, there
On Fri, Jun 14, 2019 at 12:25 PM Vladimir Dubrovin wrote:
> Nope, I mean 2 different things.
>
> 1. Why quarantine is useful (with pct=0).
>
> For example this mailing list (dmarc@ietf.org) performs From rewrite (aka
> From munging), e.g. dubro...@corp.mail.ru is replaced with
>
One (hopefully) last thing:
On Mon, Jul 22, 2019 at 9:23 AM Murray S. Kucherawy
wrote:
>
> 3.4. Section 6.6.3. Policy Discovery
>
>A new step between step 3 and 4 is added:
>
>3A. If the set is now empty and the longest PSD (Section 2.3) of the
> Organiz
Sorry, I hit "send" when I didn't mean to. Finishing up:
On Mon, Jul 22, 2019 at 9:23 AM Murray S. Kucherawy
wrote:
>
>o Multi-organization PSDs that require DMARC usage (e.g., ".bank"):
> PSD DMARC based reports will only be generated for domains that d
Reviewing as the document shepherd:
Abstract
[...]
organization can use to improve mail handling. DMARC policies can be
applied at the individual domain level or for a set of domains at the
organizational level.
I think the abstract is a bit too abstract. Which set of domains?
On Thu, Jul 11, 2019 at 5:54 PM John Levine wrote:
> In article <3a6e6f9ac98c4e60af1075760efde...@verisign.com> you write:
> >> I don't plan any changes except for those in response to last call
> comments.
> >> Unless I get direction otherwise, I don't plan any updates until after
> last call
This message begins Working Group Last Call for draft-ietf-dmarc-psd, which
is currently at version 04. An 05 may appear shortly with some text
changes that were previously discussed on the list; these do not include
any technical changes (I believe) so the author is free to update with only
On Mon, Jun 10, 2019 at 3:31 PM Scott Kitterman
wrote:
> > >On Thursday, June 6, 2019 at 1:12 PM EDT Scott Hollenbeck wrote:
> > >I recently had a chance to read through draft-ietf-dmarc-psd. If I
> > >understand it correctly (and I'm not sure that I do), the document
> > >suggests that it's
On Tue, Jun 4, 2019 at 4:01 AM Alessandro Vesely wrote:
> Appendix D1 of rfc7208 mentions DNSWL as a way to mitigate SPF's
> reject-on-fail. The score attributed to the sender by a trusted DNSWL is
> also
> useful after DATA, thence the need to store that value for downstream
> filters.
>
>
Just came in to start WGLC and saw this. If you have the momentum to do an
update now (like today), feel free. Otherwise I'll kick off WGLC shortly.
On Mon, Jun 10, 2019 at 3:26 PM Scott Kitterman
wrote:
> On Tuesday, June 4, 2019 6:37:47 PM EDT Tim Draegen wrote:
> > > On May 27, 2019, at
On Fri, May 31, 2019 at 10:55 AM Dilyan Palauzov
wrote:
> Shall I submit an erratum to RFC7489?
>
I would, yes. And this should certainly be recorded as something we need
to fix for standards track DMARC, whether by chasing down RFC7489 errata or
via a dedicated issue in this WG's tracker.
On Sun, May 26, 2019 at 7:49 AM John Levine wrote:
> In article <54fb29a0-517a-430e-af5b-cb079cc3d...@aegee.org> you write:
> >-=-=-=-=-=-
> >
> >Hello Douglas,
> >
> >1) Check the Authentication-Results header. An implementation could put
> there additional information as comment. A
>
On Wed, May 29, 2019 at 10:13 AM John R Levine wrote:
> As far as I can tell your proposal to break the document in two has
> gotten no support at all. Can we stop now?
>
What's on topic for the group and what isn't is the purview of the
co-chairs and the charter. Let's please not stifle
401 - 500 of 838 matches
Mail list logo
