On Sat, 25 May 2019, Dave Crocker wrote:
2. Along similar lines, I get confused when I hear that x% of {some set
of domains} has "deployed DMARC". What does that mean? Have they
Ultimately, you are asking marketing questions, not technical ones.
Right. It's easy enough to imagine soemone han
I'm getting the impression that what we need is a non-normative
deployment guide, not as part of the spec.
Although Section 8 of the spec currently has normative requirements for
implementations. Yes, that's different from deployment but having those
requirements to implement something that isn'
On Fri, 24 May 2019, Jim Fenton wrote:
I hope this isn't devolving into a "we can't make any changes, because
it might break something" argument.
I don't think so, but we also have a tradition of minimizing the changes
to what's needed. Look at RFCs 2821 and 5321 for example, where they
deli
MTA-STS and TLSRPT started out as one document as well, and separated
quite cleanly IMO. I'm not sure what kind of incompatibilities you think
might be created.
That's because they separated before they were published, so there was
nothing to be incompatible with. If I knew what would break wh
You may recall that we've been discussing ways to publish DNS authority
boundaries, like the Mozilla PSL but in the DNS itself, not a text file.
I've been claiming that with careful use of wildcards one make the number
of lookups depend on the number of boundaries, not the number of labels
in
As I understand it, your design depends on putting NXDOMAIN signals
in the additional section to show that there aren't any boundaries
between the names it returns. How do you plan to do that?
John, I don't understand your note.
In draft-dcrocker-dns-perimeter-00, it says this:
Another
Since bad email filters are the problem, why is there no IETF working
group to define the expected behavior of email filters?More
importantly, can we start one NOW?
It's kind of outside the IETF's expertise -- there are people in the IETF
(not in this WG) who believe that DNSBLs were a fail
(One thing I'll pick at that I missed before, John: The phrasing
"SHOULD do X but MAY do Y" doesn't really work: taken strictly, the
MAY weakens the SHOULD. I would take the second key word out, and say
"SHOULD do X but Y is permitted .")
OK, fixed that and Ben's catch of a dangling section re
On Fri, 5 Apr 2019, Benjamin Kaduk wrote:
The whole premise of rigorous specifications is that anyone can jump in to
the ecosystem and implement something that interoperates, and in my opinion
the current presentation is not very accomodating to such a participant.
We seem to have a fairly basi
On Fri, 5 Apr 2019, Benjamin Kaduk via Datatracker wrote:
I'm not sure I fully understand the security consequences of causing
the SPF macros %{s} and %{l} to never match when the local-part contains
non-ASCII characters, but they seem potentially quite bad. That is, if
the policy is intending t
On Wed, 3 Apr 2019, Dave Crocker wrote:
Now, about /end to end/ support, not just publishing...
Please provide some examples comparable to your proposed use case. That is,
what are new RRs that are getting well-scaled, on-going use, defined in say
the last 5 years?
There aren't many other t
On Wed, 3 Apr 2019, Dave Crocker wrote:
Section 7's suggestion for using Additional information does not rely on
caching.
Reliance on existing wildcard depends on propagation of a new RR, which
continues to be problematic. There's a reason the Attrleaf table has so many entries...
Now we're
On Mon, 25 Mar 2019, Leif Johansson via Datatracker wrote:
The one issue I have is that the security considerations section claims
that the proposed changes attempts to mitigate some security issues
in email involving SPF, DMARC and/or DKIM but it is not obvious (at
least not to me) exactly what
On Mon, 25 Mar 2019, Benjamin Kaduk wrote:
Maybe I should just take that out. The only issue it mitigates is that
it makes DKIM and DMARC checks on EAI mail more reliable.
That seems important enough to state explicitly.
OK, added a sentence.
Regards,
John Levine, jo...@taugh.com, Taughanno
IMHO, by cutting out direct domain spoofing, DMARC makes it easier for
receivers to craft algorithms that spot impersonation attacks.
I realize that's the theory, but do we know how well that works in
practice?
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please
DMARC has never been an anti-spam scheme. It's about phishing, which is
not the same thing.
I'm going to have to disagree with you John. DMARC is about preventing
direct domain abuse. It does not specifically address phishing as the bad
guys can simply use cousin domains, homoglyphs, etc.
Wel
But if the AIM is to have an end to end easier to implement encryption +
phishing protection, probably it would make sense?
Not really.
This will not reduce the SPAM but using DMARC and properly tune the
policy P=reject; pct=100 would help to secure the content and reduce the
phishing, (and s
On Wed, 20 Mar 2019, Bernie Hoeneisen wrote:
I presume that PeP would make spam filtering much harder since the filters
can't look inside the messages.
This is a mutual challenge of email systems that use true end-to-end
encryption. While those improve Privacy, spam mitigation means need to
On Mon, 11 Mar 2019, Tim Evens (tievens) wrote:
I should have been more clear. This is NOT specific to HTML/HREF rendering.
Section references to an RFC without the RFC mentioned is misleading. For
example:
" DMARC [RFC7489] defines a policy language that domain owners can
specify for the
A related point ...
The draft currently says it updates RFC 7208, but is that right? It only
explicitly documents what's already defined there. Should that be removed?
It does say that matching a UTF-8 local part fails, which is new.
If you write code the way I write code, a current impleme
Would you care to post that version? The nits check is whining about some
out of date refs and one down level citation.
Done.
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
__
Is there really a benefit in filtering out people/organizations that are
not fastidious in the use of whitespace and character case?
Maybe, but that's not what standards are about. The point of a standard
is to say here's what you do if you want to interoperate. I have never
found it product
The ABNF rule I included, and the one that cites it (dmarc-record) do not
show any white space permitted before the 'v', so no it's not legal.
Ah, now that I look at it again, I see that the dmarc-record rule is the
one that matters here, since it allows WSP after the version but not
before.
The formal specification is quite clear on both of your questions:
Section 6.4:
dmarc-version = "v" *WSP "=" *WSP %x44 %x4d %x41 %x52 %x43 %x31
which means that the white space is required to be allowed and the value in
this tag-value is case sensitive.
Thanks, but the white space in
On Wed, 12 Dec 2018, Dave Crocker wrote:
The source of the pressure is that the cost of a queriable registry is high.
Very, very high. So creating one needs to have a very compelling
justification. I don't see how this one comes close.
Seems that way to me. Even if it's distributed by DNS,
On Wed, 12 Dec 2018, Dave Crocker wrote:
we used a DNS scheme like my DBOUND one, whoever runs the DNS policy
server can see all the queries and will have some idea of the mail
traffic from various names. This approach doesn't have that problem.
1. Doesn't the query to the registry suffer t
Agree with John but from the dns side, simpler solutions tend to get traction
faster.
John May agree with that.
Sure. My DBOUND approach was pretty simple, using no new rrtypes or other
magic.
From my high tech gadget
On Nov 8, 2018, at 15:47, John R Levine wrote:
On Thu, 8 Nov 2018
On Thu, 8 Nov 2018, tjw ietf wrote:
I remember the two hog mentioned but there could of been a third.
At this point I can't find any of the drafts other than mine, and a
problem statement mostly by Andrew Sullivan.
In any event, I agree it's worth having the WG take a whack at this,
keeping
On Mon, 5 Nov 2018, Brandon Long wrote:
If it does work, I'd be a surprised. Most likely, it'll fail validation
prior to full parsing (we extract the i= first, and only fully parse all
the k=v pairs later).
Also, does that mean you have to use the same algorithm in both the AMS and
AS for a giv
On Fri, 2 Nov 2018, Kurt Andersen (b) wrote:
I mean ARC as it's implemented now, not in our multi-signing draft.
It seems like a poor implementation choice to be enforcing something which
is not part of the spec :-), especially when there are parenthetical
comments and references to things like
It seems like a poor implementation choice to be enforcing something which
is not part of the spec :-), especially when there are parenthetical
comments and references to things like ARC-MULTI to warn you against
leaping to foot-shooting enforcement choices.
Here's what the spec says:
3. Va
On Fri, 2 Nov 2018, Kurt Andersen (b) wrote:
With the current spec, if you have two AMS or AS with the same i=
that's invalid,
No, it is not invalid.
I mean ARC as it's implemented now, not in our multi-signing draft.
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg N
On Mon, 20 Aug 2018, Kurt Andersen (b) wrote:
No, by subsequent I mean intermediaries who handle the message after the
point of initial "oh, this is broken" determination. So if I'm the 5th
intermediary (let's assume that all are ARC participating for this
discussion), and the chain on the messag
I'm still at a bit of a loss as to how one can effectively do a "greedy"
seal over a broken chain in a deterministic fashion.
I've been discussing this with Seth. Particularly once we start doing
parallel chains for different algorithms, different implementations will
disagree about what's a
On Wed, 15 Aug 2018, Dave Crocker wrote:
This is a very different kind and degree of vague (and without precedent, I
believe (unless someone can point to operational experience on the net that
is similar?)
I believe there are lots of trace fields that don't have a concrete use.
I am not famil
On Wed, 15 Aug 2018, Dave Crocker wrote:
Modest, indeed. Also unknown.
This is building in a permanent behavior, for a use that is, at best, vague
conjecture.
Well, sure, but we could say that about all of ARC. As far as I know
nobody has any rules yet for evaluating ARC chains beyond "if
I know I lost the argument on cv (I think cv is entirely superfluous and
there's no point adding/signing a cv=fail header), but it seems the
argument for that is more data. That said, this "either or" signing set
thing on cv=fail seems pretty cumbersome.
You guys have looked at as many ARC sign
I was updating my EAI-izing draft for DKIM and DMARC and realized that it
would be nice not to have to update ARC, too.
The gist of it is the same as what I said for DKIM: anywhere there's a
domain name there can be an IDN written with U-labels (Unicode), and
anywhere there's user text, the te
The working group considered cv=invalid last year, but there was strong
consensus was against it. The guidance for Sealing cv=invalid Chains
somehow made it into this draft applied to all cv=fail Chains. All Chains
should be Sealed in the same fashion (your AS covers the ARC Set you've
added and a
In authentication service identifiers in EAI-formatted messages, a U-label
and its equivalent A-label are considered to be the same.
Does that mean the proposed change is appropriate, or the current text is
sufficient?
I still prefer my proposed change. The way you handle A-labels and
U-lab
On Fri, Jul 27, 2018 at 10:24 AM, John Levine wrote:
The ARC draft clearly says that every ARC header can be signed by
whatever domain you want.
Are you saying we should proscribe it, because its semantics are unclear?
I'd say that all signatures in a seal SHOULD have the same domain, to m
There's a bunch of errata from the past year that are neither verified nor
rejected. Most of them look correct, suggest they all be hold for update.
Erratum 5229: adds some misssing default values to the report XML scheme.
Looks correct.
Erratum 5365: report filename .gz should be .xml.gz.
.
Ah. I still think it should go, but if you really want to do that, invent
a new enhanced status code. They're cheap. 5.7.7 isn't right, it's more
like corrupt S/MIME bodies.
R's,
John
--Kurt
On Thu, Jul 26, 2018 at 4:36 PM, John R. Levine wrote:
I agree, this is ou
I agree, this is out of place. Whether you reject at SMTP time is a much
broader topic than ARC failures.
On Wed, 25 Jul 2018, Seth Blank wrote:
https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-5.2.2
I am confused as to where this section comes from. It was never discusse
Something I noticed in a conversation on mailop.
-- Forwarded message --
Date: Wed, 25 Jul 2018 15:26:57
From: RFC Errata System
To: superu...@gmail.com, zwi...@yahoo-inc.com, rfc-...@rfc-editor.org
Cc: jo...@taugh.com, rfc-edi...@rfc-editor.org
Subject: [Technical Errata Reporte
An erratum on RFC7601 just appeared that reports a bug in the ABNF for the
resinfo rule. I think the purported bug is not a bug but his suggested
rewrite to the ABNF is cleaner than what's there now.
https://www.rfc-editor.org/errata/eid5435
Regards,
John Levine, jo...@taugh.com, Taughannock
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-rfc7601bis-02&url1=rfc7601
Looks OK to me. I have some minor editorial niggles about the wording
of the EAI advice, but the substance is fine.
In section 5:
For messages that are EAI-formatted messages, this test is done after
con
On Fri, 29 Jun 2018, Dave Crocker wrote:
Not at all. The point of a standard is to say here is what you do if
you want to interoperate. Trying to figure out how to recover when
someone else doesn't follow the spec is a fool's errand, since there
are more ways to misimplement a spec than any of
On Tue, 10 Apr 2018, Kurt Andersen (b) wrote:
Registries make RSEP requests all the time. They're tedious and fairly
expensive, but the process is straightforward.
Is this something that could be within the remit of the dmarc-wg if we
wanted to pave the way with ICANN across the board?
I bel
A friend looking at DNS traces says he's seeing a lot of queries like
this.
_dmarc.78.0x18.0143.0031
The numbers vary, some don't have the 0x. Any idea what it is? The
_dmarc suggest something thinks it's finding those domains on From: lines
but I'm having trouble imagining what it is.
I have now posted
https://tools.ietf.org/html/draft-andersen-historic-4406-etal-00 for this
task.
Please let me know if that fits the bill.
Looks good to me. I hope Dave remembers what the process is for a
document like this one. AD sponsored?
Regards,
John Levine, jo...@iecc.com, Primary
On Thu, 22 Mar 2018, Kurt Andersen (b) wrote:
That would probably be me, but I don't know what the local-part
problem is. My intention was to import the local-part changes from
the EAI RFC.
The problem has to do with the ambiguity that is being imported along with
those local-part ABNF changes
On Mon, 19 Feb 2018, Murray S. Kucherawy wrote:
Seems fine, although I've long found 7601 one of the most mysterious RFCs
ever published.
Why's that? (And why wasn't this mentioned when 7601 or any of its
antecedents was in last call? No errata?)
I admit I could have been paying more attent
Here's some stuff from my EAI authentication draft which it would be nice
if you could fold in.
Is this stuff in scope for this working group? This feels a bit like
feature creep.
Or should your draft just modify this one instead of RFC7601? The changes
are so small that this could go throug
Here's some stuff from my EAI authentication draft which it would be nice
if you could fold in.
In section 1.5, I'd add a section about EAI, pointing to RFCs 6530-2, and
saying that in EAI messages, you can have UTF-8 most places you can have
text intended for humans, and U-labels anywhere the
Read all about it:
https://datatracker.ietf.org/doc/draft-levine-appsarea-eaiauth/
This is an updated version of a draft I wrote two years ago, that tries to
nail down the small changes to SPF, DKIM, and DMARC in EAI messages. This
version adds a section for the Authentication-Results heade
I don't see the point of the header.ds field. We already have header.d,
so why not just add header.s?
If there are two DKIM validations, the A-R header will look like this, no
confusion I can see:
Authentication-Results: example.com; ...
dkim=pass header.d=foo.com header.s=abc; header.b="A
On Tue, 2 Jan 2018, Kurt Andersen (b) wrote:
I don't think this will be super complicated, but I do think it would be a
mistake to try and publish now and then retrofit rather than adding it
before we publish.
I agree (which is why I started off with the first draft that is currently
found in
I still don't understand why we need to say more than DKIM did on this
topic.
DKIM doesn't have a chain of signatures. With DKIM, a signature is either
valid or not, and you can ignore the ones you don't understand. ARC has a
chain of ARC seals, and the current document says there's only one
That is true, but it's also true that the standards track version of
EAI is fairly different from the experimental version, mostly by
leaving out a feature that didn't work in the field (downgrading.)
Does that mean going with "experimental" first was a good choice or bad
choice for them?
For
On Fri, 22 Dec 2017, Dave Crocker wrote:
3. Incompatible features: This is the interesting case, where the previous
and later versions have conflicting behaviors. My view is that this is not
merely a new 'version' but, rather, is a new protocol. However the protocol
itself -- not version -- ha
ensible in their namespace as
well.
Thanks again.
Ta.
I.
--
Dr Ian Levy
Technical Director
National Cyber Security Centre
Staff Officer : Kate Atkins, kat...@ncsc.gov.uk
-----Original Message-
From: John R Levine [mailto:jo...@taugh.com]
Sent: 20 December 2017 17:58
To: Kurt Andersen
SPF doesn't have sub-domain level protection like DMARC does, would it be
useful to look at adding it?
I doubt it. SPF was written and implemented a decade ago and it's
unlikely anything new would be widely deployed.
DMARC sub-domain level protection assumes that the owner domain isn't a
TL
On Wed, 20 Dec 2017, Kurt Andersen (b) wrote:
I need to be able to emulate in some way the effect of SPF and DMARC
records for non-existent first level subdomains under the PSL gov.uk - to
stop spoof mail apparently coming from them being delivered.
I'm quite sure that you will need to do this
So my thought here is that now that DCRUP is due imminently, we should
update the YANG test suite to reject SHA-1 hashes.
Thoughts?
That's what I would do. Given how new ARC is and the absence of legacy
code, I don't see any reason to allow them.
R's,
John
_
The devil will be in the details, I realise that.
Really, this is not a new idea. It doesn't work. Please go back and read
the archives from a decade ago when all of these ideas were considered and
rejected.
R's,
John
PS:
* Asking users to manage their own security settings doesn't work
I shall remove the reason of "security painting" by MUAs from the text.
What remains is automated content processing (spam filtering) which
still appears to be a sufficiently good reason on its own. It still
appears to me that most of the difficult cases can be remedied in the
proposed [but curre
On Fri, 29 Sep 2017, Rick van Rein wrote:
Thanks to John for reading the draft proposal.
Marking content in an MUA is a WKBI*. There is no reason to believe
that users would understand content marking or would make reasonable
decisions based on it.
Hmm. The idea was founded on the common rel
I just got spam from a couple of Virginia Tech students with an
impressively clueless "survey" about DKIM and DMARC usage.
If you got it, could you instead reply to their professor and the VT IRB
pointing out that scraping people's addresses from mailing lists is
unethical and, in many countri
On Wed, 24 May 2017, Dave Crocker wrote:
Unless there is a very compelling need for multiple A-R header fields -- and
I don't think I've seen that asserted -- then the simplest thing is to
declare them illegal and any occurrence of them as invalidating the
authentication mechanism(s).
There's
Seems reasonable, give or take a word or two to make it clear we're just
talking about the ones for the current hop.
There should only be the ones from the current hop if the admd is stripping
previously existing ones prior to adding any new ones per the authres rfc.
I meant not to use a-r wit
On Wed, 24 May 2017, Seth Blank wrote:
aft-ietf-dmarc-arc-protocol-03#section-5.1.3 :
"The AAR should contain all Authentication-Results results from within its
ADMD, regardless of how many Authentication-Results headers are on the
message."
Seems reasonable, give or take a word or two to make
Without marking the published key as obsolete, downgrade attack is
possible, because attacker can still use a weaker key to spoof
signature.
If you know how to spoof a sha256/rsa1024 signature, I know a lot of
people who would like to talk to you.
Other than that, please review RFC 6376. Ea
Does this initiative include an intention to update the cryptographic
guidance from RFC 6376 sections 3.3 and 3.3.3 ? The proposed charter
speaks of adding new algorithms, but doesn't discuss deprecating/removing
old ones.
We haven't decided yet. I'd think that'd be something DCRUP could
cons
Ok - nice to know I'm not the only one thinking this (means I'm not totally
crazy). I'm willing to drop my draft and just contribute/review this one.
There is no reason to have multiple drafts trying to do the same thing.
No, don't, we can moosh them together. I don't know much about elliptic
Should we add more hash algorithms?
As far as I know SHA-256 is still adequate for the forseeable future, but
I expect the crypto experts will weigh in. Ditto whether we really need
three new algorithms since the more ways there are to sign, the more ways
there are to have broken signatures.
I think tightening up some currently allowed ambiguity in the ARC
specification is a much simpler and much better solution. I'm not sure why
there's such concern about canonicalizing the format and ordering of some
tag/value pairs.
If you think that's all it would take to make signature headers
It's even more important than it was with DKIM to have a test suite that
can verify signing behavior. If we don't agree on any sort of standard, a
test suite will need to select a preferred format for the ARC headers &
will fail all implementations that don't meet this form. We've discussed
this
Signing one seems wrong, ie if the arc-seal only signs a single
arc-message-signature at a given hop, then the other signature can't be
verified, and if I can't handle the algorithm of the one that's covered,
then I can't verify the chain.
Currently away on a trip, I'll take a closer look when I
I see a rabbit hole here... So you're transitioning, so you sign twice (one
with your old, one with your new) before you send to me and hey, I'm
not the end point either, so I need to forward it along, but I'm also
transitioning, so I sign both of yours, twice? I would kind of have to,
wouldn'
Sure, with dkim. With arc, it's a bit more complicated, we need to
understand exactly how to sign the chain if there are multiple AMS and AS
headers. We probably want text about what happens if only one verifies as
well, and whether a hop should continue signing both paths or just one.
All quit
On Tue, 24 Jan 2017, Brandon Long wrote:
I'm not opposed to requiring support for different encryption algorithms,
but we really need to clean up and understand exactly how we handle
migration to a new algorithm, probably with a section in the draft specific
to it with an example.
Fortunately,
This sounds like something that we should definitely add so that there is
clarity, but it does add a situation where cv=unknown might happen if the
previous step only signed with an algorithm that was not understood.
Right -- you can't tell a signature with an unknown algorithm with one
that's
https://www.ietf.org/rfcdiff?url2=draft-kucherawy-dkim-rcpts-01
I forgot to update the title of Section 3, but other than that I think I
captured what's been discussed. Please let me know what I've missed.
How come rh= has one hash instead of several? You can put all the
addresses in the To:
- pick a random string S of length L using only printable ASCII characters
(I like 8 for L but that's arbitrary)
- SHA the string produced by prepending S to the recipient address, and
express the result in base64 string R
- include R in a new "er" (envelope recipient) tag and the salt S in an
"rs
The proposal creates redundant information and an especially awkward usage
restriction.
I entirely agree. Along with Ned's analysis of the various options, I
hope this is enough to persuade people that the correct solution to the
problem of signing spam for people to resend is Scott's: Don't
On 11/14/2016 10:00 PM, John R Levine wrote:
My version puts the recipient addresses into the DKIM-Signature header
Privacy violation.
You might want to read the rest of the message before responding.
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please
[ resent with a reasonably correct date header ]
I can write this up as a draft if people think it's interesting.
Murray's draft puts the envelope recipients into the DKIM hash, which
means that the message sent to multiple MTAs be signed separately for
each target MTA.
My version puts the reci
On the other hand, for purely transactional domains, it could be simpler for
the recipient to be able to easily find that ARC-ish mechanisms are not
authorized.
As is invariably the case here, except sometimes. It is my impression
that there are forwarders that break DMARC signatures (MS Exch
As John pointed out, RFC6376 requires that the signature not pass for any
"v=" value other than 1. It won't even get as far as considering the "!"
tags.
He said "most" implementations he checked will conform to that. I thought
it was "all"; perhaps he'd care to elaborate.
All the ones that an
Things get easier if you make the new feature optional, in which case
you don't need a version number...
If you can figure out how to make signature conditional on another with
without a version bump, that would be swell. I've been thinking about it
for over a year and so far this trick elude
I think at least the latter is a minor point since the XML source for
RFC6376 is readily available. I'm happy to pick up the editor pen again if
needed.
My concern is that once the can is opened, it's hard to keep some of the
worms from escaping.
There was a further rather theological argum
I think "!cd" is the only thing I changed. Here's my old comment about it
with some open issues mentioned, like "v=2" to which Dave objected:
https://mailarchive.ietf.org/arch/msg/dmarc/WQNRhqdUjM5Kut0BWzENx8aJSO8
I suppose the version bump to v=2 is an open issue, but I don't really see
what
I made a post some time back about changes I made in my implementation
versus the spec. I'll dig that up too. For one thing, I apparently
decided I didn't like the term "forward signature" and preferred
"conditional domain", so the new tag is "!cd". We can argue about that and
the other stuff w
I would expect conditional signatures to be applied by
large mail systems, using their private list of domains that look like
mailing lists to decide who gets them.
From the past couple of years of discussion, it is clear that all of
the large mail systems already have such a list of domains, s
Except of course for all of the people who don't look at all the crud in
their spam folder. They're not likely to write about messages they don't
see. If it's in the spam folder, for a whole lot of people it might as
well be discarded.
If a tree falls in the forest and your don't hear it, does
This is of course if the message is not spammy or contain a virus, or nasty
stuff like that, where the anti-spam filter may discard the message.
Except of course for all of the people who don't look at all the crud in
their spam folder. They're not likely to write about messages they don't
s
I'm mulling indeed about deleting the whole EAI stuff, because it is about
tangent policies around DMARC and not an interoperability issue per se.
Really, it's just wrong. Delete it, please.
I see the mailing list is focused on finding future solutions, not in
explaining current operational
> For this to work, you somehow need to persuade the real system to send
> you a signed message from the address you're planning to abuse. That
> seems like an implausible amount of work.
I agree it sounds like a lot of work. But I don't see why you would
bother attacking the resigning system a
My understanding is that the bad guys were stealing Yahoo address book
information and then mailing from OUTSIDE Yahoo to the recipients (not
Yahoo) claiming to be from the Yahoo user that they stole the address
book info from - thus the p=reject shutting the problem down almost
immediately for
301 - 400 of 461 matches
Mail list logo
