Yes, I will participate and the proposed timing is fine.
--Kurt Andersen
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On Thu, Apr 8, 2021 at 5:02 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
>
> "IETF is interested in attacks of the form
> 'otherdomain.nonexistentdomain.psd', but IETF is not interested in attacks
> of the form 'nonexistentdomain.otherdomain.psd'.
>
I don't understand your
On Wed, Mar 24, 2021 at 3:25 PM Charles Gregory
wrote:
>
> Has anyone considered an option to add "affiliated domains" to a DNS
> entry? That way at least you could specify legitimate alternate/authorized
> domains that could still pass DMARC.
>
Yes, but no technically and operationally sound
On Wed, Mar 24, 2021 at 1:21 PM John Levine wrote:
> It appears that Gren Elliot said:
> >For better or worse, there is long established practice in the
> Calendaring community when implementing iMIP (rfc6047) when an
> >assistant is working on behalf of a manager for the manager’s email
>
On Sun, Mar 21, 2021 at 3:04 PM Tim Wicinski wrote:
>
> In Section 1.1 "Example"
>
> OLD
>
>Defensively registering all variants of "tax" is obviously not a
>scalable strategy. The intent of this specification, therefore, is
>to enhance the DMARC algorithm by enabling an agent
Good work on the updated phrasing, I'd make just a couple of changes to the
"tax" suggestion:
On Fri, Mar 19, 2021 at 9:28 AM Alessandro Vesely wrote:
>
> *Example*
>
> Since the algorithm (last word) hasn't been mentioned yet:
>
> OLD
> Defensively registering all variants of "tax" is
This is getting much better - thanks for all the wordsmithing. I have one
nuance to add...
On Thu, Feb 25, 2021 at 6:13 AM Dave Crocker wrote:
>
> The suggested revisions to Barry's suggested revisions, below, primarily
> serve to reference the PSD construct without needing to reference the
>
On Thu, Feb 18, 2021 at 7:09 AM Ken O'Driscoll wrote:
>
> . . . I'd propose something like the below, which I think gets across what
> we all want to say.
>
> ===
> Aggregate feedback reports contain anonymized data relating to messages
> purportedly originating from the Domain Owner. The
On Wed, Feb 10, 2021 at 6:43 AM Scott Kitterman
wrote:
> No. Sigh. Let's try it again.
>
> Yes, one might actually use a HELO result for DMARC. It gives you the
> same
> result as if mail from is null. So what?
>
> No one has given us a case where an attacker could get a aligned SPF
> result
On Sat, Feb 6, 2021 at 11:53 AM Dotzero wrote:
>
> On Thu, Feb 4, 2021 at 11:43 AM John R Levine wrote:
>
>> I really do not see anything to change here, and we have a lot of other
>> tickets to work on. Please, can we stop and close this one?
>>
>
> +1 Could we have a show of consensus on
On Fri, Jan 29, 2021 at 6:52 AM Tim Wicinski wrote:
>
> I suggest adding it to this paragraph:
>
>This document specifies experimental updates to the DMARC and PSL
>algorithm cited above, in an attempt to mitigate this abuse.
>
update to DMARC = yes; update to PSL = no
> On Fri, Jan
On Mon, Jan 25, 2021 at 10:05 AM John Levine wrote:
> In article <63451726-124b-c24f-3be1-d6435e12c...@tana.it> you write:
> >OLDER:
> >These reports SHOULD include the "call-to-action" URI(s) from inside
> >messages that failed to authenticate.
>
The intent of calling out CTA links was
On Fri, Jan 22, 2021 at 4:57 PM Murray S. Kucherawy
wrote:
> On Fri, Jan 22, 2021 at 4:55 PM Kurt Andersen (b)
> wrote:
>
>> On Fri, Jan 22, 2021 at 3:06 PM Tim Wicinski wrote:
>>
>>>
>>> Here's the paragraph in question
>>>
>>> T
On Fri, Jan 22, 2021 at 3:06 PM Tim Wicinski wrote:
>
> Here's the paragraph in question
>
> To determine the organizational domain for a message under
> evaluation,
> and thus where to look for a policy statement, DMARC makes use of
> a Public Suffix
> List. The process for
On Thu, Jan 14, 2021 at 7:28 AM Murray S. Kucherawy
wrote:
> On Thu, Jan 14, 2021 at 3:12 AM Дилян Палаузов
> wrote:
>
>> I have not read the thread “Ticket #28 - Failure report mail loops”.
>>
>
> Thanks, and apologies to the group; I should've checked for an open ticket
> on this topic first.
On Tue, Jan 5, 2021 at 10:18 AM Paypal security confirm your password now <
jo...@taugh.com> wrote:
> >> reputation for the domain. I have trouble imagining why anyone would
> >> think it's a good idea to get alignment by using third party domains
> >> that recipients don't know.
> >
> > Because
On Tue, Dec 29, 2020 at 5:31 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
>
> DKIM, A-R, and ARC should all have a mandatory attribute indicating the
> HELO name of the server applying the header, the IP Address of the previous
> server which supplied the information being
On Wed, Dec 23, 2020 at 10:10 AM John R Levine wrote:
> On Wed, 23 Dec 2020, Ned Freed wrote:
> > Failure reports provide detailed information about the failure of a
> single
> > message or a group of similar messages failing for the same reason. They
> > are meant to aid in cases where a
On Tue, Dec 22, 2020 at 11:00 AM Alessandro Vesely wrote:
>
> Making specifications that cannot be legally abided by is in IETF scope?
>
Sure - RFC 7258. Unless you want to play the semantic card of BCP vs.
specification.
--Kurt
___
dmarc mailing
On Thu, Dec 10, 2020 at 6:26 PM Dave Crocker wrote:
> On 12/10/2020 6:01 PM, Kurt Andersen (b) wrote:
> > I think that is much closer to the right semantic but highlights a
> > problem that the mail coming from a particular domain probably doesn't
> > rate a single broad-b
On Thu, Dec 10, 2020 at 5:03 PM Dave Crocker wrote:
> On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote:
>
> to quibble with the "*unauthorized use*" situation. This situation
> devolves into use-as-imagined vs. use-as-really-used when one considers
> vario
On Wed, Dec 9, 2020 at 10:09 AM Dave Crocker wrote:
> It might be worth a bit of thinking about what, exactly, DMARC can
> reasonably do and how it should be summarized, for popular consumption:
>
> *Alignment - *DMARC defines a basis for authenticating use of the domain
> name in the
I'm wondering why we should wait for IETF110 rather than having an interim
meeting sooner. Interim meetings are also likely to garner greater
participation since they do not include participation fee. If there are
topics worthy of F2F discussion, why wait? If there are not, then why
charge people
On Sun, Dec 6, 2020 at 10:46 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
>
> I ask the chairs to formally endorse development of an alternative to ARC
> as an additional approach to the mailing list problem...
>
So you are asking the WG to go back to our second milestone and
On Sat, Dec 5, 2020 at 5:21 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> ...much of this is about AOL in particular, and the currently available
> information suggests that AOL is not on board with ARC.
>
I would point you to
On Sun, Dec 6, 2020 at 11:13 PM Murray S. Kucherawy
wrote:
> On Tue, Dec 1, 2020 at 2:17 PM John R Levine wrote:
>
>> We would like to close this ticket by Dec 15, two weeks from now, so
>> short
>> trenchant comments are welcome.
>>
>> Ticket #1 is about SPF alignment. We need to replace
On Fri, Dec 4, 2020 at 2:51 PM Michael Thomas wrote:
>
> What changed in the bis version to change its intended status?
>
The entire point of this working group (and the bis version that is in
progress) is to move DMARC into the fully-recognized "standards" track.
Note that even the current
As usual, John has pretty well nailed the response, but there was one other
part of your question (Mike) that I thought deserved explanation:
On Sat, Nov 21, 2020 at 7:14 PM John Levine wrote:
> In article you write:
> >If I'm a receiver who is going to be making some filtering decisions
>
On Fri, Nov 20, 2020 at 5:57 AM Doug Foster wrote:
>
> However, spoofing of non-existent subdomains is a potential problem for the
> RFC5321.MailFrom domain, which then becomes an attack vector for the
> RFC5322.From address as well. The problem exists because because SPF has
> no
>
+1 to being able to sleep through the night and deal with issues
asynchronously on the list.
--Kurt
On Tue, Nov 17, 2020 at 12:10 PM Dotzero wrote:
> Considering that some of us have to be up in the wee hours to participate,
> it would be nice to know whether it is happening or cancelled. Just
On Sun, Nov 15, 2020 at 12:21 PM John Levine wrote:
> In article wm5wltcgib0jby0gubntop3qhzfr68yb2__r...@mail.gmail.com> you write:
> >
> https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08=draft-ietf-dmarc-psd-09
> >
> >Please review the changes and offer up comments to the working
On Fri, Nov 13, 2020 at 10:41 AM Tim Wicinski wrote:
>
> All
>
> During the chairs call this morning we were discussing the upcoming
> meeting. Now Seth has a conflict with the meeting time that can't be
> altered. Since work items have been progressing rather well recently, and
> the editors
On Thu, Nov 12, 2020 at 2:58 PM Jesse Thompson wrote:
> On 11/12/20 3:23 PM, John Levine wrote:
> > You now can put a DMARC
> > record on a name below the org domain to shadow a subtree, but I don't
> > think that is a problem that needs to be solved.
>
> I'm confused by this statement. Are you
On Thu, Nov 5, 2020 at 9:31 AM Alessandro Vesely wrote:
> The consensus of the working group is to remove the
> normative constraint about p= (ticket #49). So now only v= is required.
>
I must have completely misunderstood the discussion and will have to go
back and look up the thread. I
On Mon, Oct 26, 2020 at 2:59 PM Tim Wicinski wrote:
>
> This starts a Call for Adoption for: DMARC-bis
>
> We'll be starting with the text from the RFC 7489.
> This is available here:
> https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-dmarcbis/
>
> Changes made so far have been to include
On Tue, Sep 29, 2020 at 3:50 PM Dave Crocker wrote:
> On 9/29/2020 3:08 PM, Seth Blank wrote:
> > I don't know of any receiver that checks DMARC, but then doesn't check
> > alignment
>
> It's not a matter of field statistics:
>
> Since checking alignment is an obvious part of the DMARC
>
On Tue, Sep 29, 2020 at 3:15 AM Alessandro Vesely wrote:
>
> +1. The rationale, AIUI, is that if the receiver successfully evaluated
> alignment, then "pass" is fine. If the receiver didn't evaluate anything
> after
> it saw p=none, then "none" is fine. and should agree.
>
If a receiver
On Mon, Sep 28, 2020 at 8:47 PM Seth Blank wrote:
> At a minimum, per Dave's comments here:
> https://mailarchive.ietf.org/arch/msg/dmarc/XXE3r5FUozl6LVohv8rTkn5QG4E/
> I still believe there's some clear consistent language that needs to be
> agreed upon to drive the appropriate specificity in
On Mon, Sep 28, 2020 at 10:46 AM Dave Crocker wrote:
> . . .given that 'disposing of' the message is a domain owner goal,
> frequently, perhaps changing "disposed of" to "processed" would be less
> inviting of misunderstanding?
>
Yes, I think that, at least in American English usage, "disposal"
On Sun, Sep 27, 2020 at 11:23 AM Scott Kitterman
wrote:
> On Sunday, September 27, 2020 1:16:11 PM EDT John Levine wrote:
>
> Agreed. Maybe it would help if someone who takes the latter view would
> explain what they think RFC 7489, Section 6.6.2, Step 6 is for:
>
> >6. Apply policy.
achieve closure more quickly. Ideally we
could come to these changes without having to wait for IETF109.
--Kurt Andersen
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On Wed, Sep 23, 2020 at 2:56 PM Seth Blank wrote:
> The original question in this thread had two parts:
>
> "Is it desirable to clarify this language, [1] such that it is clear which
> DKIM keys are required to include in a report, and [2] if so, how should
> the appropriate keys be determined?"
On Thu, Sep 24, 2020 at 1:39 AM Murray S. Kucherawy
wrote:
> On Sun, Jun 7, 2020 at 2:23 PM Seth Blank 40valimail@dmarc.ietf.org> wrote:
>
>> https://trac.ietf.org/trac/dmarc/ticket/51
>>
>> In a DMARC aggregate report, a record with a disposition of "none" is
>> ambiguous, as a disposition
A scenario that you did not list, but which used to be common was a mail
transit path that went both in and out of a foreign protocol. Consider the
example of a message that starts with SMTP --> X.400 (with irreversible
changes) --> SMTP --> recipient. If the inbound and outbound gateways are
not
https://academic.oup.com/cybersecurity/article/6/1/tyaa009/5905453 was just
published by NIST, proposing a difficulty rating scale for detecting (and
hence avoiding) phishing messages.
Interestingly, the domain aspects are relatively minor cues amongst their
extensive list. They do not score the
The lack of universal DMARC verification and insufficient flexibility in
the application of enforcement and local policy overrides in the "filter
spam as a service" market (as well as the X.400, SMS, UUCP, Bitnet sort of
protocol gateways) were the problems that we were addressing within this
item
On Wed, Aug 19, 2020 at 12:11 PM John R Levine wrote:
>
> It is abundantly clear that Ericsson and AOL and Yahoo do not object to
> their users sending mail through discussion lists. Ericsson doesn't want
> their execs to be phished, AOLhoo doesn't want complaints "why am I
> getting spam from
On Wed, Aug 19, 2020 at 1:34 AM Alessandro Vesely wrote:
> On Tue 18/Aug/2020 01:21:33 +0200 Murray S. Kucherawy wrote:
> > The industry in general, and the IETF in particular, have chosen not
> > to pursue widespread use of any kind of standards-based third party
> > domain signature policy or
On Fri, Aug 14, 2020 at 12:16 PM Jim Fenton wrote:
> On 8/14/20 11:30 AM, Kurt Andersen (b) wrote:
>
> On Fri, Aug 14, 2020 at 9:23 AM Dotzero wrote:
>
>>
>> Is this an interoperability problem that is solved by IETF standards or
>> is it an organi
On Fri, Aug 14, 2020 at 9:23 AM Dotzero wrote:
>
> Is this an interoperability problem that is solved by IETF standards or
> is it an organizational problem that requires an organizational solution?
> Perhaps we need to generate an RFC entitled "Don't Do Stupid Things". ;-)
>
I think that it
On Fri, Aug 14, 2020 at 7:31 AM Dotzero wrote:
>
> I've been involved in setting up DMARC with a policy of p=reject for
> somewhere North of 6,000 domains. As a sending domain, the heavy lifting is
> in getting buy-in across the organization that it is a worthwhile effort,
> getting control of
It would be worthwhile for everyone in the group to read through
https://www.usenix.org/conference/usenixsecurity20/presentation/chen-jianjun
as they analyze implementation flaws that allow attacks against DMARC in
existing implementations.
The paper should be publicly accessible now since the
On Thu, Aug 13, 2020 at 2:33 PM Doug Foster wrote:
> The current DMARC architecture supports authorizing a vendor to mail on
> behalf of their clients if the client includes them in their SPF policy or
> delegates a DKIM scope to them and they use it.
>
>
>
> I agree that SPF is too limiting
On Thu, Aug 13, 2020 at 12:06 PM Neil Anuskiewicz
wrote:
>
> Tunable! You said the magic word I have a client now getting spoofing.
>
Receiving spoofed mail or having their domain *being* spoofed?
> My point is that it sure would be nice to be able to tune so that BigCRM
> and BigCRM
On Mon, Aug 10, 2020 at 12:05 PM Tim Wicinski wrote:
>
> During IETF 108, the chairs realized that there was interest in Dave's
> RFC5322.Sender draft.
>
> This starts a Call for Adoption for draft-crocker-dmarc-sender
>
+1 for adopting the document into the WG for continued discussion.
--Kurt
This is a known issue with many calendaring frameworks. Besides the issue
of delegates who are sending on behalf of someone in another domain, most
calendaring systems send "forwarded" invitations by trying to resend in the
name of the event originator.
--Kurt
On Mon, Jul 20, 2020 at 11:36 AM Seth Blank wrote:
> We have a session on the books for IETF108, and would like suggestions
> from the group for the agenda, otherwise the chairs will choose relevant
> topics. Items in tickets or from the past month are all fair game.
>
Based on the recent
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 our
>> CEO to other employees for responses which happened to contain malware
>> and/or bad links. ...
>Except that the problem isn't
Dave writes:
However, for all of the real and serious demonstration of users' being
tricked by deceptive or false content in a message, there is no
evidence that problematic content in a field providing information
about message's author directly contributes to differential and
problematic
On Fri, Jun 19, 2020 at 12:41 AM Laura Atkins
wrote:
> On 19 Jun 2020, at 07:59, Murray S. Kucherawy wrote:
>
> So to those of you with access to such (e.g., M3AAWG regulars among
> us), is there evidence in the wild of spammers and phishers using
> discardable (ahem) domains to achieve
On Mon, Jun 15, 2020 at 11:30 AM Tim Wicinski wrote:
>
> On Mon, Jun 15, 2020 at 2:27 PM Scott Kitterman
> wrote:
>
>>
>> To follow-up on Brandon's note about Google's use of ARC, it's bigger
>> than
>> mailing lists and so is this problem. It's any intermediary that
>> modifies a
>> message
On Fri, Jun 12, 2020 at 5:52 PM Dave Crocker wrote:
>
> > ARC lets the recipient look back and retroactively do the filtering
> > the list didn't.
>
> The concern about the creator of an ARC chain spoofing the purported
> origin of a message is valid.
>
By "creator" do you mean "initiator"
On Fri, Jun 12, 2020 at 5:06 PM Scott Kitterman
wrote:
>
> On June 12, 2020 11:33:13 PM UTC, "Kurt Andersen (b)"
> wrote:
> >I would like to understand what you mean by:
> >
> >On Fri, Jun 12, 2020 at 1:02 AM Alessandro Vesely
> >wrote:
> >
I would like to understand what you mean by:
On Fri, Jun 12, 2020 at 1:02 AM Alessandro Vesely wrote:
> . . . ARC chains can be forged.
>
--Kurt
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
I'm sorry to pile on but could not restrain myself:
https://www.bmj.com/content/327/7429/1459?ijkey=c3677213eca83ff6599127794fc58c4e0f6de55a=tf_ipsecsha
I get Dave's point, but at the same time, it is well known that copy tweaks
can have significant effects on conversion rates. Whether the
On Fri, May 15, 2020 at 6:14 PM John Levine wrote:
> In article zmn0oxmgns0cspywu58hqlaw7wvvbh1442yu4e...@mail.gmail.com> you write:
> >-=-=-=-=-=-
> >Should we consider adding JSON formatting to DMARC?
>
> What Scott said, no. Report processors will always have to be able to
> decode the
Extracting from the abstract of a paper in process by Casey Deccio (now
researching SPF at BYU, formerly at Cisco):
Our techniques elicit SPF and DMARC validation activity of the servers,
> while minimizing spam and perceived abuse. We find that only 25% of mail
> servers and less than half of
On Thu, Apr 16, 2020 at 7:29 AM John Levine wrote:
> In article <4666d39f-85f5-4ad2-a754-11fed0a5c...@kitterman.com> you write:
> >Perhaps I'm too pessimistic, but I don't think it's possible to actually
> make this clear to anyone that isn't familiar
> >with RFC 7489 without essentially turning
On Fri, Apr 10, 2020 at 9:34 AM John Levine wrote:
> In article skkohn-j+qiccser1rtg1anwpw...@mail.gmail.com> you write:
> >-=-=-=-=-=-
> >
> >Agree with John/Scott/Kurt on keeping this in 7489 and trying to weasel
> >word around it for now.
>
> So how about renaming it Policy Super Domain
On Fri, Apr 10, 2020 at 6:49 AM Scott Kitterman
wrote:
> On Friday, April 10, 2020 9:38:40 AM EDT Todd Herr wrote:
> >
> > I don't disagree, but what I was going for here was some level of
> > consistency with section 3.2 of RFC 7489. . .
>
And it needs to stay entirely in RFC7489 :-)
> >
On Thu, Apr 9, 2020 at 1:36 PM Murray S. Kucherawy
wrote:
>
> 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
On Fri, Apr 3, 2020 at 1:09 PM John Levine wrote:
> In article <
> caba8r6sbhlfkzhd4gapbxqbgny57j1elxt2spyafatyay3t...@mail.gmail.com> you
> write:
> >In practice, I don't know how common it is for clients to consume this
> >header.
>
> They have to if they're adding ARC seals on the way out.
>
On Tue, Mar 31, 2020 at 10:56 AM Damian Lukowski wrote:
> > I don't see any reason to exclude them. We could do this:
> >
> > autbserv-id = sub-domain *("." sub-domain)
> >
> > Where sub-domain is imported from 5321 for ASCII mail and 6531 for EAI
> mail.
>
> Does this mean that a
On Mon, Mar 30, 2020 at 10:43 PM Murray S. Kucherawy
wrote:
> 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
On Sat, Mar 7, 2020 at 7:15 AM Murray S. Kucherawy
wrote:
>
>> Thanks to you and Murray for carrying out that writeup. For a nit:
>>
>> There is one implementation already . . .
>>
>> Actually two. Besides Scott's implementation, zdkimfilter 1.7 implemented
>> PSDDMARC since Tue 24 Sep
On Sat, Feb 29, 2020 at 11:16 AM Tim Wicinski wrote:
>
> If we're going down the road of definitions, RFC8499 defines what a
> "Public suffix" 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
On Thu, Feb 27, 2020 at 4:16 AM Alessandro Vesely wrote:
> On Thu 27/Feb/2020 06:30:59 +0100 Murray S. Kucherawy wrote:
> >
> > With a completed (and now seven month old) Working Group Last Call on the
> > PSD document, and as far as I can see no sustained objection, we should
> > proceed toward
On Tue, Feb 4, 2020 at 10:13 PM Scott Kitterman
wrote:
>
> Assuming that's correct, please help me understand what PSD DMARC is
> affected at all. All it does is consume the org domain however
> DMARC/DMARCbis choose to define it. I don't see as it makes a difference
> from a PSD DMARC
On Tue, Dec 10, 2019 at 2:13 PM Brandon Long wrote:
>
> On Mon, Dec 9, 2019 at 6:27 PM Kurt Andersen (b) wrote:
>
>> On Mon, Dec 9, 2019 at 4:54 PM Scott Kitterman
>> wrote:
>>
>>> On Monday, December 9, 2019 7:41:27 PM EST Brandon Long wrote:
On Mon, Dec 9, 2019 at 4:54 PM Scott Kitterman wrote:
> On Monday, December 9, 2019 7:41:27 PM EST Brandon Long wrote:
>
> > I'm sure I probably missed this, but couldn't we avoid this question by
> just mandating no reporting for non-existing organizational domains? Is
> that a non-starter?
>
On Wed, Dec 4, 2019 at 2:39 AM Alessandro Vesely wrote:
>
> > Rather, it's primed as a possibly useful data collection exercise.
>
> Kurt also talked about reporting some findings. I'm embarrassed, I have no
> idea what I, as a receiver, should report. What data should I, and other
> receivers
I'm willing to volunteer.
On Tue, Dec 3, 2019 at 12:42 PM Murray S. Kucherawy
wrote:
> 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
I think that if we could get a core set of receivers who would be willing
to test this and report on their findings in 3-6 months, that would be
great.
--Kurt
On Tue, Dec 3, 2019 at 12:40 PM Murray S. Kucherawy
wrote:
> On Mon, Nov 11, 2019 at 2:21 PM Dave Crocker wrote:
>
>> On 11/10/2019
On Mon, Dec 2, 2019 at 9:11 AM John C Klensin wrote:
>
> --On Monday, December 2, 2019 08:29 -0800 Dave Crocker
> wrote:
>
> > On 12/2/2019 7:56 AM, Kurt Andersen (b) wrote:
> >> There's also already RFC7960 which expands upon 5598 with
> >> specific refe
There's also already RFC7960 which expands upon 5598 with specific
reference to DMARC's impact.
On Sat, Nov 30, 2019 at 7:37 AM Dave Crocker wrote:
> On 11/30/2019 4:40 AM, Alessandro Vesely wrote:
>
> Let me quote this from the ietf-smtp mailing list:
>
> On Sat 30/Nov/2019 00:12:53 +0100 John
On Mon, Nov 11, 2019 at 12:43 PM Alessandro Vesely wrote:
>
> about the need for each OD to opt out by defining its own DMARC record,
> lest
> have reports delivered to the realm. In the latter sense, Nominet solved
> the
> problem of what rights has gov.uk on domains below it.
>
Requiring
On Mon, Nov 11, 2019 at 9:50 AM Alessandro Vesely wrote:
> On Mon 11/Nov/2019 16:46:17 +0100 Kurt Andersen (b) wrote:
> >
> > I don't think that it is fair to say that anyone who refers to the org
> domain
> > concept as cited in the DMARC spec is necessarily invo
On Mon, Nov 11, 2019 at 1:23 AM Alessandro Vesely wrote:
>
> Does the WG agree to an erratum as follows:
>
> TYPE: technical
>
> SECTION: 2.3
>
> ORIGINAL TEXT:
>
>smtp: Indicates information that was extracted from an SMTP command
> that was used to relay the message. The "property"
On Mon, Nov 11, 2019 at 1:58 AM Tim Wicinski wrote:
> Scott
>
> PSD DMARC does talk about organizational domains which from the original
> DMARC spec (section 3.2)
> does say 'Acquire a "public suffix" list'
>
> The addition of the preamble text shouldn't move the document in either
> direction.
On Mon, Nov 11, 2019 at 1:58 AM Tim Wicinski wrote:
> Scott
>
> PSD DMARC does talk about organizational domains which from the original
> DMARC spec (section 3.2)
> does say 'Acquire a "public suffix" list'
>
> The addition of the preamble text shouldn't move the document in either
> direction.
for ARC to be a valuable addition to DKIM, it
> needs to focus on the “custodian” and not the “sender”.
>
>
>
> Thank you both for your time and attention.
>
> -Bill
>
>
>
> *From:* Brandon Long
> *Sent:* Wednesday, November 6, 2019 12:43 PM
> *T
o
I don't see how mutability would matter.
--Kurt Andersen
On Wed, Nov 6, 2019 at 7:30 AM Weist, Bill wrote:
> DOI: 10.17487/RFC8617
>
>
>
> The inclusion of the address headers in the signature, and possibly the
> Subject, is an issue:
>
>
>
> ARC-Message-Signat
On Fri, Oct 25, 2019 at 3:52 AM Дилян Палаузов
wrote:
>
> If it is a goal to reuse the dmarc-reporting mechanism to report also
> about perceived spam probability, then it can be
> discussed in more details how this can be achieved. My experience is,
> that asking a provider, why an obviously
On Fri, Aug 2, 2019 at 3:00 AM Alessandro Vesely wrote:
> To stick with A-R semantics, it should have been named
> tcp.ip, remote.ip or some such.
>
Note that RFC8617 section 10.2 (
https://tools.ietf.org/html/rfc8617#section-10.2) does add in an
smtp.remote-ip method item.
--Kurt
u mind proposing concrete language
to replace Appendix C? Speaking from experience, it can be helpful to be
able to do in-place comments/markup so I've posted
http://bit.ly/dmarc-rpt-schema - please make any adjustments in "Suggest"
mode or comments you feel appropriate. The invitation
On Mon, Jul 22, 2019, 04:44 Scott Kitterman wrote:
>
> On July 22, 2019 4:31:40 AM UTC, "Douglas E. Foster" <
> fost...@bayviewphysicians.com> wrote:
>
> >"Senders SHOULD register all domains in DNS, as MTA operators MAY block...
>
> I think that it is well outside the scope of this document to
On Fri, Jul 19, 2019 at 8:30 AM Kurt Andersen (b) wrote:
> On Thu, Jul 18, 2019 at 10:42 PM Scott Kitterman
> wrote:
>
>>
>> If we want to take another run at this and put it in more standard DNS
>> terminology, then maybe:
>>
>> a domain for which
On Thu, Jul 18, 2019 at 10:42 PM Scott Kitterman
wrote:
> On Thursday, July 18, 2019 11:42:36 AM EDT Kurt Andersen (b) wrote:
> > On Wed, Jul 17, 2019 at 7:35 PM Scott Kitterman
> >
> > Most MTAs will also follow CNAMEs. Should they be included (along with
> > othe
On Wed, Jul 17, 2019 at 7:35 PM Scott Kitterman
wrote:
> > On July 17, 2019 8:14:54 PM UTC, "Kurt Andersen (b)"
> > wrote:
> > >Firstly, I'm a little concerned with the sentence which says 'Note that
> > >"np" will be ignored for DMARC reco
On Wed, Jul 17, 2019 at 2:40 PM John Levine wrote:
> In article zsdwzvr...@mail.gmail.com> you write:
> >Firstly, I'm a little concerned with the sentence which says 'Note that
> >"np" will be ignored for DMARC records published on subdomains of
> >Organizational Domains and PSDs due to the
1 - 100 of 332 matches
Mail list logo