In article
you write:
>-=-=-=-=-=-
>
>In mid-November, I shared some proposed text for new Abstract and
>Introduction sections -
>https://mailarchive.ietf.org/arch/msg/dmarc/wNE-cvIWQ3PXrM-42SozSocnnxs/
>
>Dave Crocker submitted some suggestions on-list, and I noodled a bit with
>the text
In article you write:
>On Thu 10/Dec/2020 00:48:12 +0100 Jesse Thompson wrote:
>> On 12/9/20 11:07 AM, Alessandro Vesely wrote:
>>> We would like to close this ticket by Dec 23, two weeks from now, so please
>>> get on it.
>>>
>>> The ticket text is:
>>>
>>> It has been asked for a new
In article <7dc4203e-1140-8808-776c-e80e5b5f6...@tana.it> you write:
>> Many Girl Scout troops were affected when Yahoo published p=reject. Which is
>> probably why John brought it up. This isn’t a hypothetical, this is things
>> that
>> we know actually happened and real world effects of
In article <2717cf5f-bec9-d561-d7f7-ac167dc7c...@tana.it> you write:
>>> dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mrochek.com
>>> The policy statement is right there: p=NONE.
>>>
>> No. That is not guaranteed whatsoever. It could say "(eat at Joe's)" and be
>> valid.
>
>
>Correct.
In article <14d833ce-0ae0-f818-fd4f-95769266a...@mtcc.com> you write:
>
>On 12/29/20 12:10 PM, John Levine wrote:
>> A lot of tiny non-profits like Girl Scout troops use email addresses
>> at webmail providers and send their announcements through ESPs like
>>
In article <5d0793ae-de65-cd1d-32ef-c909202a0...@mtcc.com> you write:
>
>On 12/29/20 10:59 AM, John Levine wrote:
>>
>> Don't forget
>>
>> o Normal forwarding of SPF validated mail
>> o Authorized third party senders with no access to DKIM keys
In article <01rtqrkld8qk004...@mauve.mrochek.com> you write:
>I think a list of possible failure causes would be nice to have, because
>a lot of people seem to think that DMARC is a completely reliable mechanism.
>
>I'm not entirely convinced this document is the place for it, but OTOH
>I'm not
In article
you write:
>I believe at one time long ago there was an idea that a second possible
>usage for failure reports showing illegitimate mail was to give the domain
>owner evidence to present to an abuse desk or takedown vendor to get the
>illegitimate mail cut off at its source, but I
In article
you write:
>Is it not also important to note that the recipient of the failure report
>(the domain owner) may not be the originator of the failed message, and
>that fact should also weigh into the consideration of deciding whether to
>generate such reports?
The exact same issue
In article
you write:
>-=-=-=-=-=-
>Aggregate reports and failure reports get used in wholly different manners,
>have fundamentally different use cases, are implemented in wildly different
>ways, and have completely different privacy and security considerations.
All true, but the actual specs
Count| Bytes | Who
++---
17 (34.0%) | 98873 (25.5%) | Alessandro Vesely
11 (22.0%) | 59211 (15.3%) | John Levine
6 (12.0%) | 38088 ( 9.8%) | Michael Thomas
3 ( 6.0%) | 13012 ( 3.4%) | Benny Pedersen
2 ( 4.0%) | 39519 (10.2%) | Todd
Count| Bytes | Who
++---
10 (23.3%) | 61316 (13.9%) | Alessandro Vesely
6 (14.0%) | 29727 ( 6.7%) | John Levine
5 (11.6%) | 95589 (21.7%) | Douglas Foster
5 (11.6%) | 34737 ( 7.9%) | Michael Thomas
3 ( 7.0%) | 82453 (18.7
In article <754690b7-6624-4cc6-66e1-62438b32c...@tana.it> you write:
>On Sat 19/Dec/2020 01:03:58 +0100 Seth Blank wrote:
>>
>> A privacy consideration should say such a thing, specifically clarify what
>> may be in a report that could be categorized as PII even after intended
>> redaction, but
In article <1e61f7c4-c6d2-5dab-dfc7-f1fd740e1...@tana.it> you write:
>Now my tiny MX stores 115,225 domains total. And I have no idea how I could
>add a trust-ARC-seals boolean field to each domain record.
You wouldn't. Only a small fraction of those domains send enough forwarded
mail to be
In article you write:
>We would like to close this ticket two weeks from now, by the end of the year,
>so please get on it.
>
>The ticket text is just:
>
> Make it clear in privacy considerations that failure reports can provide
> PII well beyond a domain name, and are not sent by most
In article
you write:
>I'm seeing a report where the XML contains two SPF records within a single
>auth_results entity. This doesn't seem correct.
It's specifically allowed in the XML schema. In this case I'd guess it
is checking the From header domain, the org domain, and the bounce
Count| Bytes | Who
++---
35 (18.8%) | 267386 (16.8%) | Michael Thomas
29 (15.6%) | 150513 ( 9.5%) | John Levine
23 (12.4%) | 120702 ( 7.6%) | Alessandro Vesely
22 (11.8%) | 182969 (11.5%) | Dave Crocker
16 ( 8.6%) | 123376 ( 7.8%) | Murray
In article <6c5878e8-fdd8-05c0-3b60-ba180ecbc...@tana.it> you write:
>Maybe it's me, but I don't understand the change below. The only difference I
>see between Old: and New: is the removal of «minOccurs="1"». Since that is
>the
>default value, I see no incompatibility. What am I missing?
In article
you write:
>Based on a discussion from last year
>(https://mailarchive.ietf.org/arch/msg/dmarc/YoHhhaAfwRjbd8aq4fiV6xU1ifw/),
>there was a
>request/ticket to clarify the language in the document.
>
>>From https://tools.ietf.org/html/rfc7489#section-7.2:
>
> * Data for each Domain
In article <1ac986ff-507b-4917-9c6d-d84e9337f...@wordtothewise.com> you write:
>p=none: mail sent by authorized users of this domain may or may not be aligned
>in a DMARC compliant way.
>
>p=quarantine: mail sent by authorized users of this domain should be aligned
>in a DMARC compliant
>way.
In article you write:
>-=-=-=-=-=-
>
>On 12/9/2020 3:05 PM, Michael Thomas wrote:
>> we know that amount of traffic going through mailing lists is tiny --
>> like a couple percent.
People at very large mail systems tell me that while the amount of
traffic from discussion lists is a tiny part of
In article
you write:
>For this ticket in particular-- the simplified failure report with only
>from: and to: addresses speaks to Jesse's exact use case, without any of
>the other PII that tends to get failure reports in privacy trouble (like
>body content and attachments). This approach to
In article you write:
>I would hesitate to assume that seeing p=none on a domain as an indicator that
>they are serious about deploying DMARC and reconciling their
>own Holy Roman Empire conundrums; rather it's there just to not be seen as
>lagging behind their peers, justifying funding for
In article <609e1c9b-cc4d-d7d1-0fa8-79f515c1e...@tana.it> you write:
> It has been asked for a new report type (perhaps a subset of failure
> reports) that provides minimal data from the email (specifically, the
> initial ask is for the to: and from: email addresses only) in order to
In article <62b7d80e-2c39-4d02-0b5a-bd6ede7d5...@tana.it> you write:
>When dmarc authentication method fails on a message, an MTA may decide to send
>a failure report. If the message is itself a failure report, however, no
>failure report should be sent. The question is, how does the MTA
In article
you write:
>-=-=-=-=-=-
>
>Note that I asked Two questions. Your answer appears directed to the second
>question. The answer to the first question appears fairly clear to me.
>Administrators of a system can restrict or delete a user account.
It depends what agreements they might have
In article you write:
>>> I didn't get any of those (the POSTs below are not to the right URI)
>>> but it's impressive how fast Russian bots started to probe it, within
>>> hours.
>>
>> I thought it's about interoperability. Simply having a webserver running
>> doesn't come close to
I don't think there is a ticket for this, but it would be nice if
there were standard ways to put a few more items into the DMARC part
of an A-R header, in particular the p= and pct= values and the
location of the policy record if it's not the same as header.from.
None of the existing ptypes
In article
you write:
>Anyways, +1 to keeping p=quarantine as a concept, but willing to go along
>with the consensus on naming.
I'm modestly in favor of keeping p=quarantine as a feature but utterly opposed
to changing the keywords such as "p=quarantine" in the DMARC record.
It's fine to
In article
you write:
>> I have a slight preference for the first option. HELO is too arbitrary in
>> the protocol for me to put much value in using it in any of these systems.
>
>There's a bit of an implementation detail though. If one is relying on an
>encapsulated ck_host() function then you
>I don't understand the security or GDPR references.
Well this is amusing. I wondered if anyone had ever implemented some
version of the http reporting in early DMARC drafts, so I set up a new domain
with a server that will accept POST or PUT requests and added its URI to my
DMARC records.
I
In article <0408ae98-e1c1-71fe-fdd4-8bc7a7c15...@tana.it> you write:
>We would like to close this ticket by Dec 18, two weeks from now, so please
>get
>on it.
>
>The ticket originated from John's comment, in May 2019:
>
> Apropos recent discussions, we could recommend that failure reports be
In article you write:
>Compared with the use of "l=" tag (Section 8.2 of [RFC6376]), the
>fact that footers are written in plain text ...
They are? Some are, some are added as MIME parts.
We really need to keep in mind that there is a lot of list management
software with a vast array
In article
you write:
>As I recall, people took a run at trying ADSP and it was largely
>unsuccessful. I recall at least Yahoo, PayPal, and Google trying it but
>finding that it interfered with their employees' participation in lists, so
>they each invented new domains for their employees to
Count| Bytes | Who
++---
35 (24.0%) | 311900 (26.3%) | Michael Thomas
28 (19.2%) | 154564 (13.1%) | John Levine
20 (13.7%) | 134094 (11.3%) | Dave Crocker
15 (10.3%) | 84752 ( 7.2%) | Alessandro Vesely
8 ( 5.5%) | 134799 (11.4%) | Brandon
In article you write:
>The domain owner might want all sorts of unreasonable things. Having a
>way to let the domain owner publish demands that are widely ignored
>indicates a seriously flawed semantic model. And that is, indeed, the
>current reality for DMARC.
Thanks. Lest anyone think this
In article you write:
>If ARC is advocating for a bypass of p=reject that introduces a new
>state. If my policy is reject, I want you to reject the mail. If I want
>you to reject the mail unless you think it has come from an acceptable
>place with receipts, then you need a new policy tag like
In article you write:
>> our job to try to guess whether the bank's users are following some
>> internal policy we can't see.
>
>There is no guarantee of that. If my bank says reject that mail, I want
>my provider to reject that mail, period. No amount of ARC shenanigans
>should change that
In article you write:
>>> Got it. However, the spec says it's a list of addresses to which aggregate
>>> feedback is to be sent. When there are multiple entries, up to now,
>>> reports
>>> are sent to each. ...
>The VALCHAR element in Section 3.2 of RFC 6376 accepts "/", which is seldom
In article <4f2d2e0e-c773-95df-0958-12344e963...@mtcc.com> you write:
>
>As I understand ARC, it is means of transporting the original auth-res
>to the destination in case the origin signature is broken by an
>intermediary. From there the destination can decide one way or the other
>to override
In article you write:
>> I dunno how special that case is, but there are lots of cases where mail
>> passes
>> through multiple layers of ARC signing mutations.
>>
>> I routinely get mail from Microsoft's farm with an ARC seal or two
>> that has never been near a mailing list. Any time a MS user
In article
you write:
>Hello,
>
>There's currently a ticket that suggests that the requirement for external
>validation be removed. Today, if
>example.com has an RUA that points at example.net, the latter must create a
>record as such:
>
>example.com._report._dmarc.example.net TXT "v=DMARC1"
In article
you write:
>mailing list to mailing list mail is very common in GSuite, but maybe we're
>a special case.
I dunno how special that case is, but there are lots of cases where mail passes
through multiple layers of ARC signing mutations.
I routinely get mail from Microsoft's farm with
In article <0408ae98-e1c1-71fe-fdd4-8bc7a7c15...@tana.it> you write:
>We would like to close this ticket by Dec 18, two weeks from now, so please
>get
>on it.
>
>The ticket originated from John's comment, in May 2019:
>
> Apropos recent discussions, we could recommend that failure reports be
In article you write:
>Maybe _discardable_ should be used instead.
>
>Why do I have a feeling of deja vu?
Gee, I can't imagine.
R's,
John
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
In article you write:
>On Tue 01/Dec/2020 23:21:48 +0100 John R Levine wrote:
>> We can adapt the approach MTA-STS uses in RFC 8460.
>>
>> If rua= has an https URI, the reporter uses HTTP POST to that URI with
>> the report as an uncompressed or gzipped XML file as the POST body.
>
>TL;DR:
In article <327860af-2fa7-63ee-4b89-6e7e383f3...@crash.com> you write:
>> Do you think there was a shared understanding of how p=quarantine
>> would be implemented? ...
>quarantine." Rather that the Domain Owner is requesting whatever the
>Receiver implements between rejecting the message and
In article
you write:
>I know of no other
>standard that requires this type of relationship.
Here at the IETF, the CAA DNS record that specifies which certificate
authority can sign for what domains does a tree walk. If there is a
CAA record at example.org it controls signing of foo.example.org
In article you write:
>On 12/1/20 4:16 PM, Douglas Foster wrote:
>>
>> I have always assumed that p=quarantine and pct<>100 were included to
>> provide political cover for "Nervous Nellies" who were afraid to
>> enable p=reject.
>
>p=none, p=quarantine, and the pct= option were all included so
Count| Bytes | Who
++---
24 (20.7%) | 218851 (20.1%) | Michael Thomas
23 (19.8%) | 126757 (11.7%) | John Levine
14 (12.1%) | 130060 (12.0%) | Dave Crocker
11 ( 9.5%) | 57691 ( 5.3%) | Alessandro Vesely
10 ( 8.6%) | 114874 (10.6%) | Brandon
In article you write:
>questions the wg deems needed since then. Leaving ARC in an experimental
>state ad infinitum doesn't seem optimal. Basically: 1) was it needed at
>all 2) did it help. 3) if it helped, how much did it help.
I agree that at some point we need to declare the experiment over
In article <695b8714-b174-e3d6-d6c0-1a1d535fb...@mtcc.com> you write:
>Not everything is service provider. We were investigating this from an
>enterprise standpoint.
>
>And if you can't trust mailing traffic from providers what is the point
>of ARC?
Um, please see the previous umpteen messages
's enough of a problem
that Gmail can't just whitelist traffic from mailing lists.
R's,
John
--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-
In article
you write:
>-=-=-=-=-=-
>
>On Tue, Nov 24, 2020 at 10:47 AM Alessandro Vesely wrote:
>
>> The PSL is the result of a community-maintained effort. ...
>I'm curious as to whether this is the consensus opinion of the PSL. It's
>my impression that it is not, given the arguments that
In article <9ab0d7b9-2e35-f64b-02ea-a111c10ac...@wisc.edu> you write:
>So if acme.example publishes aspf=s adkim=s
>It does not prevent finance.acme.example from publishing aspf=r adkim=r
>Which would align widgets.acme.example with finance.acme.example even if the
>intent was to only align
In article you write:
>On Tue 24/Nov/2020 13:52:43 +0100 Brotman, Alex wrote:
>> I had one spam message that had 13 parts. It included both "_mta-sts" and
>> "mta-sts" in there, as well as
>"mail" nine times. The last two parts were the org domain.
>
>If the message happened to authenticate,
In article you write:
>> One of the points of the tree walk is to get rid of the PSL processing.
>
>The PSL processing is a local lookup on an in-memory suffix tree. How is it a
>progress to replace it with a tree walk? A PSL search is lightning faster
>than
>even a single DNS lookup, isn't
In article
you write:
>I suppose that an approach to building up an ARC reputation might be one
>where over time a receiving site can compare indirect mail flow that is
>purported to have X as an authenticated identifier with mail that comes
>direct to the receiving site with X as an
In article <9f388e33-c15d-9fcc-e9d3-d7719288f...@gmail.com> you write:
>On 11/23/2020 1:04 PM, Jesse Thompson wrote:
>> I meant to suggest that the requirement for a tree walk would be that the
>> Organizational Domain would need to have that in its policy.
>It seems like a decent compromise for
In article
<553d43c8d961c14bb27c614ac48fc0312811f...@umechpa7d.easf.csd.disa.mil> you
write:
>-=-=-=-=-=-
>
>Even for .mil, the vast majority of email domains are fairly short with four
>or fewer labels. Most of the other ones tend to be
>individual servers that send automatic performance
In article you write:
>-=-=-=-=-=-
>
>
>On 11/22/20 11:18 AM, Douglas E. Foster wrote:
>> ARC has a very limited set of items included in the signature.� �Body
>> hash is purposefully excluded.� So it is the same signature algorithm
>> but with different parameters and a different purpose.�
Count| Bytes | Who
++---
13 (21.3%) | 122003 (18.5%) | Murray S. Kucherawy
10 (16.4%) | 208118 (31.5%) | Doug Foster
8 (13.1%) | 39471 ( 6.0%) | John Levine
6 ( 9.8%) | 105091 (15.9%) | Todd Herr
4 ( 6.6%) | 13999 ( 2.1%) | Dave
In article
you write:
>Someone in DNSOP, I think, proposed doing the tree walk in the other
>direction.
Turns out that won't work because here's what you'd be checking:
> _dmarc.paypal.com
> _dmarc.baz.paypal.com
> _dmarc.bar.baz.paypal.com
> _dmarc.foo.bar.baz.paypal.com
You can have a
In article you write:
>If I'm a receiver who is going to be making some filtering decisions
>based on ARC, I see that it passed by some authenticator along the way
>which is fine, but my question is why I should trust that intermediary
>in general?
The short answer is that you shouldn't, any
In article
<553d43c8d961c14bb27c614ac48fc03128116...@umechpa7d.easf.csd.disa.mil> you
write:
>Section 2.7. defines a non-existent domain as "a domain for which there is an
>NXDOMAIN or NODATA response for A, , and MX
>records. This is a broader definition than that in NXDOMAIN [RFC8020]."
If we're going to refight the DBOUND battle, here's another entry,
which even has running code. I see no reason to think that we are any
more likely to endorse one of these now than we were a few years ago
so I encourage the group to limit the debate to the existing Org/PSL
kludge and a tree walk.
In article
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 group.
I looked at it, seems fine as an experiment.
If we end up changing the way regular DMARC looks for Org domains, PSD
Count| Bytes | Who
++---
13 (18.6%) | 50703 (10.4%) | Dave Crocker
12 (17.1%) | 58169 (11.9%) | John Levine
7 (10.0%) | 83931 (17.2%) | Douglas E. Foster
6 ( 8.6%) | 2 ( 5.9%) | Alessandro Vesely
4 ( 5.7%) | 41496 ( 8.5
In article <903acb7d-847e-c87c-f21b-dcfa698bf...@wisc.edu> you write:
>You can't think of universities as single entities with central management
>authority. For the longest time our CS department owned
>wisc.edu and central IT had to ask them for permission to use it for
>campus-wide email.
I
In article <4266a992-7064-d8cd-660b-a3d1d4098...@wisc.edu> you write:
>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.
>
&
In article <5bc82960-70a4-3ce2-4e3d-a39dd9743...@wisc.edu> you write:
>If tree walking is a thing that comes to fruition, what does it mean for a
>domain to be an organizational
>domain (in reference to the idea that the DMARC spec will just point to
>another doc to determine the org
>domain)?
In article
you write:
>As another case, would people be surprised that email for the medical
>center cumc.columbia.edu is a separate system managed by a separate IT
>group from columbia.edu, and that any authentication for one should not be
>applied to the other? I don't think this is unique in
In article <03758d8d-a4d7-3f9d-bc0c-3ee404fc5...@dcrocker.net> you write:
>On 11/11/2020 8:58 AM, John R Levine wrote:
>> Except that if we do a tree walk, I don't think we'd call that the
>> Organizational Domain any more.
>
>What would you call it?
"Parent default" or something like that.
In article
you write:
>This actually makes sense because there are other potential documents/uses
>besides DMARC that could reference PSL-type mechanisms.
Remember that this is a well-known swamp of despair. We had a whole
DBOUND working group that failed to define a PSL-like thing.
I am
we should remove the rule about what order the tags appear.
R's,
John
--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
_
%) | Todd Herr
2 ( 7.1%) | 20065 (10.2%) | Jim Fenton
2 ( 7.1%) | 13227 ( 6.7%) | Alexey Melnikov
2 ( 7.1%) | 7310 ( 3.7%) | John Levine
1 ( 3.6%) | 9730 ( 4.9%) | Seth Blank
1 ( 3.6%) | 8573 ( 4.4%) | Tim Wicinski
1 ( 3.6%) | 6156 ( 3.1%) | Dotzero
1 ( 3.6%) | 5744 ( 2.9
In article <15f9054f-f32c-4be7-a812-79d7754c5...@www.fastmail.com> you write:
>The idea is that we are starting from adopting a known document in a known
>state, which will take less time than
>discussing 3 adoption calls of documents that are nowhere ready for the WG to
>review.
Sounds good to
%) | Alessandro Vesely
1 (16.7%) | 2781 ( 7.6%) | John Levine
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Count| Bytes | Who
++---
4 (28.6%) | 83728 (58.4%) | Brotman, Alex
3 (21.4%) | 14615 (10.2%) | Simon Ser
2 (14.3%) | 12832 ( 9.0%) | Murray S. Kucherawy
2 (14.3%) | 8763 ( 6.1%) | John Levine
1 ( 7.1%) | 10823 ( 7.6%) | Dotzero
[ Replies sent to ietf-822 since this is unrelated to DMARC ]
In article
you write:
>I've submitted a draft for a new Authentication-Results method a while
>back [1]. I'd like to get some feedback.
>
>My use-case is: on a mailing list system [2], I'd like to display PGP
>signature status, if a
Thompson
1 (11.1%) | 8810 (10.3%) | Hector Santos
1 (11.1%) | 7592 ( 8.9%) | Alexey Melnikov
1 (11.1%) | 2813 ( 3.3%) | John Levine
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Count| Bytes | Who
++---
3 (25.0%) | 13231 (10.2%) | John Levine
2 (16.7%) | 26570 (20.5%) | Douglas E. Foster
2 (16.7%) | 23416 (18.1%) | Jesse Thompson
2 (16.7%) | 8551 ( 6.6%) | Alessandro Vesely
1 ( 8.3%) | 33575 (25.9
In article you write:
>> The bar for ARC to be usable is pretty low. It's not "doesn't send
>> spam" or even "knows who its users are." It's only "doesn't lie about
>> where mail came from." I expect that in practice the usual DNSBLs
>> will be good enough.
>
>Is the assumption with ARC, when it
In article <1265372281.9984.1601969016...@appsuite-gw1.open-xchange.com> you
write:
> It would be much better if there were a few professional/community efforts to
> build reliable and complete lists of good
> and bad ARC intermediaries, like for spam.
Having tried and failed to build a
%) | 8459 ( 1.7%) | John Levine
1 ( 1.6%) | 7434 ( 1.5%) | Murray S. Kucherawy
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
In article <4004580.HQKp4RnRq6@zini-1880> you write:
>I don't think this his helpful. If something like this is going to be
>standardized, it shouldn't be called DMARC because it's not.
We (the generic we) seem to have a fundamendal disconnect about what
DMARC is for.
One group appears to
Count| Bytes | Who
++---
8 (13.8%) | 105682 (21.6%) | Seth Blank
7 (12.1%) | 45638 ( 9.3%) | Scott Kitterman
7 (12.1%) | 35318 ( 7.2%) | Dave Crocker
5 ( 8.6%) | 85113 (17.4%) | Douglas E. Foster
5 ( 8.6%) | 21680 ( 4.4%) | John
In article you write:
>On 9/26/2020 5:55 AM, Douglas E. Foster wrote:
>> but you apparently choose not to hear.
>
>
>that's an ad hominem.
>
>Chairs?
I thought he was already in everone's kill file.
___
dmarc mailing list
dmarc@ietf.org
In article
you write:
>> It is desirable to have logically distinct disposition responses, and if
>> so, what should be reported in the latter case? As a straw man, "pass"
>> instead of "none"?
>
>Given the choices, I like "pass".
Agreed. That's what my code did until I realized it was
%) | Sabahattin Gucukoglu
2 ( 9.5%) | 9262 ( 5.0%) | Alessandro Vesely
2 ( 9.5%) | 7723 ( 4.2%) | John Levine
1 ( 4.8%) | 15078 ( 8.2%) | Ken O'Driscoll
1 ( 4.8%) | 9022 ( 4.9%) | Dotzero
1 ( 4.8%) | 5498 ( 3.0%) | Kurt Andersen (IETF
person in charge said words to the effect that I know this
will screw up everyone's mailing lists and I don't care.
R's,
John
--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment bef
4 | 106009 | Doug Foster
4 | 68673 | Murray S. Kucherawy
3 | 13432 | John Levine
1 | 16031 | Dotzero
1 | 15075 | Brandon Long
1 | 5033 | Alessandro Vesely
1 | 2320 | Role account
___
dmarc mailing list
dmarc@ietf.org
https
see most of them have been there at least since
2016.
--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
dmarc mailing
hat SPF/DKIM can't describe."
--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
6 | 83178 | Douglas E. Foster
3 | 15719 | Alessandro Vesely
3 | 15580 | John Levine
2 | 30553 | Jesse Thompson
2 | 22291 | Murray S. Kucherawy
1 | 5592 | Rolf E. Sonneveld
___
dmarc mailing list
dmarc@ietf.org
https
ely damage from allowing wisc.edu to forward seems pretty
low, the damage from outlook.com or gmail.com considerably more.
R's,
John
--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. h
In article <46d35938-50ee-871d-d88b-e93c68555...@bluepopcorn.net> you write:
>But what I was getting at is that the "weak" signature might not have to
>be any different from any other DKIM signature (except possibly to
>specify the authorized mediator). It's just that a verifier might fully
In article you write:
>> If the list is somel...@lists.foo.org, does the signature have to be
>> d=lists.foo.org? How about d=foo.org?
>>
>This seems like an analogous situation to the DKIM i= flag, where the
>domain MUST be the same as, or a subdomain of, the value of the d= flag.
>So I'd
In article
you write:
>> message. If the intermediary DKIM signs the modified message with their own
>> signature, that provides some assurance to the receiver.
>
>You mean like https://tools.ietf.org/html/draft-levine-dkim-conditional-00?
>
>I'm pretty sure that got implemented too, but I can't
17 | 180845 | Dotzero
16 | 101029 | Alessandro Vesely
10 | 54554 | John R Levine
10 | 52421 | Dave Crocker
7 | 82320 | Murray S. Kucherawy
7 | 79120 | Jesse Thompson
6 | 91131 | Douglas E. Foster
5 | 117191 | Laura Atkins
4 | 46484 | Brandon Long
2 | 54558 | Todd
501 - 600 of 918 matches
Mail list logo
