Just inspecting the email source/original/header and I notice this.
Is this intended?
I mean having unknown [127.0.0.1]?
Or it should be the server IP right?
And also sending an email to gmail account goes to spam folder, maybe that’s the reason.
Everything on System Status Check is fine all GREEN Status.
Header:
Received: from authenticated-user (unknown [127.0.0.1])
(using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
by box.mydoaminhere.com (Postfix) with ESMTPSA id 53426121E29
Normally it has the user’s (client) login name and IP address. We hide it for privacy.
Apparently Google does actually score you down if you have a 127.0.0.1 identification in the header info. I ran across some info about this on their site when researching why my stuff was going to their spam as well. It does seem that getting added to dnswl has helped some with this issue.
When I send email from my server it shows a receive line like this
Received: from mail.mydomainname.org ([127.0.0.1])
The issue seems to lie in that the receive line represents the name of the server, but an IP of 127.0.0.1 which when forward and reverse checks are done on the source results in failures and raises your spam score. We might be able to overcome this by putting the IP address of the server in place of the 127.0.0.1 thus resulting in a matched pair.
In regards to AOL and Yahoo I signed up for their Compliance Feedback Loop programs which seems to get the reputation up as long as you keep an eye on any feedback you get and act on it. This will let you know when people are clicking on the spam button in regards to email for your domain.
Interesting. All right. Well yes we could put the server IP in. That would be a nice solution. Could you open an issue on github or try to patch the setup here?
Let me see what I can do.
Ok, This has proven an interesting thought process.
I have found that the file that needs to be changed is the postfix_outgoing_mail_header_filters which has the rules to replace the received line. Mail-postfix.sh copies that file to /etc/postfix/outgoing_mail_header_filters.
The ideal solution would be to write a routine in the filter file to build the replacement line on the fly. This file appears static (I don’t believe commands can be resolved here) however so I would need to use the mail-postfix.sh file to build the line and replace the existing one in the filters file.
So far so good, but wait, what if the hostname or ip address of the system change in the future. We need to be able to have the filters file updated. The last thing we want is the receive line lying outright. This is the part of the problem where this turns from a simple problem to a rather complex one from my viewpoint.
Does anyone see a cleaner solution to this than I do?
Don’t worry about the hostname or IP address changing. For that we require that the user re-run setup anyway.
Here you go. Tried to keep it clean and simple.
About this issue, I think box.occams.info is yours @JoshData.
And looking it’s headers, 127.0.0.1 is not there.
I hope to see this on the next version being fix.
Still, when I received an email.
I got 127.0.0.1 as address.
Received: from box.domain.org ([127.0.0.1])
by box.domain.org (Dovecot) with LMTP.....Same here, but I guess @JoshData did not have time to push the fix.
In the meantime, @JoshData, is there a way to manually change this in a .conf file?
Thanks!!
I haven’t released an update with this change yet, but it will be there in the next update.
I’m using the master branch and the first issue is already fixed.
Outgoing emails has correct header now, but incoming email has still similar issue.