I think @robin 's suggestion seems well thought out. The big advantage is that it would be totally optional to do it for apps for which it would be hard, while providing a significantly better UX for apps which do support it.
@nebulon Kind of depends on the app type, too, I guess? The one I really notice this stand out on is for LAMP. I have maybe 4-5 of these, all serving static sites. I don't really care when they update, but whenever they do, I get a bunch of notifications for them all at once.
I don't know. I guess I see your point, and maybe it's fine to just leave it be. Ultimately, I guess if you don't design for people to have too many things of the same type, it probably won't matter anyway.
@girish Hi there. Thanks for checking into this for me.
I had a suspicion that the spam engine was verifying, since I did see those fields in the Spam results headers. However I think it's also useful to have Haraka add the headers as well. It would add very little overhead and will add additional detail that the spam header doesn't contain about the DKIM verification (such as which signature failed or passed, since an email can contain multiple).
In regards to DMARC. I don't believe this would be risky at all if implemented in the following manner:
No DMARC record found, take no action.
DMARC found, DKIM/SPF aligned, take no action
DMARC found, DKIM/SPF alignment fails, but p=none, take no action.
DMARC found, DKIM/SPF alignment fails, but p=quarantine, move to spam folder
DMARC found, DKIM/SPF alignment fails, p=reject, dev/null the mail. If you don't like the risk of this, push it to spam instead... or make it a cloudron option under Settings.
👍 Internally, there is already a way to set custom env vars (you can do this only in the CLI currently, cloudron env). So, we have to update the manifest and the UI to use those fields and set env vars.