-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DKIM verification fails due to msg body modification by private relays/transfer agents #165
Comments
@VasuK111 this will also be helpful for you to fix this edge case! We should aim to undo their changes and verify the original dkim anyways. Might also be good to include the modifications in #162 here as well. It's because ideally, to avoid people falling back to ARC when DKIM could work, I think best for possible DKIM verifications to be tried before ARC is tried. The zkp2p fixes are here: see (specific to HDFC): https://github.com/zkp2p/zk-p2p/blob/develop/client/src/components/ProofGen/validation/hdfc.tsx#L85 |
But how do I whitelist beforehand a particular relay service? @Divide-By-0 @winnsterx . Any thoughts please? Edit from Divide-By-0: We are not whitelisting relays, we are reverting the email. |
#189 might fix this
On another note, if there is not requirement to extract data from email body, then bodyhash check can be ignored altogether on the circuit level. Both circuit and input generation helpers have parameter for |
@saleel was this fully fixed with tests? i forget |
We do have the infra and some cases are handled, but not sure if it covers the Apple case mentioned above. If its not covered, we need to identity the changes made by Apple and add a sanitizer to revert that. @winnsterx In you email do you also have a dkim signature from yelp? If so, its better to use with that, so verifier is trusting yelp signature and not apple-relayer (which could have same key for other domains as well?) |
An edge case that causes DKIM verification failure is when the email comes from a private relay service or a transfer agent. These intermediaries modify the body without updating the expected hash in the header.
One specific example is if Apple users select to "sign-in with Apple ID" for certain apps (i.e. Yelp), Apple will relay the email from Yelp to the receiver all under emails hosted by privaterelay.appleid.com. Even though the signature passes, the body hash check fails.
spits out the following error:
One way to fix this is to skip the body hash check entirely if we detect that the email is coming from a whitelisted relay service. Or one can check exactly where Apple is tempering with the body and excise that section to get the body hash.
The text was updated successfully, but these errors were encountered: