CODEWITHSUNDEEP
emailgosmtpgmailpostfix-mta
Scott Owens
Scott Owens

Reputation: 81

golang & postfix - email received header is localhost

While trying to setup postfix to allow a website to sent password reset emails I've noticed that when sending emails form the command line using 

echo "body" | mail -s "subject" [email protected]

the emails arrive just fine and are not marked as spam. However, when sending from withing the sites server, the header is set as being received from localhost and thus is marked as spam.

Received: from example.com (localhost [127.0.0.1])
by example.com (Postfix) with ESMTPS id CE1299C435
for <[email protected]>; Tue,  2 Aug 2016 05:28:41 +0000 (UTC)

As a note, dkim, spf and dmarc test all list as passed, so they are not the problem.

I have also tried sending an email with the same content using the above echo method and had it arrive fine (although plaintext as I used it as above and didn't add the content type headers).

Initially this was sent using smtp.SendMail

err := smtp.SendMail(hostname + ":25", nil, sender, recipients, []byte(msgstr))

which provides no way to set sending host, so in an attempt to correct this I switched to using a manual dial, sending a HELO message, then starting tls (attempting to start tls before the HELO resulted in a panic saying the HELO had to be the first call)

c, err := smtp.Dial(host + ":25")
if err != nil {
    log.Panic(err)
}

if err = c.Hello(host); err != nil {
  log.Panic(err)
}

if err = c.StartTLS(config.TLS()); err != nil {
  log.Panic(err)
}

This still sends the email successfully, but as before the received header still shows localhost as the origin, I feel I've misunderstood something as I believed that HELO served to identify where the call was coming from.

Your advice and help is appreciated, this is the first time I've tried to configure an MTA and use it like this, there has been a bit of a learning curve that I'm evidently not over yet.

Upvotes: 3

Views: 2239

Answers (1)

Scott Owens
Scott Owens

Reputation: 81

As Juergen Gmeiner suggested in the comments, my problem ended up being caused by a poorly configured /etc/hosts file, such that it wasn't effecting other services.

The existing entry was:

127.0.0.1 localhost example.com

Changing this to:

127.0.0.1 example.com localhost

solved the problem while not breaking the existing services that needed localhost to evaluate properly.

This solution worked for my locally hosted server process, if the same problem occurs with a remote server, and equivalent like would need to be created with the ip and hostname of the remote. i.e.

<remote ip> <hostname>

note: while I tested that this last part by calling from my local development build to our production server and it worked, its not a 100% tested solution.

Thank you all for your help, and I hope that this mistake on my part helps anyone else who makes a similar error in the future.

Upvotes: 3

Related Questions