For those who operate public facing SMTPd that receive a large volume of
incoming traffic, and accordingly, a lot of spam...
How much weight do you put on an incoming message, in terms of adding
additional score towards a possible value of spam, for total absence of
DKIM signature?
Zero. DKIM for mailing lists is a horribly broken design and legitimate
mailing lists are second only to spam in quantity of SMTP transactions.
Regards,
Bill Herrin
Greetings,
> For those who operate public facing SMTPd that receive a large volume of
> incoming traffic, and accordingly, a lot of spam...
>
> How much weight do you put on an incoming message, in terms of adding
> additional score towards a possible value of spam, for total absence of
> DKIM signature?Zero. DKIM for mailing lists is a horribly broken design and legitimate
mailing lists are second only to spam in quantity of SMTP transactions.
Eh, that's really not accurate, imv, and some folks who run mailing
lists have put in serious effort to make sure to *not* break DKIM
signatures (which is certainly possible to do). The combination of
making DKIM signatures work and DMARC allows messages to go through that
would otherwise end up getting bounced, from what I've seen.
What's annoying are the systems that appear to assume a DMARC policy
that says "bounce it if it's not from a server in our SPF list" when
there's no DMARC policy in place, but there is an SPF list. Not
everyone really wants to put in the effort to set up DKIM, but they're
fine putting up an SPF record, but there seem to be a number of servers
out there that bounce mailing list traffic in those cases (seems to
specifically be MS Exchange systems, from the google'ing that I've
done).
Thanks!
Stephen
Alright, so "horribly broken design" overstates the case but there are
enough problems that weighting the absence of DKIM at something other than
zero will surely do more harm than good.
Regards,
Bill Herrin
There are quite a few things you can do to get the mailing list traversal rate > 90%, iirc. For average mailman-like
lists like nanog it's very high. Of course while a "badly" behaving mailing list can trivially defeat any DKIM signature,
it doesn't really take too much effort to not behave "badly". Whether that false positive rate is too high is another
question.
Mike
+1. A DKIM signature by itself means nothing more than someone had the
ability to configure DKIM on an email server.
The signing domain (d=) is what matters as the signer needs access to the
zone in order to be able to publish the key, which may be interpreted as an
indication of trust.
DMARC requires the signing domain to be either exactly the same or share
the same organisational unit with the From address for this reason.
Even without DMARC, a receiver *could*, depending on the signing domain,
choose to interpret it as a positive signal. This is marginally better than
treating any DKIM signature or the absence thereof as a signal of any kind.
Personally, unless an author domain is publishing a DMARC policy of reject
or quarantine, I don't think recipients should be scoring based on DKIM at
all, perhaps with the exception of signing with a revoked key.
Ken.
Only 90% should be considered horribly broken. Anything that makes
it difficult to run a simple mailing list with less that at least 2 or 3 9's
is unacceptable.
I've been saying for years that it should be possible to create the concept of DKIM-friendly mailing lists. In such
a case, you could have your nines. Until then, the best you can hope for is the list re-signing the mail and blaming
the list owner instead.
Mike
Anecdotal experience. I'm subscribed to a lot of mailing lists. Some pass
through DKIM correctly. Others re-sign the message with DKIM from their own
server.
98% of the spam that gets through my filters, which comes from an IP not
in any of the major RBLs, has no DKIM signature for the domain. My theory
is that it does introduce somewhat of a barrier to spam senders because
they are frequently not in control of the mail server (which may be some
ignorant third party's open relay), nor do they have access to the zonefile
for the domain the mail server belongs to for the purpose of adding any
sort of DKIM record.
A broken DKIM signature is indistinguishable from a lack of a signature header. It's possible that as a heuristic
you might be able to divine something from lack of signature and the existence of selectors for a domain, but
afaik there isn't an easy way to query for all of the dkim selectors for a domain, and even if there were it would
be a pretty sketchy heuristic, is my bet.
Mike
A broken DKIM signature is indistinguishable from a lack of a signature header.
I'll argue that it's possible to distinguish between the two. *However* the DKIM standard states that you should treat a broken DKIM signature the same as no DKIM signature.
I've come to understand DKIM to be proof /positive/, as in trust something when there is a DKIM signature -and- it validates. Everything else defaults to neutral, NOT /negative/.
It's possible that as a heuristic you might be able to divine something from lack of signature and the existence of selectors for a domain, but afaik there isn't an easy way to query for all of the dkim selectors for a domain, and even if there were it would be a pretty sketchy heuristic, is my bet.
Not being able to tell if DKIM is in use has been a long standing annoyance of mine.
That being said, I think it could be trivial to query for DMARC records and deduce things from the existence of the "adkim" option. If it's there and set to reject, then there really should be DKIM-Signature header for the message.
There have been a number of things that fall into that category, two of which immediately come to mind are:
- Requiring Reverse DNS
- SPF
I'm not commenting about the viability of these things, just that they are fairly well accepted and that they can trivially break mailing lists.
IMHO, DKIM and DMARC are just the recent additions to that list.
A broken DKIM signature is indistinguishable from a lack of a signature header.
I'll argue that it's possible to distinguish between the two. *However* the DKIM standard states that you should treat a broken DKIM signature the same as no DKIM signature.
Remember: if you treat a broken signature better than lack of signature, spammers will just insert phony signatures to game you.
So they really are the same.
Not being able to tell if DKIM is in use has been a long standing annoyance of mine.
That being said, I think it could be trivial to query for DMARC records and deduce things from the existence of the "adkim" option. If it's there and set to reject, then there really should be DKIM-Signature header for the message.
I haven't really kept up with dmarc, but its progenitor ssp could give you that indication, iirc.
The real problem with large enterprise that we found, however, is that it was really hard to track down every 25 year
old 386 sitting in dusty corners that was sending mail directly instead of through corpro servers to make certain
that everything was signed that should be signed. Maybe that's gotten better in the last 15 years, but I'm not too hopeful.
Mike
Spammers can:
A) Establish domains that use SPF and DKIM as well as anyone else
B) Use the stolen credentials of legitimate accounts on legitimate servers to relay SPAM messages.
So the presence of SPF/DKIM does not reliably indicate whether the message is spam or not - only that the sender is "authenticated". The lack of optional tech like SPF and DKIM might be used as a heuristic, but it's not reliable enough to use in practice in my opinion. I wouldn't quarantine or reject messages that are missing these optional technology because the take rate isn't high enough.
Where DKIM/SPF really help is when there's a failure that indicates a message has been spoofed. This is a good indication of phishing and is a justified reason to reject or quarantine a message in the interest of your employees or subscribers. Sometimes these will be config errors, but I feel confident telling the sender to take config issues up with their service provider.
15 years ago we blocked outbound port 25 except from our campus mail
servers. That should be SOP by now. It is fairly easy to look at
firewall logs to find these.
Remember: if you treat a broken signature better than lack of signature, spammers will just insert phony signatures to game you.
So they really are the same.
Yes, they are /effectively/ the same. However it is possible to distinguish between a broken DKIM signature and the lack of a DKIM signature.
What you do with that information is up to you. - Guidelines suggest that you treat them the same. (Thus them being /effectively/ the same.)
The real problem with large enterprise that we found, however, is that it was really hard to track down every 25 year old 386 sitting in dusty corners that was sending mail directly instead of through corpro servers to make certain that everything was signed that should be signed. Maybe that's gotten better in the last 15 years, but I'm not too hopeful.
I hear you, and I don't disagree with your sentiments about the difficult of the matter. However, I find it highly suspect that such systems ancient are still in use. There may very well be replacements for said systems that are < 20 years old.
Either way, they would still run afoul of things like SPF (unless you allow your entire IP space to send email).
There are other security / vulnerability implications of such infrastructures. - I'd argue that they are motivation enough to wrangle these rogue systems.
Where DKIM/SPF really help is when there's a failure that indicates a message has been spoofed.
There are other legitimate things that can break DKIM signatures. I have personally seen changes in content type encoding break a DKIM signature.
The message was perfectly valid, and only failed DKIM signature validation.
This is a good indication of phishing and is a justified reason to reject or quarantine a message in the interest of your employees or subscribers.
As much as I would like to be able to safely reject on DKIM Signature validation failure, I don't think that it is safe to do so.
Sometimes these will be config errors, but I feel confident telling the sender to take config issues up with their service provider.
Hopefully this will bring the perceived problem to someone's attention who can hypothetically do something to correct it.
In which case neither will they be RFC compliant.
(1) The "inaddr-arpa" ptr from the incoming connection, when resolved, MUST result in a set of IP Addresses which includes the original IP Address.
(2) The "name" specified in the HELO/EHLO MUST resolve to an MTA that meets the above reverse/forward resolution requirement.
(3) The domain name specified in the envelope-from MUST be resolvable to an MTA that meets the above requirement (1) or be empty.
(4) The SPF checking, if done, MUST NOT fail.
(5) The connecting MTA MUST NOT speak when not spoken to (that is, it MUST NOT not violate the SMTP chat protocol).
If you dump all connections that are do not meet these requirements, you will have eliminated 99% or more of all spam.
DKIM signatures do not really add much at all except prove that the message was sent through a server that could calculate a DKIM signature. It says nothing about whether the message is SPAM or not. 99% (or more) of all spam will have violated one or more of rules (1) through (5) long before the message contents are accepted so that the signature can be verified.
In article <1d458e76-ab61-db28-79cb-6aabcab4ff3b@mtcc.com> you write:
I've been saying for years that it should be possible to create the
concept of DKIM-friendly mailing lists. ...
I suppose, if your users are OK with no subject tags, message footers,
or any of the other cruft that list users have taken for granted for
the past 30 years.
The people who brought us DMARC have a new anti-DMARC thing called
ARC that is intended to help recipients guess whether a message with
a broken signature came through a mailing list. It's a kludge, but
since it's a kludge that Gmail has already implemented, you'll be
seeing more of it.
Returning to the original question, if a message has no DKIM
signature, that doesn't say anything particularly bad, but it does
mean that the sending IP is your main bit of info to decide whether
it's mail you want, which has issues of its own.
R's,
John
PS: details here Specifications – dmarc.org
PPS: Please spare us pontification about why ARC can't possibly work
unless you're prepared to cite section numbers in the ARC spec
supporting your argument.
In article <88a1ae22-a5c1-dc46-caa7-cca813109e99@tnetconsulting.net> you write:
- Requiring Reverse DNS
- SPFI'm not commenting about the viability of these things, just that they
are fairly well accepted and that they can trivially break mailing lists.
A mailing list sending with bad rDNS or bad SPF is a pretty cruddy
mailing list. Normal lists put their own bounce address in the
envelope so they can handle the bounces, so their own SPF applies.
No idea why you think rDNS for a list's MTA is any harder than anyone
else's MTA.
R's,
John