Opened 2 years ago

Last modified 2 years ago

#19914 new defect

DKIM causing trouble with Tor lists, should be stripped

Reported by: starlight Owned by: qbi
Priority: Medium Milestone:
Component: Internal Services/Service - lists Version:
Severity: Normal Keywords:
Cc: weasel Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Tor Project list server does not remove DKIM headers and reliably modifies the Subject: header in such a manner as to produce DKIM validation failures. Beyond adding a prefix which can be anticipated by conscientious senders, spaces are injected at unpredictable offsets. This badly degrades spam-scoring of messages by Google and other ESPs and frequently results in the sending of list messages to spam folders.

My recommendation is that the list server configuration be set to completely strip DKIM headers from forwarded messages.

Possibly if the list server software supports it, a DKIM-signed RFC-7001 Authentication-Results: header might be added though it seems to me the positive effect on spam scoring would be minor, where in comparison not stripping DKIM headers results in a substantial negative impact.

Child Tickets

Change History (3)

comment:1 Changed 2 years ago by qbi

Cc: weasel added

weasel: What is your opinion on the suggestion?

comment:2 Changed 2 years ago by weasel

DKIM is just a bad standard when it comes to mailinglists.

Certainly, we should stop munging subjects and bodies.

comment:3 Changed 2 years ago by starlight

Is troublesome to leave messages in intact since inserting [list-name] at the front of subject lines is a major convention. Without random space insertion as a factor one can manually add [list-name] and configure the l=<body_size> field when sending and obtain good signatures (I've done this), but as a practical matter most people will not expend such effort.

In general mailing list servers simply strip out the DKIM-Signature: and related headers, which is better than forwarding DKIM-fail messages.

In theory a second Subject: header can be prepended that DKIM will not check, but the core SMTP RFCs specify that only one instance of this field should exist.

Note: See TracTickets for help on using tickets.