Signing all headers by default is not ideal
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
dkimpy |
Fix Released
|
Undecided
|
Stuart Gathman |
Bug Description
Currently pydkim defaults to signing all headers. This is not a good default since some headers are more likely than others to be modified in transit. It makes pydkim's signatures more fragile than they need to be.
RFC 4871 5.4 and 5.5 has a long discussion about this with an explicit recommendation in 5.5. There are options and no single default setting is obviously correct. My suggestion is that pydkim provide a safe (does not sign headers likely to be modified in transit and does sign all header likely to be end user visible) default and API to adjust this.
Here is my suggestion for default (from 4871 5.5):
From (REQUIRED in all signatures)
Sender, Reply-To
Subject
Date, Message-ID
To, Cc
MIME-Version
Content-Type, Content-
Resent-Date, Resent-From, Resent-Sender, Resent-To, Resent-Cc, Resent-Message-ID
In-Reply-To, References
List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive
The default should 'sign' two From headers by default to prevent an additional From being added.
The API should only require From be signed (since it's a 4871 MUST). If someone wants to change from signing two Froms to one, I think that should be allowed, but if they want to not sign From at all then I think they can edit the code. Our API shoulnd't allow it.
Changed in pydkim: | |
milestone: | none → 0.5 |
assignee: | nobody → Stuart Gathman (stuart-gathman) |
Changed in pydkim: | |
status: | New → Fix Committed |
Changed in pydkim: | |
status: | Fix Committed → Fix Released |
Verifying 2 froms was a hack - I'll have to be sure that signing 2 froms is compliant. That would require that the RFC specifies the equivalent of our dkim.select_ headers( ). Are there any other MUST headers? Off to read RFC.