Some outgoing mails (especially coming from the web server) are missing DKIM signatures and won't authenticate against it. The IgnoreHosts directive of OpenDKIM needs to be adjusted here. @Michael: Is there a network range for servers only? Or do we need to sign all mails coming from RFC1918 addresses?
Added 172.28.1.0/24 to the InternalNetworks, so mails coming from these IPs should be signed now. We need to test if mails delivered via submission port are still, too, but I think so. :-)
Tested, this is fixed now.
172.28.1.0/24, 192.168.9.0/24 is what we use internally mainly Since relay.i.ipfire.org is only pointing to IPv4 only, we don't use IPv6 at the moment but that is only disabled since we migrated to the new machine
For the records: 192.168.9.0/24 was missing, added now. Had much too little coffee today...
Some outgoing mails are still missing DKIM signatures. This might be fixed by adding the internal network (see last comment), but we keep this open until the DMARC reports prove that.
I do not see any major amount of unsinged mails looking at the DMARC reports. Can we consider this as being closed?
If the reports are all green, yes. What can we do about the remaining yellow ones?
(In reply to Michael Tremer from comment #7) > If the reports are all green, yes. > > What can we do about the remaining yellow ones? In case of the Gmail report from yesterday (https://dmarc-reports.ipfire.org/dmarc-reports/?report=645&hostlookup=1&sortorder=1&p=2018-04#rpt645), not very much I'm afraid. They are all DKIM signed.
I looked yesterday or two days ago and there is still a lot of yellow in there. Amazon for example. Or is that a fraud?
Hard to tell... There is some traffic to Amazon, but mostly aggregated DMARC reports. Could you send me those so I can check wether they are DKIM signed?
I don't have them. I removed the CC to postmaster@ipfire.org so I do not get a sh*t ton of emails in my inbox that I cannot do anything about.
Well, in that case I suppose there is no information left. Are you fine with re-enabling the CC and move the reports to a separate folder in your IMAP account?
Created attachment 575 [details] attachment-4160-0.html Yes that would be fine. Or ideally having them put in an own Git repo with my archive script?! For how long and for what purpose do you want to keep them?
I use to keem them 14 days, mainly for debugging and throubleshooting.
Some mails to Amazon SES are missing DKIM signatures: - https://dmarc-reports.ipfire.org/dmarc-reports/?report=722&hostlookup=1&sortorder=1&p=2018-04#rpt722 - https://dmarc-reports.ipfire.org/dmarc-reports/?report=723&hostlookup=1&sortorder=1&p=2018-04#rpt723 These seem to be DMARC reports. @Michael: Could you send them to me so I can have a look at them? Apart from that, everything else is green now.
I am not storing them. I just pipe them into the script which puts them into this database that you are having a look at.
(In reply to Michael Tremer from comment #16) > I am not storing them. I just pipe them into the script which puts them into > this database that you are having a look at. I meant the DMARC report we sent to Amazon SES since I suspect it being missing a DKIM signature for whatever reason.
Yes same, I do not store them. I will set something up that they are stored in a separate inbox and then we should have one in a few days if that is soon enough.
Since the last DMARC reports indicate DKIM success with a few exceptions (looks like mail redirections at GMail), I think we can close this issue. @Michael: Can we? :-)
I didn't check the reports, but I trust you when you say this is okay...
What is with all the stuff that is coming from web06? That's the wiki and forum.
Re-opened because we need to get rid of "web06.i.ipfire.org" in the headers...
(In reply to Michael Tremer from comment #22) > Re-opened because we need to get rid of "web06.i.ipfire.org" in the > headers... I filed this seperately under #12042. Closing this.
We currently send messages without DKIM signatures, as DKIM keys are missing.
This is fixed for ipfire.org and lighthningwirelabs.com by now. Some other personal domains of Michael may be missing, but they are not that crticial here...