Although things have improved since, some mails are still coming from internal domain names such as "web01.ipfire.org" or have internal sender account names such as "nginx@web01.ipfire.org" (look at yesterdays Yahoo DMARC report for example). We need to eliminate them in order to run a DMARC reject policy.
From which application are they coming from? The forum and wiki have been updated. They could either be old emails in the queue.
(In reply to Michael Tremer from comment #1) > From which application are they coming from? The forum and wiki have been > updated. > > They could either be old emails in the queue. Possible, yes. One example is: Mär 01 20:15:47 mail01.i.ipfire.org postfix/smtpd[3434]: NOQUEUE: reject: RCPT from unknown[172.28.1.107]: 450 4.1.2 <ackerley20@cheaterboy.com>: Recipient address rejected: Domain not found; from=<nginx@web01.ipfire.org> to=<ackerley20@cheaterboy.com> proto=ESMTP helo=<web01.ipfire.org>
There have been 53 emails like that in the queue on the web server. I dropped them all and we should see if any are coming back. Cannot really explain to myself why some of them came through after a while.
(In reply to Michael Tremer from comment #3) > There have been 53 emails like that in the queue on the web server. > > I dropped them all and we should see if any are coming back. Cannot really > explain to myself why some of them came through after a while. This was another one: Mär 01 20:25:21 mail01.i.ipfire.org amavis[3902]: (03902-03) Passed CLEAN {AcceptedInternal}, AM.PDP-SOCK/MYNETS LOCAL [172.28.1.107] <nginx@web01.ipfire.org> -> <[redacted]@gmail.com>, Queue-ID: 0ABA8111C4EA, Message-ID: <20180301202519.9BE0C644B9@web01.ipfire.org>, mail_id: hWte8fnGm8FH, Hits: -1.098, size: 3022, 875 ms There still seems to an application which is not covered...
phpBB is fucking bullshit software. So the test email function is fine: > Mar 01 21:37:57 web01.ipfire.org postfix/pickup[32388]: 3A35E644DE: uid=997 from=<no-reply@ipfire.org> > Mar 01 21:37:57 web01.ipfire.org postfix/cleanup[321]: 3A35E644DE: message-id=<0a0f48f8e456ed888e5eca0b74b6e315@forum.ipfire.org> > Mar 01 21:37:57 web01.ipfire.org postfix/qmgr[18843]: 3A35E644DE: from=<no-reply@ipfire.org>, size=1209, nrcpt=1 (queue active) > Mar 01 21:37:58 web01.ipfire.org postfix/smtp[325]: 3A35E644DE: to=<michael.tremer@ipfire.org>, relay=relay.i.ipfire.org[172.28.1.200]:25, delay=1.2, delays=0.23/0.01/0.01/0.99, dsn=2.0.0, status=sent (250 2.0.0 > Mar 01 21:37:58 web01.ipfire.org postfix/qmgr[18843]: 3A35E644DE: removed But *actual* emails are coming from somewhere else. Only god knows why this is. I will have a look where else I can change this...
I set this in php.ini now: > mail.force_extra_parameters = -fno-reply@ipfire.org
Seems like most of the legitimate outgoing mail is DKIM signed now, but there are still some exceptions. Maybe old queued messages, we'll wait a few days here. @Michael: Looks like somebody in China is sending spoofed ipfire.org-mails: https://dmarc-reports.ipfire.org/dmarc-reports/?report=123&hostlookup=1&sortorder=1&p=2018-03#rpt123
Comment # 7 on bug 11654 from Peter Müller > @Michael: Looks like somebody in China is sending spoofed ipfire.org-mails: > https://dmarc-reports.ipfire.org/dmarc-reports/?report=123&hostlookup=1&sortorder=1&p=2018-03#rpt123 Yeah, I have seen those. They are in there every day. But what what is that stuff coming from apm.com?
According to the DMARC reports, this is fixed now. Some mails are still sent without DKIM singature, but that is another problem, and I will take care about this.
Actually not really, since loads of systems send their internal email with the hostname as domain name. Those usually don't go to external mail servers, but they could. Do we care about that?