The Hostile Email Landscape (liminality.xyz)

An anonymous reader writes: As we consolidate on just a few major email services, it becomes more and more difficult to launch your own mail server. From the article: "Email perfectly embodies the spirit of the internet: independent mail hosts exchanging messages, no host more or less important than any other. Joining the network is as easy as installing Sendmail and slapping on an MX record. At least, that used to be the case. If you were to launch a new mail server right now, many networks would simply refuse to speak to you. The problem: reputation. ... Earlier this year I moved my personal email from Google Apps to a self-hosted server, with hopes of launching a paid mail service à la Fastmail on the same infrastructure. ... I had no issues sending to other servers running Postfix or Exim; SpamAssassin happily gave me a 0.0 score, but most big services and corporate mail servers were rejecting my mail, or flagging it as spam: Outlook.com accepted my email, but discarded it. GMail flagged me as spam. MimeCast put my mail into a perpetual greylist. Corporate networks using Microsoft's Online Exchange Protection bounced my mail."

Comments

Don't Know How You Made That Conclusion

[0xG]

I run a small email system ~2500 users and don't have your problems...

Re:Don't Know How You Made That Conclusion

[beelsebob]

More likely, the original poster simply has his DNS misconfigured in some weird way, and doesn't know it.

Re:Don't Know How You Made That Conclusion

[Anonymous Coward]

I second that emotion. Current *big* players are trying to limit spam and phishing, and require a few ducks in a row before you stop getting caught in their filters. I suspect proper analysis of the configurations and logs would pinpoint the issue. DNS would be a quick start but the problem could be in a few places depending on what mail implementation he's using. On another note, is it possible OPs domain has been used for spam/phishing in the past? The UNI I work has dealt with blacklists in the past and it was merely a case of spoofing and those adding us to blacklists didn't do their diligence in tacking it down properly. *Posted anon as to not get fired*

Re:Don't Know How You Made That Conclusion

[acoustix]

I run a small email system ~2500 users and don't have your problems...

You probably have a dedicated/static IP and it isn't tainted from others who have used it before you.

For people trying to run their own email server at home it can be a real pain. ISP's blocking 25 and 587. DHCP means that your IP pool has a bad reputation. Etc...

Re: Don't Know How You Made That Conclusion

[Anonymous Coward]

Probably no SPF or TXT records

Re:Don't Know How You Made That Conclusion

[MyFirstNameIsPaul]

You need to go to their stupid new Postmaster service and 'fix' the 'issues'. I observed the exact same behavior for mail servers that hadn't changed a DNS record or even IP address in years roughly around the same time they launched this new 'service'. Coincidence? I think not.

Re:Don't Know How You Made That Conclusion

[bsdasym]

I'm with you here. OP sounds like just being paranoid and probably is not quite properly setup. I setup a new domain last month with it's own self-hosted email and had no problems at all getting email through to any of the major providers. To avoid trouble, you need at a minimum:
- An IP address in a block that doesn't already have a terrible reputation.
- Working, correct reverse DNS that matches the SMTP banner.
- Working, correct forward DNS for the MX records that also matches the SMTP banner.
- Correct SPF/TXT records covering your mailserver, even if you know SPF is stupid.
- A mailserver not configured as an open relay (duh).

With all this in place, I have had no problems getting through on a system with a domain and mail handling less than a week old.

Re:Don't Know How You Made That Conclusion

[Anonymous Coward]

+1
Rejections in my experience have nearly always always been related to the PTR record needs to be pointing to the domain actually sending the email, not the domain name in the email address. My limited understanding is this:

So if my email address matt@example.com uses mail.isp.com on port 25 to send email then the PTR needs for the ip address isp,com sends from needs to say mail.isp.com... not example.com as you might expect.

when isp.com talks to another smtp server it will be asked to id itself. The server should reply with its FQDN and it is this that the PTR record for the servers id needs to point to . Even if that server hosts hundreds of websites and email accounts.

I believe most VPS hosts allow this to be changed to whatever you want if you are given a fixed ip address. If they don't allow this to be changed then problems will occur and if you are handling emails you need to check before signing up. The PTR record is not applicable to a domain but to an IP address. You can only have one PTR record for an IP address.

That is if my memory serves correctly. When I set up email servers, I always seem to forget this until I do sending tests to yahoo and other big boys. Then I set it properly and things behave.

Other problems happen if using microsoft exchange and the srv fields in txt records for the dns are not set exactly right. Though I don't have to fiddle with this for obvious reasons.

 

Re: Don't Know How You Made That Conclusion

[slasher999]

Missing spf records were the first thing I thought of as well. That isn't a silver bullet by any means but can certainly help your ratings while you are new and building a reputation.

