ATSPACE seems incapable of using SPF properly

ATSPACE tightened up their SMTP mail servers so hosted domains won’t be used for SPAM. Great. I’m a customer; please tell me first.

As of January 1, 2018 I can’t send mail any more from my laptop to their SMTP server. Also, companies that send me mail have started calling to say their email to me is being bounced. Bad on ATSPACE. Their customer service has been abysmal. They say nothing of substance, sending me on goose chases.

For instance, when I sent them a transcript of a telnet session with their SMTP server, they said I have a bad router or my firewall is broke. What?! The ASCII text was clearly sent to/from their server and rejected. And so on…  This has gone on for 2 months.

More security usually causes more pain.  Mail servers get inundated with requests to accept mail. Some used to work without even a username or password! Now, most require at least a username and password. About 2017, passwords became insufficient. Now, servers are requiring SPF certification of the email sender. In other words, when someone tries to submit an email associated with your domain, the mail server actually looks up your domain and pulls the SPF record you have created in your DNS records. This record tells them what IP addresses are authorized to send email in the name of your domain. If the actual submitter passes the rule sets, all is good. Otherwise the mail is rejected – often with a disconnect. Or, if the submitter cannot be resolved to an IP address, you’ll probably get a #103b error or a “host not found” error.

“Associated with your domain” is sketchy. Remember, this was designed for cross-national mail servers to talk with each other. My laptop is not a mail transfer server – only an end-user mail submission client. When it’s just an individual sitting at a laptop trying to submit an email to an SMTP server, the process gets sketchy. It’s not clear what the potential mail receiving server actually tries to resolve to an IP address from whence to pull an SPF record – a public IP? a NAT’d LAN IP? a hostname? a domain name? NetBIOS name?

Postmarkapp.com has a wonderful SPF tutorial and they say the Return-Path email is used to get an IP. It’s not clear ~what~ the SMTP recipient gets as a Return-Path when there isn’t a Return-Path because the only two things submitted are the MAIL FROM address and the RCPT TO address (and, of course, the implicit IP address the SMTP communication is coming from).

But a for-sale host and email service like ATSPACE should be able to handle the added technical requirements of an end-user mail submission client.  They are not.  They are 1) silently bouncing all email when the mail transfer agent gives them a hostname they cannot lookup with DNS.  I know ~why~ they’re doing this, but it is killing my ability to receive email.

They’re refusing email from my own home laptop SMTP submission because it doesn’t provide a FQDN. In my personal tests (laptop submitting to ATSPACE’s SMTP server from behind a NAT router cable modem), everything publicly looks like it comes from the same external IP address. And I keep the MAIL FROM and RCPT TO addresses the same while doing email send tests. “EHLO [10.0.0.107]” is rejected by ATSPACE while “EHLO elite” works with ATSPACE (elite is the netBIOS network name of a laptop I use, but actually they accept any alpha trash word).  That’s a capricious and incorrect distinction.  All the big boys like Yahoo, Gmail, GoDaddy, and others accept either from me.

In fact, RFC 2821 (SMTP) says: “In situations in which the SMTP client system does not have a meaningful domain name, the client should send an address literal” Also, see section 3.6 of the same RFC: “The domain name given in the EHLO command must be either a primary host name (a domain name that resolves to an A record) or, if the hose has no name, an address literal.”

Okay.  So ATSPACE, you’re wrong to accept a NetBIOS name, and you’re wrong to ~not~ accept my address literal of 10.0.0.107!

BTW, Mac Mail and Thunderbird send an IP address in the EHLO command and Outlook sends the netBIOS name (or %COMPUTERNAME% to be more precise) in the EHLO command.

To be clear, there are two steps to using SPF records:

1. retrieve the SPF record from whoever is contacting you.
2. interpret it to see if the submitter is legitimate.

ATSPACE is failing on Step 1. Maybe they will do the right thing when they can retrieve an SPF record.  But they aren’t getting to Step 2 are bouncing all inbound mail whenever they can’t go get an SPF record from someone. That is intolerable and they’re going to lose customers.

Extra resources and commentary:

stackoverflow.com
If no Return-Path:, Sender: is used for bounces.
If no Sender:, From: is used for bounces.

openspf.org
MX records tell the world what machines receive mail for the domain.
SPF records tell the world what machines may send mail from the domain.

However! “For the domain” is defined as the part of the email after the @ sign. “From the domain” is NOT defined as the part of the email after the @ sign in the From field. Instead, “from the domain” is defined by part after the @ sign in the Return-Path field.

Best SPF checker:

kitterman.com

Best SPF description: postmarkapp.com.  See the yellow flowchart

https://postmarkapp.com/guides/spf

Best check everything: mxtoolbox.com

openspf common mistakes

Outlook puts %COMPUTERNAME% in the EHLO identification command.

Demanding a FQDM with the EHLO command is a broke idea.

Thunderbird sends IP address for EHLO

Once ATSPACE successfully retrieves the SPF record, what IP address does it use to compare to the rule set defined in the SPF record?

Specifying the right SPF record is only the second problem. The first problem is finding which DNS record to retrieve; the looker-upper must be able to find you on the internet. How is ~that~ done if I’m behind a NAT?

Whatever my software announces itself as, ATSPACE insists this must resolve to some public internet address, but if this is true, how can any computer behind a NAT router work?   The ATSPACE policy also fails for any company that has an outbound email server named baracuda.company.com or cuda.company.com or anything.company.com, because although company.com is findable on the internet, of course their internally named emails server isn’t.

None of my other ISPs have any trouble with this issue.  Maybe every company trying to send me emails can fix it on their end to satisfy ATSPACE’s arrogance.  An individual laptop user cannot change what the email program sends out to identify itself.  Maybe if ATSPACE loses several thousand customers, they’ll start to pay attention.