On 4 Feb 2021, at 9:44, Jeff Abrahamson wrote:
I've a couple security/spam questions for the more experienced.
1(a) A while back Gary <li...@lazygranch.com> noted the very useful
http://dkimvalidator.com/ . It has the curious habit of
simultaneously saying
Validating Signature
result = pass
Details:
in the DKIM section and this sort of thing in the samassassin section:
SpamAssassin Score: 0.201
Message is NOT marked as spam
Points breakdown:
0.0 SPF_HELO_NONE SPF: HELO does not
publish an SPF Record
0.1 DKIM_SIGNED Message has a DKIM or
DK signature, not
necessarily
valid
0.1 DKIM_INVALID DKIM or DK signature
exists, but is not
valid
Is this normal or a point for worry? It did say "not spam".
This is a point of worry for the people operating that tool. It MAY be
an issue that eventually comes to those of us who work on SpamAssassin,
if anyone goes to the trouble of providing a test case where a DKIM
signature is valid but SA insists otherwise. However it is so easy to
break a DKIM signature, especially if the 'strict' canonicalization is
specified, that I would bet on that being a problem specific to how that
tool passes messages to SA.
If you have a test case of a message which that or another DKIM
validator says has a valid DKIM signature AND which you can share in
full AND which your own SA installation (i.e. one that you can
reconfigure at will) says hits DKIM_INVALID, *PLEASE* submit a bug at
https://bz.apache.org/SpamAssassin/enter_bug.cgi with the sample. A
sample of "in the wild" non-spam would be the best, since that's where
the DKIM_INVALID/DKIM_VALID* differentiation is most useful.
1(b) I've noticed that my domain key record tends to get spaces
inserted. I presume strings get concatenated and so this isn't a
source of concern. But I've not found that documented. (I didn't
read the RFC cover to cover, I admit.)
I think that section 2.8 (whitespace) of RFC 6376 and the BNF that
follows says that white space doesn't count. There are over 200
pages of RFC on DKIM (that I found before I got tired of looking).
That is basically the gist. DNS TXT records consist of one or more
Pascal-style (leading length byte) ASCII strings which are typically
displayed by DNS tools as a whitespace-delimited list of double-quoted
strings, but for the purposes of DKIM (and I believe for all
applications using long TXT records) the strings are concatenated
without delimiters.
jeff@birdsong:~ $ host -t TXT mail._domainkey.p27.eu
mail._domainkey.p27.eu descriptive text "v=DKIM1; h=sha256;
k=rsa;
s=email;
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqSJRsAihnsJklyYQvm59m0B6rOK+hwFtMWGGQtDPDTVtzU59Sa1DSK8sAlS0tGUb+kEd3"
"onPUJBmLLr30R8KihfQP1iSB9MjGSjuOXKs8BX6/3i1hX8xCYJ/Pc6E6AvrnVqBr4SDZ5ID62VXfBP7UUrnemO2uMSYnexkHDWubPEJHb7vXTPi5ugRGeuuOg7XzIUayNN/fV+njs
774R09/XGvxb"
"NkJSbhiQa6J0IHbc4cVLQc9Xc7uNSfG6u/LendXrctd3XgPtJz/xUK140VJJzsXebgfiH/SDFbxbiUXWlzktDfxiOQ6rOYVuTdBQgkoVSdzldx++qmwpUHefZG9wIDAQAB"
jeff@birdsong:~ $
Looks fine to me and https://mxtoolbox.com/SuperTool.aspx and
https://dmarcian.com/dkim-inspector/ both agree, so you can be sure that
at least some DKIM implementations will deal with it just fine. OTOH,
other tools seem to dislike it, giving what seem to me to be nonsensical
explanations, so you MAY run into problems.
That is the generally the story of DKIM and DMARC.
2(a) I get lots of dmarc reports. After looking at a few, I
started
pushing them to a special dmarc mailbox where I don't have to see
them. Is there any sense in which these are actionable ? Should I
occasionally look at them or set a machine to look at them? Are
there
any easy ways to look at them, say a mutt viewer? (Detach, ungzip,
and dmarc-cat doesn't scale.) Or automated tools?
There seems to be a thriving business in third parties (e.g. Dmarcian)
watching and analyzing DMARC reports. I know of no one receiving
significant report volume who analyzes their own reports in depth. It
can be useful to watch the volume and spot-check when it gets heavy to
make sure that your signing isn't particularly fragile. For example, one
system I work with has a signature surveillance system *locally* (i.e.
NOT relying on recipient reporting, but just looking at the outbound
flow) which has led to the development of a bespoke tool for
'normalizing' address list headers like To and Cc ahead of signing and
Sendmail's idiosyncratic delivery-time butchery. Because butchery is
better when you do it yourself first...
2(b) Is there any general guidance for whether to set the policy to
nothing, spam, or reject?
I guess you mean none, quarantine, and reject. I am fundamentally
opposed to anything like "quarantine," having been forced to stand up
and maintain quarantine and 'spam folder' systems which have universally
been a complete waste of effort: harmful to overall email service
quality and wasteful of user & support time. Due to the fragility of
DKIM signatures and the violence done to discussion mailing lists by
'reject' policies, I also don't believe that to be useful *for
conversational mailstreams*. Using 'reject' for specific mailstreams
that are particularly targeted by forgeries (e.g. notifications asking
the recipient to do something by clicking a link) is reasonable and
reasonably harmless.
TL;DR: "none" for any mail that might be hitting discussion mailing
lists, "reject" only for mail where phishing is a concrete risk.
3. I'm finding that occasionally sites will stop delivering our
mail.
Sometimes they explain it (hotmail refusing to accept) and one can
flag it. Other times (OVH recently) someone just stops seeing my
mail at all. Some sites claim that ISPs block entire /24's, which
strikes me as oddly indiscriminant post-1990 or so. Is this all
normal?
Yes. It may shock you to learn that blocking mail by much larger ranges
is not uncommon. The big consumer mailbox providers may not do that so
much, but smaller mail systems with less diverse inbound legitimate mail
may shun whole ASNs programmatically if they see only garbage from them.
I sometimes think the world just wants small site operators to believe
that they should be paying the big guys instead. ;-)
You think? Huh... I can't imagine that the companies credited in RFC7489
could have possibly designed DMARC with the intent of making it tilt the
playing field towards their own business models. That would be
unethical, which we all know cannot be true of such giants of the
industry. It is entirely coincidental that the first significant use of
and honoring of DMARC 'reject' policies was by large mailbox providers
who also had captive discussion fora designed to supplant traditional
discussion mailing lists. (Despite what I may have said in the past...)
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
