postfix on Linode: all email going to Gmail/hotmail SPAM

Maybe those PHP headers? Are non-PHP emails also classified as spam?

@kenyon:

Maybe those PHP headers? Are non-PHP emails also classified as spam?

thanks for getting back to me.

The PHP aren't the problem. I tried sending an email straight from telnet, and it's also in SPAM

we are really almost desparate after trying out anything we could think of. A colleague of mine tried sending a simple email from his server and it goes to INBOX, without even using SPF records or DKIM.

Here's another complete email that just goes to SPAM on gmail / hotmail. We are postponing a web app launch because of this for the past 5 days.

ANY advice or tips on this is really appreciated:

Delivered-To: someone@gmail.com
Received: by 10.216.183.13 with SMTP id p13cs84787wem;
        Sat, 13 Nov 2010 09:00:00 -0800 (PST)
Received: by 10.229.214.139 with SMTP id ha11mr3256460qcb.235.1289667599435;
        Sat, 13 Nov 2010 08:59:59 -0800 (PST)
Return-Path: <support@ourapp.com>Received: from www.ourapp.com (www.ourapp.com [173.xxx.xxx.xxx])
        by mx.google.com with ESMTP id u7si11134289qco.191.2010.11.13.08.59.58;
        Sat, 13 Nov 2010 08:59:59 -0800 (PST)
Received-SPF: pass (google.com: domain of support@ourapp.com designates 173.xxx.xxx.xxx as permitted sender) client-ip=173.xxx.xxx.xxx;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of support@ourapp.com designates 173.xxx.xxx.xxx as permitted sender) smtp.mail=support@ourapp.com
Received: by www.ourapp.com (Postfix, from userid 48)
    id 5AB8F1C881; Sat, 13 Nov 2010 11:59:58 -0500 (EST)
To: someone@gmail.com
Subject: Signup confirmation needed
From: OurApp.com <support@ourapp.com>Reply-To: OurApp.com <support@ourapp.com>MIME-Version: 1.0
Content-type: text/html;charset=UTF-8
Date: Sat, 13 Nov 2010 16:59:58 +0000
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <20101113165958.5AB8F1C881@www.ourapp.com>

Hi! We're thrilled to have you on board!

You are now just 1 t=
iny step away from securing your shiny new account.
Please click the following link to confirm.

<a h="ref=3D&quot;http://www.ourapp.com/beta/regconfirm/guid/7a8344e1ae=" 04062c9c2495429255b5a0="" id="" 76"="">Confirm your subscription</a>
 <b= r="">Have a good day!
[Ourapp.com](3D'http://www.ourapp.com')</b=></support@ourapp.com></support@ourapp.com></support@ourapp.com> 

@jorre:

@kenyon:

Maybe those PHP headers? Are non-PHP emails also classified as spam?

thanks for getting back to me.

The PHP aren't the problem. I tried sending an email straight from telnet, and it's also in SPAM

Did you try setting up RDNS in Linode? That solved my problem almost immediately.

@jefe78:

@jorre:

@kenyon:

Maybe those PHP headers? Are non-PHP emails also classified as spam?

thanks for getting back to me.

The PHP aren't the problem. I tried sending an email straight from telnet, and it's also in SPAM

Did you try setting up RDNS in Linode? That solved my problem almost immediately.

yup, RDNS is set up

my IP resolves back to www.ourapp.com (hostname of the machine)

is that correct, or should it resolve back to something as mail.ourapp.com ?

@jorre:

@jefe78:

@jorre:

thanks for getting back to me.

The PHP aren't the problem. I tried sending an email straight from telnet, and it's also in SPAM

Did you try setting up RDNS in Linode? That solved my problem almost immediately.

yup, RDNS is set up

my IP resolves back to www.ourapp.com (hostname of the machine)

is that correct, or should it resolve back to something as mail.ourapp.com ?

Should resolve to whatever you set. Mine resolves to ottawahosts.com

