On 2020-05-19 00:09, Douglas E. Foster wrote:
I understand your question to be "Why do I see invalid DKIM signatures
on messages from the IETF mailing list?"
yes this is my consern, it should not be breaked on take ownerships, if
maillist can break dkim and take ownerships and still not make it dmarc
pass then its incompetent maillist admins
its just sadly not the only maillist its daily problem on
I can provide your answer
The typical message on this mailing list has three signatures:
Signature Analysis:
* The first signature is from the submitter's organization. In your
message, it was from junc.eu.
yes
* The second signature is applied by IETF shortly after receipt of
the message.
opendkim resign ?
* IETF adds an Athentication-Results header which indicates that the
junc.eu signature was valid when they checked it
yes i did my homework then
.
* Then, IETF changes the FROM address to be @dmarc.ietf.org and tags
the Subject with [dmarc-ietf]. This breaks both of the first two
signatures.
why is it done ?, to fix there own problem of breaking dkim ?
* Then, IETF applies a second signature which is verifiable.
it just not giving dmarc pass, why ?
Integrity Analysis:
* The IETF rule is "an unverified signature is the same as no
signature." Therefore, the invalid signatures can and should be
ignored. It appears that your tool is getting confused by the invalid
IETF signature and ignoring the valid one.
i think that on the safe side to not make dkim pass with signatures not
from original outhor domain, if that ships sail it would make it hard to
verify without openarc sealing
* The message passes SPF because the Sender Address has been changed
to dmarc-boun...@ietf.org.
thats the standard aling changes, all well there
* The second passes DKIM because the second IETF signature verifies.
but why is it not dmarc pass
* No official assertion is been made about the sender's domain, so
there is no need to verify against that domain. But if you want to
do so, you can evaluate whether to place trust in the
Authentication-Results header applied by IETF.
waiting for AuthRes plugin in spamassassin then all problems will be
bigger if results is evaluated outside of spamassassin from AR headers
hope developpers wake up on the risk of breaking more then just dkim
* IETF converts all messages to plain text, and strips or blocks
attachments, so they have minimized the opportunity for malicious
submission.
i remember with amavisd-new it was good to disable 8bitmime before
letting amavisd-new do its dkim sign, that helps make dkim signed
signature not break on mime converters
Implications for Email Defenses:
This example is a reminder that every message is a take-it-or-leave-it
proposition. You can accept the message or reject it, based on the
message characteristics, but you will probably be unable to cannot
change the sender's behavior. In this situation, you may not like
having two signatures from IETF, but you cannot change IETF. As a
result, any spam filter needs to be very flexible about exceptions.
Too many spam filters do not have adequate exception mechanisms.
i will let spamassassin do its work on dkim breakage on maillists, but
that is same reason i do not use sid-milter, opendkim, openarc,
opendmarc, its designed badly to maillists that claim its impossible to
not break dkim
Hope this helps,
it does hopefully :=)
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
