[Novalug] SMTP service providers

Rich Kulawiec rsk@gsp.org
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 "joe@example.net" and is then allowed
to submit messages that are from joe@example.net -- but not from
anybody/anywhere else.

This prevents Joe from engaging in local forgery (mary@example.net)
and global forgery (randomstuff@example.org) 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 joe@example.com
or joseph@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 joe@example.com!"  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.

2. Backscatter.

A random mail system gets its hands on a message putatively from
joe@example.com, decides it's spam or infested with malware, decides to
bounce it back to the sender, sends it to joe@example.com...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 --
by definition.)

3. Forgery. 

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 [1]) 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,
depends, 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:

	host-190-131-67-48.ecutel.net.ec
	ip-186.249.204-230.globalwave.com.br
	177-179-155-4.user.veloxzone.com.br
	dhcp-209-159-206-139.bhfc.net
	235.66.113.112.broad.km.yn.dynamic.163data.com.cn
	95.39.46.54.static.user.ono.com
	107-173-27-162-host.colocrossing.com
	a2i805.smtp2go.com
	fixed-188-29-187-188-29-5.iusacell.net
	50-61.hanastarnet
	b1c3a645.virtua.com.br
	pc-184-205.cecyt8.ipn.mx
	114-43-108-97.dynamic.hinet.net
	105-185-4-232.apn.mobile.telkomsa.net
	c-87-3.cust.wadsl.it
	p50933b1c.dip0.t-ipconnect.de

What do these have in common?  Now compare/contrast with these:

	puck.nether.net
	mailgate.medicine.wisc.edu
	lennier.cc.vt.edu
	smtpout.karoo.kcom.com
	lists.openbsd.org
	smtp3.stanford.edu
	mailout.cymru.com
	mail.nanog.org
	ironman.ucdenver.edu
	outbound.smtp.vt.edu
	support.opsdc.com
	smtp.gms.com
	tarragon.mail.virginia.edu

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.

---rsk

[1] 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 mailing list