Another thing I set that made a difference was adding the following line to /etc/php5/apache2/php.ini:

sendmail_path = /usr/sbin/sendmail -t -i

sendmail_from = -fjeff@localhost

so you'll add your name/domain to the line as such(don't forget the -f)

sendmail_from = -fjorre@localhost

Let me know if that works. This part is probably a goose hunt but its worth ruling out.

thanks a lot for helping me out!

the php.ini file has already been set like this to make sure the Return-Path header is set to the same as our from/reply-to address:

sendmail_path = /usr/sbin/sendmail -t -i -f support@ourapp.com

(the sendmail_from settings is only for windows)

nslookup x.x.x.x (server ip) gives me

Non-authoritative answer:

x.x.x.x.in-addr.arpa name = www.ourapp.com.

is that ok?

(all mail still goes to spam)

Have you tried clicking "Not spam" on the Gmail e-mails? The first e-mail from a new IP usually lands in my spam trap, but "Not spam"ing it fixes it up forevermore.

As for Hotmail, I'm not sure what their procedure is this week. See also http://mail.live.com/mail/postmaster.aspx

@hoopycat:

Have you tried clicking "Not spam" on the Gmail e-mails? The first e-mail from a new IP usually lands in my spam trap, but "Not spam"ing it fixes it up forevermore.

As for Hotmail, I'm not sure what their procedure is this week. See also http://mail.live.com/mail/postmaster.aspx

that could be a solution for myself, but we can never ask this to our clients. Any other solutions to not having a first mail go to spam?

Check your IP against DNS blacklists and reputation services. Stop using www.xxx for mail and create a mail.xxx subdomain, update configuration accordingly. Start signing outgoing mail with DKIM. If your content-type is HTML (it is in your example), start using full valid HTML, with body tags, etc. Google collects reputation information, but it may take time.

@mst:

Check your IP against DNS blacklists and reputation services. Stop using www.xxx for mail and create a mail.xxx subdomain, update configuration accordingly. Start signing outgoing mail with DKIM. If your content-type is HTML (it is in your example), start using full valid HTML, with body tags, etc. Google collects reputation information, but it may take time.

Thanks for your reply!

I get why people would use DKIM, but my collegue and other tests we ran were just servers sending out email even without SPF or DKIM that would arrive just fine in gmail's INBOX, so I wonder if it's worth the hassle.

I'll look into well formed HTML for our mails, but simple plain text emails from telnet aren't getting through either.

Gmails never mentions using a mail.xxx subdomain for mail, their guidelines state that we should have Reverse DNS and SPF set up. Does it really matter if we change the subdomain to mail.xxx ?

It is a good habit to never mix subdomains, both from administration perspectives and when reputation services are involved. Bear in mind that Google likes to keep huge databases of everything it encounters. Another thing pops to mind: GMail hates "spammy" keywords. Sometimes simply rewording a message helps. Expressions like "just 1 step away" and "please click" and "confirm your subscription" may very well make Google go bonkers.

@mst:

It is a good habit to never mix subdomains, both from administration perspectives and when reputation services are involved. Bear in mind that Google likes to keep huge databases of everything it encounters. Another thing pops to mind: GMail hates "spammy" keywords. Sometimes simply rewording a message helps. Expressions like "just 1 step away" and "please click" and "confirm your subscription" may very well make Google go bonkers.

thanks.

We tried several messages, just simple ones to send through telnet but all goes to spam anyhow, nothing spammy in our mails …

@mst:

It is a good habit to never mix subdomains, both from administration perspectives and when reputation services are involved.

what exactly do you mean by this?

Should we run our mailserver on another A record (mail.xxx.com?)

right now we have a machine www.xxx.com that is running apache + postfix for our web app.

postfix uses our hostname to send out emails which is www.xxx.com

heres's another update:

[root@www mydir]# mailq

-Queue ID- –Size-- ----Arrival Time---- -Sender/Recipient-------

39E861C959 1596 Tue Nov 16 13:17:27 support@ourapp.com

