Someone I know asked me what sort of bad things could happen if one
published a broken DMARC record. Obviously, if your record is bad people
won't follow your policies and you won't get your reports, but anything
else? Have you ever heard of MTAs burping on a bad DMARC record?
I've looked
Null MX doesn’t stop anyone from spoofing your domain to send email though.
Yes, I know, I wrote the RFC about it.
SPF, DMARC are tools that work together to protect your domain and your
reputation. If SPF was the magic bullet then nothing else would be needed.
The basic problem with SPF is
By that logic if you have SPF -all you don’t need anything else to protect your
domain. Why even bother with DMARC at all?
As I said, if you don't send any mail at all, a null MX is useful but I
don't see much point to DMARC. It's not a magic bullet.
I suppose there are systems that look
That's the point though, even if you don't send email from a domain it should
have a SPF and DMARC record to prevent someone from spoofing your domain.
If you have SPF -all and a null MX, you shouldn't need a DMARC record.
Regards,
John Levine, jo...@taugh.com, Taughannock Networks,
On Fri, 31 Dec 2021, su...@banbreach.com wrote:
By planned changes, are you referring to draft-ietf-dmarc-dmarcbis-04?
Yes.
When you say this is not a bug, do you mean "this is not a bug in the RFC" or
"this is not a bug in the
dmarc checker tool"?
No. I mean that it is not a bug that it
On Mon, 31 Aug 2020, Brandon Long wrote:
Hmm, DMARC is for the header from domain, however, I wonder if folks
usually only do the spf lookup on the mail from argument, which may not
be aligned and therefore doesn't hit that.
And then how would this also play with say the Sender: header
My dmarc = v=DMARC1; p=reject; rua=mailto:dmarc_rep...@bexx.com;
ruf=mailto:dmarc_foren...@bexx.com; fo=1
Is this incorrect?
I wouldn't use p=reject but the syntax looks fine.
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before
While fiddling with scripts to analyze mta-sts reports, I noticed some
peculiar DKIM validation failures in reports from socketlabs. RFC 8460
which defines the reports says that mail reports have to be DKIM signed
and the DKIM validation key should say "s=tlsrpt" rather than the usual
s=email
On Wed, 17 Oct 2018, Alessandro Vesely wrote:
wildcard *.dmarc.fail addresses and they work fine. My mail server
knows what's been rewritten recently and rejects everything else.
Wildcard *.trailing.parts doesn't work, but is existent.
I have a wildcard MX for *.dmarc.fail pointing at my
On Sun, 14 Oct 2018, Al Iverson wrote:
other than to the mailing list or to the owner. If you've addressed
that, too, great, but it doesn't feel easy or scalable.
Of course we have. The rewritten address forwards to the real address for
a few days. This means that the user's name and
On Tue, 9 Oct 2018, Al Iverson wrote:
If you treat quarantine differently than none, you’re sending me misleading
data in the reports you send (if of course
Sorry, but that is just wrong. I publish p=none because that is my
policy.
It's not wrong from my perspective. It's exactly what I
In article <530ab12f-8f41-478f-8e2c-8b276ae9d...@gmail.com>,
Ivan Kovachev via dmarc-discuss wrote:
I have also run some tests using a DMARC protected domain in reject mode and
hotmail whether manually forwarding, auto-forwarding or
redirecting the email treats the email in the same way and
Because I'm introducing a proprietary standard called "Sender Alias Domains
(SAD)" and make use of already popular solutions like SPF, DKIM, DMARC.
As is well known to anyone who is familiar with the history of e-mail,
it's not hard to keep bad guys out of a small walled garden. But it
My presentation contains 373 slides. My demo video length: 30 minutes.
From where do you really think I got the content?
I looked at the first 50 slides or so, and I get the strong impression that
you're not familiar with US patent 5,930,479, which was filed in 1996 and issued
in 1999 and
Sorry, but this is not relevant to the dmarc discuss list.
I took a look at the web page and stopped after "We are building a Parallel
Internet" ...
On Wed, 22 Aug 2018, Viruthagiri Thirumavalavan via dmarc-discuss wrote:
Hello Everyone,
First of all. I would like to thank you all for
On Wed, 11 Jul 2018, John R Levine wrote:
If you're going to have a third party send mail for you, why can't you
just list the third party IP address in your SPF record?
Oh, wait, I got it backward. On the outbound mail, you're right, it's the
customer's domain so they can add the IP to
On Fri, 25 May 2018, Rolf E. Sonneveld wrote:
I may live in another world or the mailing lists to which I subscribe may be
different from the ones you subscribe to, but it is my experience that most
mailing lists didn't implement the From rewriting kludge, but instead
implemented the 'reject
bits in a database at https://www.taugh.com/rddmard
Typo. As you might expect it's really https://www.taugh.com/rddmarc
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
1. The fact that some folk know about these issues and that they were
talked about at some point in time and that there is an obscure record of
those discussions does not mean that these issues are well-documented or
well-understood broadly.
The guy who wrote the security screed appears
So, what am I trying to accomplish, aside from the trivial goal of
making hackers stop emailing me?
As we hardly need tell you, there's no cure for stupid. Perhaps a comment
in your DMARC record saying that bug reports will be met with ridicule,
and some procmail scripts to ridicule any bug
What would be great is if this RFC could have some language discussing
having a confirmation dialog to prevent these accidental mistakes from
happening.
It does. It says that the whole point of this draft is to have a
non-interactive unsubscribe that mail systems can do in the background
It is even worse than I thought, you really want to stop efforts in
fighting phish, by muddling the waters between real domains and fake ones
There's no muddling going on. dmarc.fail is a real domain that should
have an excellent reputation since it sends no phish.
sigh!
On Sun, Feb 7,
mailing list. For example. mail from mari...@yahoo.com turns into
mari...@yahoo.com.dmarc.fail.
Except that @yahoo.com.dmarc.fail is not a domain that exists, and will
negatively impact the email deliverability.
Why in the world would you say that? It not only exists, it's DNSSEC
signed
Seeing as DNSSEC hasn't been done to many (if any) google domains, I wouldn't
expect dane to be implemented yet either.
" DNSSEC has not been widely deployed— recent studies have
found that less than 0.6% of .com and .net domains have deployed
DNSSEC [46]"
DNSSEC still has some serious
I've been looking at examples. I'm not sure how to solve the problem of
recipient perception of the subdomain. we have been so effective at
convincing people that email addresses that look different from what you
are expecting are a phishing attack and they should simply delete it
that they
Yes, but users[*] more-or-less have learnt to expect contrived messages
from mailing lists (altered Subject, footer added, and now altered From
line...), ...
The users on my mailing lists have no clue about a buggered From: line.
How many lists do you run?
Regards,
John Levine,
This is hardly a solution, both because it's utterly undocumented, and
it requires a kind of spam filtering that not everyone wants or can
afford.
Assuming by this you mean use of DMARC results as a non-absolute filter
input, isn't that how most everyone treats SPF these days?
Yes, as far as
27 matches
Mail list logo
