On 28 Apr 2019, at 21:51, John Levine via mailop wrote:
Just to be clear, we all understand that these funky DKIM signatures
have nothing to do with the reason that Google is rejecting mailop
messages, right?
I think so...
I mean, I believe that you are correct in that a SPF record for the IPv6
output would fix the problem without anyone making DKIM changes.
HOWEVER: if I understand Simon's description of the rejection events
correctly, the trigger was specifically a message with a broken DKIM
signature which had not had its From munged (because the DMARC record
had p=none,) and that changing Mailman to munge ALL From headers fixed
the problem. This would imply that Google is doing something very
dubious in looking for "authentication."
R's,
John
On 4/28/19 12:38 PM, Chris Adams via mailop wrote:
So should mailing lists reject such messages?
No. Absolutely not.
The DKIM specification states that a failed DKIM-Signature validation
should be treated like a lack of a DKIM-Signature.
I think the list MTA should accept the messages with DKIM oversigned
headers, remove said DKIM-Signature headers, pass the DKIM-less
message
into the mailing list for normal processing.
Ideally, the list MTA would add new DKIM-Signature header as messages
went outbound.
If they're going to add headers and the signing effectively says
"don't", why should the list accept the message?
The signing doesn't say "don't". The signing is a way to detect if
the
message has been modified in transit. IMHO DKIM is a trip wire of
sorts
to detect modification, nothing more, nothing less. Was the message
modified, yes or no.
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
