[conspire] Case study in modern forgery of SMTP headers

Fri Nov 6 17:23:22 PST 2015

In which, forgery victim Michael Siladi encounters corporate
obliviousness.

----- Forwarded message from Michael Siladi <msiladi at ix.netcom.com> -----

Date: Fri, 6 Nov 2015 15:10:25 -0800
From: Michael Siladi <msiladi at ix.netcom.com>
To: Rick Moen <rick at linuxmafia.com>
Cc: Geo Mealer <geo at snarksoft.com>
Subject: Re: [Basfa] Fw: new message

Rick:

I've spent about 45 minutes (in two calls) talking with six different
Earthlink support people trying to explain that my email address is
being forged into spam being sent from non-Earthlink servers.

The fifth person I talked to (the second person of the second call)
was actually in the US, and understood that the situation of my
account being used to forge spam is different from my account being
used to send spam, and connected me with a tech manager who had a
glimmer about what I was talking about.

I'm now waiting for a call back ("within 48-72 hours") from an actual
data center admin who might be able to assist me with my goal of
helping Earthlink (and my reputation.)

I feel like Don Quixote, tilting a windmills, yet I know my cause is noble.

Cheers,
Michael

========================================================

On 11/3/2015 10:16 PM, Rick Moen wrote:
> Quoting Michael Siladi (msiladi at ix.netcom.com):
> 
>> Rick, Geo:
>> 
>> Many thanks for your assistance in this matter. It is somewhat of a
>> relief to know that the email really didn't come from me.
>> 
>> Gold Stars to both of you!
> You're very welcome.
> 
> You might want to pester Netcom to immediately start publishing an SPF
> and/or a DKIM record in its DNS.  SPF was invented in 2003, so Netcom is
> 12 years overdue in protecting its users against SMTP forgery.
> 
> For those two schemes to do real good, SMTP receiving software must
> check SPF and preferably also DKIM, but forgery detection & rejection
> isn't even possible withot the information in the DNS.
> 
> It would be in a 'TXT' DNS record.  As you can see below, querying for
> such a TXT record yields a null result.
> 
> $ dig -t txt netcom.com +short
> $
> 
> Compare what I have for my own primary domain:
> 
> $ dig -t txt linuxmafia.com +short
> "v=spf1 a mx -all"
> $
> 
> Until Netcom publishes SMTP authentication records, receivers such as
> Dreamhost (which is where BASFA's mailing list currently lives) have
> no reasonable way of detecting and rejecting forged messages purporting
> to be from msiladi at ix.netcom.com that didn't come from Netcom's SMTP
> hosts.

----- End forwarded message -----
----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Fri, 6 Nov 2015 17:20:54 -0800
From: Rick Moen <rick at linuxmafia.com>
To: Michael Siladi <msiladi at ix.netcom.com>
Cc: Geo Mealer <geo at snarksoft.com>
Subject: Re: [Basfa] Fw: new message
Organization: If you lived here, you'd be $HOME already.

Quoting Michael Siladi (msiladi at ix.netcom.com):

> I've spent about 45 minutes (in two calls) talking with six
> different Earthlink support people trying to explain that my email
> address is being forged into spam being sent from non-Earthlink
> servers.

Michael --

It actually took me a few minutes to figure out what EarthLink had to do
with this, because I really don't follow ISP follies.  I assume
you're probably a Netcom old-timer from pre-1997 days.  1997 was when 
ICG Communications bought out Netcom and immediately fobbed it off to
MindSpring, which then in 2000 merged with EarthLink.  (I didn't know
this; just now looked it up.)

ISPs almost always leak clue upon being acquired, but I assume this
isn't news to you.

> The fifth person I talked to (the second person of the second call)
> was actually in the US, and understood that the situation of my
> account being used to forge spam is different from my account being
> used to send spam, and connected me with a tech manager who had a
> glimmer about what I was talking about.
> 
> I'm now waiting for a call back ("within 48-72 hours") from an
> actual data center admin who might be able to assist me with my goal
> of helping Earthlink (and my reputation.)
> 
> I feel like Don Quixote, tilting a windmills, yet I know my cause is noble.

In case it helps, you can point out to the manager that you also want to
protect _their_ reputation.  

The forgery method in use can be used to impersonate any e-mail sender
at all, and that cannot be helped, as the capability is inherent in the
way SMTP works.  It's been known since the 1997 'revenge-spam' attack on 
Joe Doll.  (See 'Joe-job' entries on http://linuxmafia.com/kb/Mail .)
However, by publishing either a SPF record or a DKIM record (or both) in its 
public DNS, EarthLink d/b/a Netcom can make such forgeries detectable.

However...

I regret to inform you that there's a strong possibility EarthLink d/b/a
Netcom isn't providing SPF/DKIM authentication data, because it made a
policy decision not to, in turn because management feels some Netcom
users will object to certain of their ill-advised habits resulting in
mail that gets tagged as a probable forgery.

https://en.wikipedia.org/wiki/Sender_Policy_Framework#Caveats

Those 'ill-advised habits' amount to customers wanting to originate
outbound SMTP (of the classic port 25/tcp variety) from any IP address
in the world at their discretion, or alternatively to redirect their 
mail through aribtrary SMTP relays at their discretion -- habits that 
make it impossible to say 'accept mail purporting to be from this domain
only if it originates from one of these specified SMTP machines'.

Feet-dragging by large ISPs is common.  Consider GMail, one of the
less-bad (looking up GMail's SPF record):

$ dig -t txt gmail.com +short
"v=spf1 redirect=_spf.google.com"
$ 

That 'redirect' record means what you think it does, so we now have to 
make a second query, following the redirect:

$ dig -t txt _spf.google.com +short 
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com
include:_netblocks3.google.com ~all"
$

In English, it says:  'Consider authentic as mail senders the IPs you
can get by querying my _netblocks, _netblocks2, and netblock2 lists.
If the sending IP isn't in their, you should SOFTFAIL it.'

The problem is the SOFTFAIL, indicated by the tilde before the keyword
'all' instead of a hyphen that would have said FAIL.  This is Google
management forcing its Operations staff to publish deliberately
wishy-washy SPF data.  

https://wiki.apache.org/spamassassin/Rules/SPF_SOFTFAIL

   A "SoftFail" result should be treated as somewhere between a "Fail"
   and a "Neutral". The domain believes the host is not authorized but
   is not willing to make that strong of a statement. Receiving software
   SHOULD NOT reject the message based solely on this result, but MAY
   subject the message to closer scrutiny than normal.

   The domain owner wants to discourage the use of this host and thus
   desires limited feedback when a "SoftFail" result occurs. For
   example, the recipient's Mail User Agent (MUA) could highlight the
   "SoftFail" status, or the receiving MTA could give the sender a
   message using a technique called "greylisting" whereby the MTA can
   issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the
   first time the message is received, but accept it the second time.

Official description at http://www.openspf.org/SPF_Record_Syntax :

   Explanation:  The SPF record has designated the host as NOT being
   allowed to send but is in transition.

   Intended action:  accept but mark

SOFTFAIL is in practice barely better than no information at all.  It
says, more-or-less 'Well, the sender IP _might_ be a forgery sender, but
it also might not.  Future hazy.  Ask again later.'

To make that personal, imagine that EarthLink d/b/a Netcom grudgingly
decides to start publishing an SPF record and/or a DKIM one, and then 
your msiladi at ix.netcom.com mail gets forged in spam to people you care
about, again.  You get in touch with someone technical at the outfit
that received the forged mail, and you say 'Well, does your SMTP host
bother to check SPF or DKIM on mail allegedly sent by ix.netcom.com?'
And a senior sysadmin there says 'Yeah, dude, and all it says is here's
a list of valid sender IPs, but that we _shouldn't_ reject mail from an 
IP not on the list.'

That's SOFTFAIL.  IMO, that and $2.25 will get you a ride on Muni.

Yahoo is worse.

$ dig -t txt yahoo.com +short
"v=spf1 redirect=_spf.mail.yahoo.com"
$ dig -t txt _spf.mail.yahoo.com +short
"v=spf1 ptr:yahoo.com ptr:yahoo.net ?all"
$

Notice the '?' operator.  That's even worse than '~', and designates
NEUTRAL.  Official explanation at http://www.openspf.org/SPF_Record_Syntax :

  Explanation:  The SPF record specifies explicitly that nothing can be
  said about validity.

  Intended action:  accept

Ask yourself:  Why would a domain operator deliberately publish an SPF
record that explicitly says it's declaring nothing?  This seems like a
management directive to create an explicitly zero-effect SPF record just 
so the firm can say it has an SPF record and technically uniformed
people will be fooled.

That's NEUTRAL.  That and your $2.25 will _definitely_ get you zero
change from Muni.

I haven't bothered to look for DKIM information, but above should give
you a notion of the problem.

----- End forwarded message -----