2

I have configured Postfix to be responsible for subdomain.example.com (google apps is responsible for example.com so I didn't want to mix the two).

As I mentioned in question title, SPF and DKIM always pass when I send mail locally from that host ($ mail xyz@gmail.com), but mails still end up in Spam folder.

The only thing missing is reverse DNS setup for subdomain.example.com and IP it's sending from, but I figured it won't matter, since SPF includes a:ip.add.re.ss, and since SPF passes...

Any ideas what else could I do to get them into inbox?

UPDATE: problem was instantly resolved as soon as Amazon removed my IP from Spamhaus PBL (see answer below).

mr.b
  • 583
  • 10
  • 25
  • dkim is not made for spam prevention/filtering, it just ensures that the messages is not tampered with along the way to the recipient. iirc – Peter Lindqvist Jun 17 '11 at 08:00
  • I figured that much, but since email itself doesn't contain anything even remotely suspicious (lorem ipsum text as copy, hello as subject?) I really have no idea what could be triggering their spam flags... – mr.b Jun 17 '11 at 08:05
  • is there no way to get the reason it is marked as spam from the spam filter? there could be lots of reasons. – Peter Lindqvist Jun 17 '11 at 08:07
  • the lack of a reverse DNS record triggers most MTAs, while SPF does not. Checking for a PTR record is probably the oldest trick in the book, and even the laziest admins have this implemented. Whether or not SPF can provide the same is not a question here, since the receiving MTA looking for a PTR will not look for it in SPF – dyasny Jun 17 '11 at 08:10
  • @dynasty: I am fully aware of that, however, I don't own the IP block, so it's not up to me to configure my PTR. I'm still waiting for my provider to configure PTR for my IP.. I'll see if problem goes away after they do that. – mr.b Jun 17 '11 at 08:15
  • You need to begin your investigation with the server that identified your message as spam. There are (literally) thousands of reasons it could be identified as spam. There may be some clues in the message headers, too, depending on what spam filter it's running through, and how generous it is with details. – Flimzy Jun 17 '11 at 08:16
  • @Peter, @Flimzy: by reading raw mail headers of message received by Gmail, no. It says absolutely nothing as to why email got classified as spam. – mr.b Jun 17 '11 at 08:17

1 Answers1

2

I think I found two possible reasons why mails are listed as spam.

First, as someone previously suggested (and as I was already aware of), missing PTR for sending server could be main cause.

Second, since this server is hosted in AWS cloud, and Amazon has worked with Spamhaus to add all their IP ranges to PBL by default, it could also be the reason... From what I know, PBL has certain weight in deciding if email will be marked as spam or not. Also, Amazon has blocked requests for removal of their IP's from Spamhaus PBL list directly - requests have to go through Amazon. Luckily, they offer a way to remove Elastic IP from this list, and to setup a PTR record, while you're at it.

So I'll see what happens after this process is complete.

UPDATE: Amazon added correct PTR record, and it didn't resolve the problem. However, after they removed IP from Spamhaus PBL, mails stopped being sent to spam. Meanwhile, many SMTP servers stopped accepting mails from my SMTP because of this PBL list, which was also resolved when PBL record was removed.

mr.b
  • 583
  • 10
  • 25
  • The PTR record not matching the From: domain is an incredibly stupid way of blocking spam. As you've pointed out, there are plenty of entirely legitimate reasons why the PTR can not and will never match. Anyone blocking incoming messages (or even weighting their scoring system for it) needs a good slap. – SmallClanger Jun 17 '11 at 12:28
  • I should add that I don't think many people do this sort of blocking, so you shouldn't worry too much about it. You may find more people scoring for the SMTP `EHLO` domain not matching the `From:` domain. There are still legitimate reasons why these don't match; but the cases are nowhere near as common. – SmallClanger Jun 17 '11 at 12:31