On 10/18/2017 02:10 PM, Dimitri Maziuk wrote:
They are different ASCII representations of the same byte, yes. They are
not the same text.
Hum. I wonder if we have been talking about slightly different things.
I've been referring to "ΓΌ" being displayed the same in MUAs which is
interpreting the different underlying text in the various content
transfer encodings.
Sign the text, re-encode text and signature together,
anyone who cares about it can decode it back to where the signature will
match.
Do I understand you correctly to mean to create the signature before
applying transport encoding?
Only, you can't do that on the MX, it has to be done on the client.
Why can't you do it at the MX?
Or do you mean that it's inefficient to do so at the MX?
DKIM is designed to produce false positives. Which means DKIM-based
tests will have low specificity
(https://en.wikipedia.org/wiki/Sensitivity_and_specificity).
My experience ~> opinion, save for mailing lists, differs. In fact,
most of the email that I receive passes DKIM.
Which makes
them bad for detecting spam. But that's OK, DMARC in general is for
*fraudulent* e-mail, not *unsolicited* e-mail.
I don't think DKIM (or SPF or DMARC) have /anything/ to do with spam
detection. SPF is for envelope sender authorization. DKIM is for
message integrity. DMARC is for policy and reporting. None of that has
anything to do with spam detection / filtering.
In fact, I've found that spammers (worth their salt) tend to be early
adopters of email technology. Thus they are quite likely to send spam
that passes SPF and DKIM and DMARC.
I'm sure once I'm plagued by *fraudulent* e-mail, I'll start caring
about RFC 7489 and the rest of them.
I started caring about SPF / DKIM / DMARC for a couple of reasons:
1) I'm pedantic and want to have the best filtering / security that I
possibly can on my personal domain.
2) I was seeing blow back from mailing lists about DKIM and / or DMARC.
Thus I dug in more and learned more.
To each his / her own motivation (or lack there of.)
When those e-mail are from mailman
I'll start caring about what mailman does with DMARC headers. But at
this point I'd just strip them all off.
I suspect that when (if) you care will be after you implement filtering
(Chicken / Egg?) that possibly rejects messages from mailing lists. Or
possibly if your messages with enhanced security cause others to have a
problem. (Again with the chicken & egg.)
(And since I'm tripping down the memory lane:
https://catless.ncl.ac.uk/Risks/23/21#subj9.1)
:-P
--
Grant. . . .
unix || die
------------------------------------------------------
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
