In article <974c2d00017358cdf3b78037e4276234db2cfdee.ca...@aegee.org> you write:
>Hello John,
>
>On Sat, 2019-01-26 at 11:31 -0500, John Levine wrote:
>> … The failure reports are almost
>> entirely useless. Of the ones I get, the majority are random Chinese
>> s
In article <6596039.Rh8MxG5e5K@kitterma-e6430> you write:
>The current PSL is over 12K lines long. What we're talking about here is
>probably .1% to 1% that size.
Indeed, but since everyone has the PSL anyway to find organizational
domains, who cares about the size? The point of asking the PSL
In article you write:
>Hello John,
>
>DMARC reports for p=none are not supposed to be useful, as they do not depend
>on the policy.
Sorry, but that assertion is completely wrong. Please see RFC 7489.
>If the question is about how to get reports on failing DKIM validation only on
>unexpectedly
In article
you write:
>> Does anyone have any issues to raise with draft-ietf-dmarc-eaiauth?
>> If I don't see anything within the next week, I will hit the "request
>> publication" button in the datatracker.
I have a version that fixes a few typos and has a new paragraph pointing
out that DKIM
In article
you write:
>-=-=-=-=-=-
>
>If a sender's IP is in SPF, so SPF passes; and the applied DKIM signature
>is successfully decrypted, so DKIM passes; what good is checking alignment
>and rejecting a message?
The short answer is that bad guys can publish SPF and DKIM just as
well as good gu
In article <002a01d4de81$18ac27b0$4a047710$@bayviewphysicians.com> you write:
>Can one of you elaborate on the potential connection between PeP and DMARC,
>or more generally, the connection beteen PeP and spam filtering?
I presume that PeP would make spam filtering much harder since the filters c
In article <3bebe973-0536-96cd-983e-240ba4346...@dcrocker.net> you write:
>Comments eagerly sought, of course.
This seems sorta kinda like my dbound draft, only with _tagged TXT
records rather than a new rrtype, and (unless I missed something) a
hope that somehow you can use a yet to be invented c
In article <14007257.XvzNgCV7GG@kitterma-e6430> you write:
>There's no change in security considerations because there's no change in the
>protocol. We're merely more clearly documenting the interaction. I'll leave
>it to the chairs/author/shepherd to decide how to respond to the discuss, but
In article you write:
> The problem:
> Spammers use non-existent domains to achieve identity spoofing, such as
>tax.example.gov.uk
> This is primarily a reception problem, because many recipient mail filters
>are not equipped to block this type of fraud. ..
Right, and we can stop right t
In article
you write:
>This neglects the benefit to the domain operators of receiving the reports
>about abuse of their domain space. For the end recipient of the bogus
>traffic, there is no difference.
I agree that the reports are useful, regardless of the policy.
I just wish we could figure o
In article <155486669171.19715.14014281020759221500.idtrac...@ietfa.amsl.com>
you write:
>I agree with Benjamin's DISCUSS comment: this document needs to better
>explain the consequences of the inability to match %{s} and %{l}.
It has no consequences at all. As Scott noted, it documents what the
In article you write:
>On 4/10/2019 8:37 PM, Scott Kitterman wrote:
> print(response.additional)
>> []
>Turns out that's what I was especially hoping to see.
As I understand it, your design depends on putting NXDOMAIN signals
in the additional section to show that there aren't any boundaries
>I took a look at the non-comment content of the public portion of the PSL to
>get an idea of the scope of this problem. Here's the distribution of lengths
>of public suffixes:
>
>one: 3077
>two: 3821
>three: 1986
>four: 3
I only see 1527 with no dot. Since there's only 1532 TLDs it's hard to
In article <5c2fc1da-ae7c-2efe-fda3-47855d61a...@bluepopcorn.net> you write:
>There are domains that would like to receive reports, but whose usage of
>mail doesn't make it useful to express a policy. Conversely, there are
>domains that want to express a policy but aren't interested in reports.
>I'
In article <20190523225213.c214620147b...@ary.qy>,
John Levine wrote:
>In article <5c2fc1da-ae7c-2efe-fda3-47855d61a...@bluepopcorn.net> you write:
>>There are domains that would like to receive reports, but whose usage of
>>mail doesn't make it useful to express
In article <20190525183556.horde.zvg1bnsybvs_enkzpkjl...@webmail.aegee.org> you
write:
>Consider this scenario: an email from a domain, with DMARC policy
>“p=reject; ruf=postmaster@domain” fails validation. A
>message-specific report is sent to postmaster@domain. The report is
>bounced (or
for them.
On the other hand, if I were a spammer, I would think your proposal
was great because it makes it a lot easier to probe and figure out
how your spam filtering works.
--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the
In article <20190526050958.horde.6vaaxrzkglqyej4uov0v...@webmail.aegee.org> you
write:
>Hello John,
>
>in case of modernwebsite.pl:
>
>DNS TXT _dmarc.modernwebsite.pl is "v=DMARC1; p=reject; pct=100;
>rua=mailto:postmas...@modernwebsite.pl;
>ruf=mailto:postmas...@modernwebsite.pl; aspf=s;adkim
t that you simply blackhole whatever IP their
bounces are coming from and leave it at that.
--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
ture anyway, if it does nkt trust
>the previous hop. Common case: aliases
>to random servers.
That would be my suggestion. You can put whatever you want into comments in
the A-R header.
--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Ple
ature, that is a rathole of no return. Also keep in mind that
malicious parties can change the signature, too, and there's no way
I know of to tell a malicious rewrite from a benign one.
ARC is designed to deal with this situation. Take a look.
--
Regards,
John Levine, jo...@iecc.com, Pri
ny more reports to that address during the next
hour, even if mail comes in that would get a report.
You can tune the time period and threshhold, but so long as the time
period is longer than a cycle of the mail loop, they don't matter
much.
--
Regards,
John Levine, jo...@iecc.com, Prim
Apropos recent discussions, we could recommend that failure reports be
rate limited per recipient both to break loops and to deter indirect
mail bombing.
--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment befo
Section 6.3 says that ruf and rua tags can take any URI, but only
define the meaning of a mailto: URI. Either it should define some
other URI schemes or it should say that only mailto: URIs are valid.
Back in the olden days there was an http or https scheme that we took
out because it was ill spe
In article you write:
>>>>>> "JL" == John Levine writes:
>
>JL> implement it. If people are interested in an https PUT scheme it
>JL> would be easy enough to define one,
>
>I find that the http POST scheme for TLSRPT works very well.
It looks s
net when you can
>or should know that they will fail validation.
Not to belabor the obvious, but the spec says what it says even if you
personally wish it said something else. The way to make systems
interoperate is to implement the actual spec.
R's,
John
--
Regards,
John Levine, jo...@i
In article <29174612-a051-8066-9dde-2afaf181c...@dcrocker.net> you write:
>The high-level point I'm trying to make is that control messages -- such
>as DMARC reports -- need to be handled in a fashion that works
>automatically and at scale. Since looping is a well-known problem for
>such messag
In article <0a8b5459-8a9a-7a5b-d169-4c183c43a...@tomki.com> you write:
>Examples:
>- raw SPF 'fail' should never result in DMARC-SPF 'pass'
>- raw SPF 'pass' out of alignment with header_from should never result
>in DMARC-SPF 'pass'
>- raw DKIM not being shown should never result in DMARC-DKIM 'pa
In article <7cd366d2-ab8d-cce8-67ff-59b79183c...@tomki.com> you write:
>As mentioned by Elizabeth recently: (Elizabeth please chime in if this
>doesn't capture your meaning)
>
>the spec does not define *which* DKIM signature should be reported in
>the DMARC RUA created by a receiver. The propos
>I concur. Does anyone know of such a policy statement from ICANN? I don't
>recall it being present in, say, any of the DNS RFCs, but there are so many
>of those now...
Hi from ICANN 65 in Marrakech.
The gTLD registry contracts say directly or indirectly what's allowed
in each TLD zone. Here's
I wasn't thinking this would go in the doc, just for background.
Autocorrectly,
John
On 27 Jun 2019 12:23, "Hollenbeck, Scott" wrote:
>
> > -Original Message-
> > From: dmarc On Behalf Of John Levine
> > Sent: Thursday, June 27, 2019 6:52 AM
&g
I wasn't thinking this would go in the doc, just for background.
Autocorrectly,
John
On 27 Jun 2019 12:23, "Hollenbeck, Scott" wrote:
>
> > -Original Message-
> > From: dmarc On Behalf Of John Levine
> > Sent: Thursday, June 27, 2019 6:52 AM
&g
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 is
>> over.
>>
>> Please review this one.
>
>Repeating what I
In article
you write:
>-=-=-=-=-=-
>
>On Fri, Jul 12, 2019 at 10:55 AM Kurt Andersen (b) wrote:
>
>> I am much more concerned with adding another tag that can only be used in
>> a PSD-DMARC record. I would be much more open to make a "normative" change
>> to the DMARC tag list (RFC 7489 section
In article <2902055.CzhLQO0xIX@l5580> you write:
>Here's the definition we have in the draft now:
>
>> 2.6. Non-existent Domains
>>
>>For DMARC [RFC7489] purposes, a non-existent domain is a domain name
>>that publishes none of A, , or MX records that the receiver is
>>willing to
In article
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 effect of the DMARC policy
>discovery mechanism described in DMARC [RFC7489] Section 6.6.3.
for
.pickle.deal. That's the way that organizational domains
work.
PSD lets you publish _dmarc.deal and have that apply by default to the whole
TLD,
.deal and ..deal and so forth.
R's,
John
--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies&
In article
you write:
>Most MTAs will also follow CNAMEs. Should they be included (along with
>other things like DNAME records) within the scope of existence? I'm a
>little concerned that we are making a special definition of "non-existence"
>which differs from the standard DNS concepts of NODATA
ication-Results:" authserv-id; method=result ptype.property=value
>ptype.property=value
I agree. We all put the DKIM stuff in comments but that's silly. If
it's worth recording, it's worth doing in a way that we all agree
about and can parse.
R's,
John
--
Regards,
In article you write:
>Current wording for p=quarantine
> quarantine: The Domain Owner wishes to have email that fails the
> DMARC mechanism check be treated by Mail Receivers as
> suspicious. Depending on the capabilities of the Mail
> Receiver, this can mean "place
In article <97b7d4320e77f9be84703677eba79686ec769f75.ca...@aegee.org> you write:
>Hello John,
>
>the "... reject at SMTP level" is at least for messages, directed to an
>address, which does not support the
>concept of
>quarantining.
>
>Please propose what shall a site do, receiving a message, subj
In article <009c01d54c69$39745520$ac5cff60$@leemankuiper.nl> you write:
>I've noticed that, even though RFC7489 appendix C states that the
>'envelope_from' element has a minOccurs of '1', this element is missing
>quite frequently.
It's not missing, it's empty. That's not the same thing.
R's,
Jo
In article you write:
>What is the purposes of the aggregate and non-aggregate reports? What are
>non-goals? I asked several times here,
>nobody answered. Perhaps a discussion on the goals and non-goal would help.
As far as I know, the point of DMARC reports is to help domain owners
understan
In article <682972a4-38e4-f5b2-3180-c5a03a3a0...@tana.it> you write:
>Looking at aggregate reports, you cannot tell whether an authentication failure
>is a sacrosanct signaling of your domain being abused rather than a legitimate
>user going through external forwarders.
Sure you can, you look at t
In article
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 approving this change based on a
>formal request. I'd rather at least see some consensu
In article
you write:
>https://datatracker.ietf.org/doc/draft-brotman-rdbd/
>
>which defines a mechanism where two domains can state they are related, or
>not related via DNS records.
>What one wishes to use this information is left to them.
>
>It would be great to get y'all giving feedback
If i
In article <79b1cbe6-8a53-9157-63de-210fd2bad...@dcrocker.net> you write:
>This goes to the essential challenge of a proposal like PSD. It
>embodies a particular model, in the absence of clarity about the model
>or broad-based discussion of its appropriateness. (Note, for example,
>that my rev
In article
you
write:
>So we could decide on doing a combinatory of #3 and #1, with the right
>mechanisms.
Publishing a list of PSD superdomains in the DNS is pretty trivial
using my dbound scheme, and should typically find out whether any name
needs a PSD check with one DNS query. The total z
ng else. I have running code
for a DNS lookup technique that does everything the PSL does without a
tree walk at https://github.com/jrlevine/bound
The problem is that we seem unable to agree on any PSL or not-PSL like thing.
R's,
John
--
Regards,
John Levine, jo...@taugh.com, Primary Perpetr
In article
you write:
> Since information about existing implementations gets removed as a doc
>passes through the editor's hands, I'm not sure why it would matter to
>update a section that will be removed.
Only if we ask them to. I don't see anything in the draft asking them to take
that secti
nizations that have
some administrative connection. The issue is people who publish A and
MX records without covering DMARC records. They're not supposed to do
that but they do, and PSD is one way of figuring out who needs to fix what.
R's,
John
--
Regards,
John Levine, jo...@ta
In article you write:
>Hello DMARC working group,
>
>I am going through the changes between RFC7601 and RFC8601 and try to
>understand the implication of the change introduced by erratum 5435.
>The new resinfo definition uses 1*propspec, that is, by my understanding
>of [1] and [2], potentially mu
In article you write:
>>> Every implementation I know puts space between multiple propspec's
>>> which the current syntax wouldn't allow
>> my understanding was that RFCs decide whether an implementation is
>> incorrect or in the case of a series, not up-to-date. If the authors
>> decided to upda
In article you write:
> [SPF] on the other hand
>has an A-R example that is domain-name only, so I assumed that
>smtp.mailfrom in spf context was more loosely defined via RFC7001's
>pvalue (that is, with the optional local-part@).
I'm pretty sure the example is wrong, and was copied verbatim
In article
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 whether in 6532 or
>5322.
This is another mistake in the ABNF in 8601. The point of 6532 is
that with the exception of Message-IDs
In article <3295240.vh5t8hYAJM@sk-desktop> you write:
>> If you want it to be a domain, the ABNF should say:
>>
>> authserv-id = domain-name
>> This is not strictly backward compatible with the current text, but I
>> don't think I've ever seen an authserv-id which wasn't syntactically a
>>
ot necessarily
meaningful to users.
Note that in an EAI-formatted message, this identifier may be
expressed in UTF-8.
--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading th
In article
you write:
>I've definitely seen non domain-name based authserv-ids, but they are rare
>and tend to be from opendmarc. We can certainly fix that in opendmarc.
My proposal says they're syntactically domain names, not that they
actually have to exist in the DNS. What do those ID's look
In article you write:
>>I don't see any reason to exclude them. We could do this:
>>
>> authserv-id = sub-domain *("." sub-domain)
>>
>>Where sub-domain is imported from 5321 for ASCII mail and 6531 for EAI
>>mail.
>
>That does allow IP address literals. Do we want that?
No, take a loo
h has an x80 bit set in a
character in the header is an EAI message.
--
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
___
dm
In article you write:
>> The intention in 8601 is pretty clear, even though the ABNF doesn't agree:
>
>Yes, the RFC says the authserv-id can contain UTF-8, but its author
>stated that he intended it to be "either a plain old ASCII domain name
>or an A-label". One does not need UTF-8 for that. If a
In article you write:
>"If the authserv-id is UTF-8, then it might be UTF-8"
Yes.
>This seems equivalent to
>
>> authserv-id = sub-domain *("." sub-domain)
>>; Where sub-domain is imported from 6531 for
>>; any mail
No, it's 6531 for EAI messages, and 5321 for ASCII messages.
EAI and A
In article you write:
>> authserv-id = sub-domain *("." sub-domain)
>>; Where sub-domain is imported from 5321 for ASCII mail
>>; and 6531 for EAI mail.
>
>, given identical input, disagree on the validity of the A-R header of
>that input. Can you please show an example?
It's the one you
In article <5c650beb-f0b7-5cae-3070-b7005dec9...@arcsin.de> you write:
>> It's the one you found. If the authserv-id has a non-ASCII UTF-8 character,
>> it's invalid under 5321 and valid under 6531.
>
>I thought we established that as soon as the authserv-id has non-ASCII
>UTF-8 characters, the ma
In article <4013d967-852c-e299-0973-03ba21db5...@arcsin.de> you write:
>Ok, that is definitely an external factor, isn't it? The information, if
>the system which processed the email, handles EAI, is not contained
>within the A-R header. Is the information even available in the DATA
>portion of an
In article <6b4c7533-ebee-796b-e00e-a2bb40750...@arcsin.de> you write:
>To decide for an authserv-id whether to pull sub-domain from 5321 or
>6531, one needs to know if the message is internationalized. But to
>obtain that information, one must have parsed all message header fields,
>per 6531 sec 3
In article <1904862.B7rBbPpL6e@sk-desktop> you write:
>> Scott, please prepare a new version of the I-D based upon your comments,
>> but don't post it until IETF Last Call finishes and all other feedback, if
>> any, has been folded in.
>>
>> Seth, as co-Chair
>
>Done. The updated version (XML, te
In article you write:
>> this specification MUST delete any discovered instance of this header
>> field that claims, by virtue of its authentication service
>> identifier, to have been added within its trust boundary but that did
>> not come directly from another trusted MTA.
>
>In my opinion, a h
In article
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. Other than
that I don't have much idea either. On my system my mailing list software
looks at it them to decide how much DMARC hackery
In article
you write:
> 1. ".co.uk" is not a TLD. TLDs are single label domains - there are
> ccTLDs and gTLDs.
Right.
> 2. The invocation of the PSL compounds the issue that was raised by Dave
> Crocker. How DMARC (RFC 7489) determines the organizational domain is
> orthogonal to thi
>Dale twice in his comments expresses doubt that it's possible for anyone to
>know all PSDs; the mention of a specific PSL in the abstract was an attempt
>to answer those doubts.
This kind of stuff drives me nuts since it suggests the reviewer isn't
familiar with all of the other stuff that has th
In article
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 (PSD)?
R's,
John
___
dmarc mailing list
dmarc@ietf.org
https://www.iet
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 this into a proto 7489bis.
I agree. Hence my suggestion l
In article <2656238.kvSPeydUtl@sk-desktop> you write:
>There is probably protocol improvement work that should be done based on:
>
>https://www.usenix.org/system/files/sec20fall_chen-jianjun_prepub_0.pdf
I didn't see any protocol issues other than the well known DKIM
multiple From: headers (the Do
In article <51be5654-94c4-38c6-8f6b-dca403d66...@dcrocker.net> you write:
>The paper has a simplistic model of email anti-abuse processing and this
>distorts some of its analysis. At the least, the paper needs to
>distinguish between theory and practice.
Yup.
>> SPF implementations treat “(a..
In article <3457203.qin9KRflZP@sk-desktop> you write:
>> Should we make it invalid to have p=none without a reporting address?
>
>I'll bite:
>
>No.
>
>This is unrelated to interoperability and unlikely to actually improve
>anything (this reminds me of the occasional suggestions to make v=spf1 +all
f junk to see of a v= tag is in there somewhere.
Other than that I agree there is no reason to specify the order of
tags.
--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the enviro
In article
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 existing XML so adding more options just adds more
complexity with no more function.
Apropos ticket #29 we might consider resu
In article
you write:
>+1, unless there are known cases where the XML payload size is a problem
>that switching to JSON would solve.
It's gzipped, do I doubt it would make much difference. Gzip is really
good at compressing the boilerplate strings that make XML bigger than
JSON.
Also, FWIW, in
In article you write:
>https://dmarcian.com/domain-checker/ test it there
You're misreading what it says. The DMARC setup is fine.
>if its complete impossible to not break dkim i will leave this maillist
After you leave, you might want to review the ARC work we've been
doing over the past year
In article <492288f0-3fc3-f85e-26c0-eda418de6...@tana.it> you write:
>Since receivers have to verify report correctness and trustworthiness, /they/
>deserve the right to decide what language they want reports to be written in.
There is lots of freely available code to parse DMARC XML reports and
p
In article you write:
>> I suggested they make a few changes which they have now done: there is
>> now an explicit _dmarc.dmarc.ietf.org TXT record, and there is an MX
>> record pointing at the mail server rather than A/ records.
>
>spamassassin still says dkim invalid here
Yes, that is corre
In article <0127a137400d466095373373ec887...@bayviewphysicians.com> you write:
>This example is a reminder that every message is a take-it-or-leave-it
>proposition. You can accept
>the message or reject it, based on the message characteristics, but you will
>probably be unable to
>cannot change
w
that I do, I don't think anything simpler would do.
In particular, anything that lets you say "I'm a mailing list" is out
since spammers can do that too. Also, real mailing lists tend to have
lousy spam filtering and leak a lot of spam, so you can't just
whitelist ev
the From: comment, viz. Jim's question.
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
___
d
In article <14fe18acad53467a8027e680dfc10...@bayviewphysicians.com> you write:
>-=-=-=-=-=-
>1) The original assertion, that DMARC creates a conflict with prior
>specifications, appears to be undefended and incorrect.
It should not be controversial that DMARC can only describe a subset
of valid I
In article <46e045ae-9691-4f5b-86bf-142c06645...@www.fastmail.com> you write:
>-=-=-=-=-=-
>
>On Sun, Jun 7, 2020, at 9:16 AM, Douglas E. Foster wrote:
>> 3) Some of the discussion has been about how to prevent soclal engineering
>> of the recipient user. This is an important
>topic, but not direc
In article <71cddc80-008c-4f33-bdac-71ebc029b...@www.fastmail.com> you write:
>I didn't know the history of the IETF's approach to UI, in particular, but I'm
>aware of the research on the nastiness of
>solving the UI problem. I mostly wanted to clarify that the problem is,
>indeed, *how* to show
In article
you write:
>-=-=-=-=-=-
>
>https://trac.ietf.org/trac/dmarc/ticket/38
>
>The spec is ambiguous about which DKIM key needs to be reported.
>
>The real world problem here is that sometimes the DKIM key(s) which are
>reported in a row of an aggregate report have nothing to do with the DKI
In article
you write:
>-=-=-=-=-=-
>
>https://trac.ietf.org/trac/dmarc/ticket/66
>
>Many different entities participate in DMARC, and to each, there is a
>different definition of what is needed to "implement" or participate in
>DMARC.
I would rather put this in a separate non-normative BCP.
>Th
tor
>which, in combination with the signing domain, tells one where to find the
>record in DNS?
Sorry, domain and selector.
R's,
John
--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading t
erable
evidence that they don't.
We're not saying that users are stupid, beause they aren't. But we are
saying that their intuitions about how to treat their incoming mail
are a poor match for the reality of what's in the mail.
--
Regards,
John Levine, jo...@taugh.com, Primar
In article <3d6f24c7-113d-a096-305e-1490c920c...@gmail.com> you write:
>On 6/8/2020 11:18 AM, Scott Kitterman wrote:
>> I was trying to suggest that the topic of this ticket (defining conformance
>> requirements) should wait for a BCP
>and that as a separate topic the terminology should be fixed i
In article you write:
>So does anyone have any that the are willing to share? They will end up on
>github so please remove any PPI or anything confidential from them.
I have 80,000 of them but most of them are copies of actual messages people sent
to mailing lists, so no such luck.
Publish a DM
In article <45af2d9b-a2d9-4d5c-b1fd-aae906d3a...@kitterman.com> you write:
>Which still leaves the question of what the value proposition is since
>if you trust the source, what more does ARC really do (I suspect that
>the answer is more tokens to run through your bayesian or whatever
>filter)?
Wh
In article you write:
>I suggest that the "Mailing List Problem" is a problem that does not need to
>be solved (and evidence suggests that it cannot be solved.) I
>can think of no purpose served by a public mailing list, like this one, which
>is not be better solved by a community forum websit
In article <2bf78d7529ba4c5e935315d767783...@bayviewphysicians.com> you write:
>The "mailing list problem" was introduced into this discussion as an objection
>to DMARCs
>progresss, by implication suggesting that DMARC must be delayed until a
>solution is found which
>creates no inconvenience to
f bad guy, I would take the two seal ARC chain
from a message from a virtuous sender, replace the message body and
>From and Subject line with my spam, add a fresh new i=3 seal and blast
it out. That ARC chain is 100% valid, even though the messsage is
spam.
That's why (as Kurt knows) you on
new bright ideas, let me know and I'll send you a
password so you can update the wiki.
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
___
In article <1ef0572d-a83c-ad97-9c0d-5f5615ab1...@wisc.edu> you write:
>On 6/15/20 2:33 AM, Alessandro Vesely wrote:
>> Let me quote a list of nineteen usable solutions:
>> 1.2 Turn off all message modifications
>> 1.3 Replace address with a generic one
>> 1.5 Rewrite address
1 - 100 of 1002 matches
Mail list logo