(host mx-cluster-a2.one.com[195.47.247.193] said: 450 4.7.1 <bram_xxx@xxx.be>: Recipient address rejected: Greylisted for 5 minutes (in reply to RCPT TO command))

bram_xxx@xxx.be

http://en.wikipedia.org/wiki/Greylist

Unrelated to your problems with gmail.

extra update: we are using Google Apps and have their mail servers set up like documented in their documentation.

Those are the only MX records. Might that be an issue?

I don't believe so.

Mine are all google's too and it's fine

EXTRA UPDATE:

how can we make sure that google doesn't see us as spam. I've read that gmail will get an email from @ourdomain.com and it will run an nslookup or something to see if we actually have a receiving MX server set up?

Can someone confirm this and give me the nslookup command that I can test with. I'm confused as nslookup on ourdomain.com gives the correct MX records, but mxrecord on WWW.ourdomain.com doesnt.

The hostname of the machine we are sending with is www.ourdomain.com

Is that something to be worried about?

Here are three things that help:

1) You need to have a proper MX record setup, as you've noted

2) Your IP's reverse DNS that you're sending from should be the same as the domain you're sending mail for (as in, foo.com -> 1.2.3.4, and 1.2.3.4 -> foo.com)

3) You should set up your SPF records properly.

@Guspaz:

Here are three things that help:

1) You need to have a proper MX record setup, as you've noted

2) Your IP's reverse DNS that you're sending from should be the same as the domain you're sending mail for (as in, foo.com -> 1.2.3.4, and 1.2.3.4 -> foo.com)

3) You should set up your SPF records properly.

Thank you for helping out. Can you let me know how to correctly check these 3 factors?

1) I have MX records set up for google apps, just like they state in their documentation. I don't have an MX record for my own machine since I don't receive email on that IP. I do have an SPF record that mentions the google apps MX servers as valid senders

2) My email headers now say:

Received: from mail.ourdomain.com (www.ourdomain.com [x.x.x.X])

should I test RDNS for mail.ourdomain.com (this is the hostname) or for www.ourdomain.com ? How do I test this 100% correctly?

3) The SPF say "pass" in gmail email headers, is that OK?

Because the test on http://www.openspf.org/Why gives me the following:

The SPF check gives me this: An SPF-enabled mail server rejected a message that claimed an envelope sender address of support@ourdomain.com. An SPF-enabled mail server received a message from ourdomain.com (x.x.x.X) that claimed an envelope sender address of support@ourdomain.com. The domain ourdomain.com has authorized ourdomain.com (x.x.x.x) to send mail on its behalf, so the message should have been accepted. It is impossible for us to say why it was rejected

You don't need an MX for the hostname of the server, only for the domain of the email sender.

Reverse DNS only needs to match the hostname of the mailserver, not the domain you are sending from. There is no requirement that the domains of the server and the email sender must match.

If you really want help, you'll need to tell us your real domain. By providing imaginary details, you are just getting guesses as to what your problems may or may not be.

In my experience no matter how well you set up all these details, it is likely that some of the major providers will see any new mailserver as a spam source. Once you have been in operation for a while and enough users have clicked "Not Spam" or whatever, then maybe you will build up enough reputation to go straight into inboxes.

@jorre:

2) My email headers now say:

Received: from mail.ourdomain.com (www.ourdomain.com [x.x.x.X])

should I test RDNS for mail.ourdomain.com (this is the hostname) or for www.ourdomain.com ? How do I test this 100% correctly?

Your mailserver is announcing itself (HELO) as mail.ourdomain.com, but RDNS says that your IP belongs to www.ourdomain.com. It really doesn't matter which name you use, but ideally you would have one consistent hostname for your mailserver.

Forward DNS: mail.example.com -> 1.2.3.4

Reverse DNS: 1.2.3.4 -> mail.example.com

HELO: mail.example.com

In postfix, you can set the HELO name by smtpheloname, (or better yet just properly set myhostname) in main.cf.