ATSPACE tightened up their SMTP mail servers so hosted domains won’t be used for SPAM. Great. Please tell me first.
As of January 1, 2018 I can’t send mail 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, send 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. I cannot understand why every mail user doesn’t quit. I am being forced to do so.
More security. More pain. Basically, 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, even passwords weren’t good enough (not sure why). Now, servers are requiring SPF certification of the 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 test, 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 a 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 side actually tries to resolve to an IP address from whence to pull an SPF record. Postmarkapp.com has a wonderful SPF tutorial and they say the Return-Path email is used. 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. 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.
Worse, 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). What is going on?! All the big boys like Yahoo, Gmail, GoDaddy, and others accept both from me.
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.”
BTW, just FYI, 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:
- retrieve the SPF record from whoever is contacting you.
- 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:
If no Return-Path:, Sender: is used for bounces.
If no Sender:, From: is used for bounces.
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:
Best SPF description: postmarkapp.com. See the yellow flowchart
Best check everything: mxtoolbox.com
openspf common mistakes
Outlook puts %COMPUTERNAME% in the EHLO identification command.
Once ATSPACE successfully retrieves the SPF record, what IP address does it use to compare to the ruleset 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 must resolve to some public internet address. , but if this is true, how can any computer behind a NAT router work?