Re:Don't Know How You Made That Conclusion

[houghi]

Script kiddies. Even if the provider doesn't block ports, all email should be rightfully be blocked as there is no Reversed DNS. And by all things practical, a reversed DNS is only possible with a fixed IP.

And that is only for outgoing email. Letting incoming email depend on a non-fixed IP could lead to serious problems. I could mean somebody else receives your email on your (previous) IP address.

Also: if the provider leaver port 25 open for non-fixed IP addresses (we are unable to run an email server, because they do not get reversed IP) it opens the ports for a shitload of extra spam from people who have no idea on how to close their server as a relay server.

I was a script kiddie, played with it to learn and now I don't have incoming mail and use my provider for outgoing mail.

Re: Don't Know How You Made That Conclusion

[MightyMartian]

Missing SPF and possibility of being on one of the RBLs. I had that problem when we switched to a new ISP, and the address block we were given had ended up on Spamcop. It took a bit of doing, but within a day it was cleared up.

Re: Don't Know How You Made That Conclusion

[ttucker]

Adding DKIM signatures helps a lot too.

Re:Don't Know How You Made That Conclusion

[ttucker]

Having DKIM setup, and a legitimate signed TLS certificate helps some too.

Re: Don't Know How You Made That Conclusion

[AntiSol]

yep, SPF and DKIM records make a big difference. Also a PTR record (so that your IP resolves to e.g hostname.yourdomain.com rather than youraccount.yourwebhost.com) helps.

Re: Don't Know How You Made That Conclusion

[postbigbang]

Just having an .xyz TLD would be enough for me to bounce it. Without a single regret, I've bounced most of the new TLDs and for good reason: not a single message wasn't spam.

Can't count the number of .eu messages that are caught up in this, as well as anything from .cn-- as we have zero business coming from China, ever. Same goes for a lot of other country TLDs..... the ISPs serving them up don't care if I send an abuse complaint, in fact, most bounce an abuse complaint.

Re: Don't Know How You Made That Conclusion

[mikael]

That's not having your own email server unfortunately. Having the one true local email server is being able to send emails directly to other hosts. That works OK if you have a static commercial IP address. It will also work if you have a dynamic IP address and use your ISP's SENDMAIL, IMAP and POP3 servers. But if you try and send Email straight out from your dynamic IP address, it will get clobbered by various spam filters which filter out dynamic IP addresses (this range has been blocked due to past spam activity) based on registered domain ranges.

Re:Do your due dilligence...

[unrtst]

..and set up SPF entries and reverse DNS. Also make sure Postfix is locked down and not acting as an open relay. It really is not that hard, this article comes off as whiny "I can't do it, so the world is against me" at best.

Did you even read the article? There's not much more than the summary, but there he does make note that reverse DNS and SPF records, among other things, were setup:

I've done this before, ...: not on any blacklists, reverse DNS set up, SPF, DKIM and DMARC policies in place, etcetera. (Side note: mail-tester.com and Port25 are great for checking your setup.)

The near-conclusion quote is his real point:

...from Microsoft's Postmaster Troubleshooting page:

IPs not previously used to send email typically don’t have any reputation built up in our systems. As a result, emails from new IPs are more likely to experience deliverability issues. Once the IP has built a reputation for not sending spam, Outlook.com will typically allow for a better email delivery experience.

Loose the .xyz TLD

[JimMcc]

My guess is that the problem lies in the fact that the OP is using a garbage TLD. I've configured our mail server to silently drop all traffic from many of the new garbage TLDs, including .xyz. It does wonders for cutting down the spam levels. Sadly it's just a new version of Whack-a-Mole. Neither I, nor any of my users, appear to have gotten a legitimate email from any other these domains. I'll bet if the OP were to use a more traditional TLD, like .com, .uk, etc. there wouldn't be problems.

Re:Sorry, use a smarthost to give yourself a boost

[tepples]

Simple way to boost your reputation is to simply configure a smarthost to send outgoing mail securely.

That boosts the smarthost's reputation, not yours, unless I'm missing something fundamental.

Re:Settings to check:

[tlambert]

Read the article. Except for #1 and #5, he explicitly says he did all of these things.

Do I trust him, or do I trust the contents of his DNS server. I think I'm going to go with the DNS server.

dig -t MX geekmail.io
geekmail.io. 899 IN MX 10 mail.geekmail.io.

nslookup mail.geekmail.io
Non-authoritative answer:
Name: mail.geekmail.io
Address: 139.162.197.129

host 139.162.197.129
129.197.162.139.in-addr.arpa domain name pointer geekmail.io. ----- OOPS