[Novalug] SMTP service providers
Thu Dec 8 09:13:35 EST 2016
On Sat, Nov 19, 2016 at 02:18:33PM -0500, Jon LaBadie via Novalug wrote:
> Verizon threw me a curve ball this week. For a long
> time they have insisted on all outbound email go
> through their smtp system. That is still true, with
> the addition that the From: and Reply-To: headers must
> be valid XXX@verizon.net email addresses.
[ One of many overdue replies. This is hasty but will hopefully
suffice to shed some light on the matter. ---rsk ]
Let me start by saying that Verizon has a long, sad history
of doing abrupt things with email, and some of what they've done has
been really stupid. (Examples: 1) blocking most of Europe because it
was allegedly a major spam source...while Verizon's own network was
overflowing with botted systems spewing spam. 2) Using sender callbacks,
not only an ineffective and stupid practice, but an abusive one.
They eventually stopped doing both of these, but it took them years to
figure out their mistakes.)
That said: limiting envelope-senders when mail is submitted isn't
necessarily a bad thing. (And while I can't definitively tell
from context, I presume you're talking about mail submission,
not mail relay.) To explain:
A good practice in mail systems is to only allow the envelope-sender
that matches the authenticated user. In other words, if Joe is a
customer of example.net, and wants to send a message via example.net,
then Joe authenticates (via a username and a password) with one
of example.net's mail servers as "firstname.lastname@example.org" and is then allowed
to submit messages that are from email@example.com -- but not from
This prevents Joe from engaging in local forgery (firstname.lastname@example.org)
and global forgery (email@example.com) but it also means that
Joe isn't able to submit mail from his own domain example.com.
That's because -- absent other mechanisms -- there's no way for
example.net's mail servers to know that Joe really is firstname.lastname@example.org
or email@example.com or anyone/anything else.
This is a partial (albeit flawed) solution to a bunch of problems, among them:
1. Misattribution of spam.
"I just got spam from firstname.lastname@example.org!" No. You didn't. That message
was never anywhere near example.com. It's a forgery, aka. "a joe job"
(which is why I chose "joe" as the LHS) designed to misdirect blame.
"Joe jobs" are sometimes launched by spammers in attempts to harass
anti-spam folks; it's generally recognized that when this happens,
it's retaliation for excellent work.
A random mail system gets its hands on a message putatively from
email@example.com, decides it's spam or infested with malware, decides to
bounce it back to the sender, sends it to firstname.lastname@example.org...who is not
actually the sender. Of course the REAL solution for this is never to
bounce, always to reject, but there are still backscatter edge cases
that are hard to get right. (Note that there are blacklists which
target backscattering mail systems, because it is, after all, spam --
I've never considered email forgery a significant problem.
Unless your name is "Paypal" or "American Express", etc., you are usually
not important enough to forge. (And financial institutions, for all
their hand-wringing about this, are some of the very worst mail
operations on the planet. They can't even get basics right, and
they've spent years training their customers to be phish victims.
But I digress.) However, it is true that constraining the envelope
sender this way helps somewhat. (Until of course 500M+ of your accounts
are compromised and then their new owners can send mail using those
credentials, which you will dutifully mark as legitimate via DKIM.
Thanks a lot for that, Yahoo. But I digress. Again.)
Going a bit further/sideways:
There are also a number of extant technologies that are designed
to curtail mail forgery by allowing domain owners to designate
the systems that are allowed to emit mail with their domain on
the RHS of the envelope sender, or to sign messages cryptographically.
E.g., "mail from example.com will only come from 192.168.10.14
and 192.168.10.15" or "mail from example.net will only come from
10.0.0.5/24" or "this message is cryptographically signed by
example.org". This ecosystem is currently a mess: some people
have deployed these, some haven't; some people check for them;
some don't; and so on. There's also been a fair amount of hype
(in some cases: a LOT of hype ) that greatly exaggerates what
these technologies are capable of. It's not clear how this is
all going to shake out.
What IS clear is that this stuff breaks things. Mail forwarding gets
broken (unless you take great pains to implement workarounds)
even though mail forwarding has been working just fine for decades
and is not a significant part of the problem set. Mailing lists
get broken -- same comment. (Which is why this list is configured
as it is instead of how I'd prefer it to be.)
So all that said: it's not possible to say, in the general case, what
will happen with mail sent from smtp2go. Depends on how they run the
operation (including postmaster and abuse handling), depends on where
that mail is going, depends on who's using which technology, depends on
what they do with traffic that doesn't pass the checks, depends,
My initial comment, though, based on a sample set size of 1, is that
they need to rethink how they name their mail hosts. Clearly they
have not been paying attention for the past 15 years.
To explain that snarky comment: look at these hostnames:
What do these have in common? Now compare/contrast with these:
None of the ones in the first group look like the names of hosts that
someone actually intended to be a mail server. Oh, they're ALL sending
mail: but with one exception it's all spam and it's being sent without the
knowledge/consent of the former owner of the system in question. All of
the ones in second group are actual real live legitimate mail servers.
More directly: real mail servers have real hostnames, quite often
containing the strings "smtp" or "mail", or in subdomains containing
those strings. Like the second group. This has been a de facto best
practice since the rise of the bots, 15-ish years ago. No, there's no RFC;
it's not required. But it's very easy to do and it avoids problems.
 The canonical example of this sort of hype is this statement:
"Spam as a technical problem is solved by SPF."
That was on SPF's home page when it was announced. Shortly thereafter,
spammers demonstrated that they understood very clearly by quickly becoming
the largest group of SPF early adopters.
More information about the Novalug