Successful delivery of emails with spoofed headers

Mr5o1 · 31 Mar 2017, 01:52 PM

One of my co-workers received an email with spoofed headers "from" me. I thought that this thought of thing wasn't really possible if things are set up correctly, so I'm trying to figure out whether this means I've missed something.

Here's the full raw message, but I've replaced my domains and addresses.

Code:

Delivered-To: recipient_gmail_id@gmail.com
Received: by 10.223.177.130 with SMTP id q2csp2261010wra;
        Thu, 30 Mar 2017 19:51:22 -0700 (PDT)
X-Received: by 10.55.148.71 with SMTP id w68mr642645qkd.268.1490928682633;
        Thu, 30 Mar 2017 19:51:22 -0700 (PDT)
Return-Path: <1billion@melakoster.com>
Received: from forward2-smtp.messagingengine.com (forward2-smtp.messagingengine.com. [66.111.4.226])
        by mx.google.com with ESMTPS id t62si3512532qkc.177.2017.03.30.19.51.22
        for <recipient_gmail_id@gmail.com>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 30 Mar 2017 19:51:22 -0700 (PDT)
Received-SPF: neutral (google.com: 66.111.4.226 is neither permitted nor denied by best guess record for domain of 1billion@melakoster.com) client-ip=66.111.4.226;
Authentication-Results: mx.google.com;
       spf=neutral (google.com: 66.111.4.226 is neither permitted nor denied by best guess record for domain of 1billion@melakoster.com) smtp.mailfrom=1billion@melakoster.com
Received: from mailmx.nyi.internal (mx2.nyi.internal [10.202.2.201]) by mailforward.nyi.internal (Postfix) with ESMTP id 1995A13C3 for <recipient_gmail_id@gmail.com>; Thu, 30 Mar 2017 22:51:22 -0400 (EDT)
Received: from mx2.messagingengine.com (localhost [127.0.0.1]) by mailmx.nyi.internal (Postfix) with ESMTP id 0FE03D812C for <coworker@ourdomain.com.au>; Thu, 30 Mar 2017 22:51:22 -0400 (EDT)
Received: from mx2.messagingengine.com (localhost [127.0.0.1])
    by mx2.messagingengine.com (Authentication Milter) with ESMTP
    id CC04B40548E;
    Thu, 30 Mar 2017 22:51:22 -0400
Authentication-Results: mx2.messagingengine.com;
    dkim=none (no signatures found);
    dmarc=none (p=none) header.from=ourdomain.com.au;
    spf=none smtp.mailfrom=1billion@melakoster.com smtp.helo=p3plwbeout02-02.prod.phx3.secureserver.net
Received-SPF: none
    (melakoster.com: No applicable sender policy available)
    receiver=mx2.messagingengine.com;
    identity=mailfrom;
    envelope-from="1billion@melakoster.com";
    helo=p3plwbeout02-02.prod.phx3.secureserver.net;
    client-ip=72.167.218.32
Received: from p3plwbeout02-02.prod.phx3.secureserver.net (p3plsmtp02-02.prod.phx3.secureserver.net [72.167.218.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.messagingengine.com (Postfix) with ESMTPS for <coworker@ourdomain.com.au>; Thu, 30 Mar 2017 22:51:21 -0400 (EDT)
Received: from localhost ([72.167.218.15]) by :WBEOUT: with SMTP id tmeHcZWgvUsyotmeHcXu9l; Thu, 30 Mar 2017 19:50:49 -0700
X-SID: tmeHcZWgvUsyo
Received: (qmail 3500 invoked by uid 99); 31 Mar 2017 02:50:49 -0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"
X-Originating-IP: 105.0.36.156
User-Agent: Workspace Webmail 6.6.16
Message-Id: <20170330195046.4c44dbeb8d194485a4a3f447668ee816.b00bb92ff0.wbe@email02.godaddy.com>
From: me Surname <me@ourdomain.com.au>
X-Sender: 1billion@melakoster.com
Reply-To: me Surname <me@mymail-network.com>
To: coworker@ourdomain.com.au
Subject: Process
Date: Thu, 30 Mar 2017 19:50:46 -0700
Mime-Version: 1.0
X-CMAE-Envelope: MS4wfHsxmI1B4cDdUB+52edyAgbMQ7JyfW1md9TY8IOqk6vOAVypaPtmJqjWNiM82fBGVVm2uQ9ajB6ItC+H/yDl5qvVlEC+Z++45aMvfzQGcAuNxcYG5/ye IkdpDrAfRUnhLIsISA3zUwAIoBpGAb7z0ROjizJLDKNSApoQOF0u20SX

<html><body><span style=3D"font-family:Verdana; color:#000000; font-size:10=
pt;"><div><span>Hi coworker,</span></div><div><br></div><div>Are you at the offi=
ce to make a payment now? get back to me now so I can send through the deta=
ils.<br><br>Regards,</div><div><br></div><div style=3D"">me</div></span><=
/body></html>

In summary it looks like:

From: my actual address
X-Sender: attacker address & domain
Reply-To: My Name <myuser@some-other-domain.com>

AFAIK my domain records are set up correctly with SPF & DKIM records.
I know that fastmail doesn't use DKIM or SPF like a firm pass or fail, but I would have thought that for a sending domain registered with fastmail this kind of spoof would have been blocked.

Anyhow, as I said above, I'm not trying to rip on fastmail spam detection (or lack there of), but rather, just trying to confirm whether this is indicative of anything set up correctly with fastmail & my domain.

Thanks in advance.

BritTim · 31 Mar 2017, 02:43 PM

I do not believe this is a spam detection issue. (The spam checks are by Google). The possible issue is abuse. It could be argued that FastMail ought to prevent your sending out emails without proving ownership of the sending address. Some other services do this, and it is a real pain. FastMail's approach seems to be that, if you are shown to be a spammer, spoofing email addresses you do not own without permission, then your account will just be terminated.

Mr5o1 · 31 Mar 2017, 04:06 PM

Quote:

Originally Posted by BritTim

I do not believe this is a spam detection issue. (The spam checks are by Google). The possible issue is abuse. It could be argued that FastMail ought to prevent your sending out emails without proving ownership of the sending address. Some other services do this, and it is a real pain. FastMail's approach seems to be that, if you are shown to be a spammer, spoofing email addresses you do not own without permission, then your account will just be terminated.

Maybe I haven't explained this clearly.. the source of this email is not a fastmail server.

attacker just sent the email to a fastmail account, which has forwarded it to a gmail account.

BritTim · 31 Mar 2017, 05:46 PM

How is the forwarding arranged? Usually, in an email received at FastMail and subsequently forwarded, I would expect to see the x-spam... headers. Is the forwarding achieved through a virtual domain? I guess, if so, the message would be forwarded without any spam checks.

n5bb · 1 Apr 2017, 02:02 PM

Sorry, but this is a very long response with many details. The answers to your questions are not easy! There is no logical reason for Fastmail to by default not forward the message you posted, but if you change to using the rules system for forwarding it's quite possible to block forwarding if the From address is in your domain, or more complex blocking. If you want to try this let me know in this thread exactly what you want to block and not block and I can help you come up with appropriate complex forwarding rules.

I agree that it's obvious that this message was forwarding using the Settings>Aliases screen, which means that the spam filter and other rules were not executed. There are two ways to set up forwarding:

Alias redirection: All messages received at this alias are forwarded directly without your sieve script (which is where the spam filter and all rules are located) being executed. The only headers which are added by Fastmail are:
- Received: These are normal headers which show when the message was received by a Fastmail server.
- Authentication-Results: The Fastmail generated header is followed immediately by a server name at the messagingengine.com domain. This is a summary of the SPF, DKIM, and DMARC authentication results when the message was
- Received-SPF: This immediately follows the Authentication-Results header and is a detailed description of the SPF test results.
Rules forwarding: The forwarding rules are located after the spam filter and discard rules in your sieve script, so forwarding only occurs if the message is not blocked by those sieve rules. The headers you see when a message is received at your account in the normal fashion are copied into the forwarded message, usually including: X-Cyrus-Session-Id, X-Sieve, X-Spam-known-sender, X-Spam-score, X-Spam-hits, X-Spam-charsets, X-Resolved-to, X-Delivered-to, X-Mail-from, additional Received headers, Authentication-Results at a messagingengine.com domain server, and Received-SPF.
For more information, see: How to set up email forwarding

When the message you posted was checked by Fastmail during the alias redirection forwarding, here is what was found:

Code:

Authentication-Results: mx2.messagingengine.com;
    dkim=none (no signatures found);
    dmarc=none (p=none) header.from=ourdomain.com.au;
    spf=none smtp.mailfrom=1billion@melakoster.com smtp.helo=p3plwbeout02-02.prod.phx3.secureserver.net
Received-SPF: none
    (melakoster.com: No applicable sender policy available)
    receiver=mx2.messagingengine.com;
    identity=mailfrom;
    envelope-from="1billion@melakoster.com";
    helo=p3plwbeout02-02.prod.phx3.secureserver.net;
    client-ip=72.167.218.32

The spammer server identified itself (helo) as in the secureserver.net domain, which is owned by GoDaddy. The server identified the envelope sender of the message as at the "melakoster.com" domain, which was registered through GoDaddy. That domain has no published SPF policy, and the message was not DKIM signed. What I believe is your munged domain ourdomain.com.au has no DMARC policy, according to these headers. The result of these tests are:

dkim=none (no signatures found);
- The message was not DKIM signed, so you can't tell if it was modified during transit. Many old email systems and domains don't sign their outgoing messages, so you shouldn't block all messages which are missing DKIM.
dmarc=none (p=none) header.from=ourdomain.com.au;
- Your domain does not specify a DMARC policy. So the receiving email system has no reason to reject messages sent by anyone (using any sending server), even if the From human-readable header is at your domain. For example, you might want to send using your domain in the From header using your ISP's email system, and you haven't declared a DMARC policy to prevent such use.
spf=none ... ...
- The source sending server declared the message was sent from a domain which has no SPF policy. This means that they allow messages to be sent from any server.

It's important to realize that the receiving email system can make decisions about the validity of a message by examining the DKIM and SPF results. But DKIM allows a message to be signed based on DNS records of any domain, and by itself it only indicates that the message was not altered in transit. SPF only indicates that the message was sent by a server authorized by the envelope sender domain, and the message is only rejected if the published policy is -all.

Neither DKIM nor SPF are required in a message, and neither is tied to the From human-readable header. You must publish a DMARC policy for your domain if you want to declare what you wish to be done if SPF and DKIM both fail, and to force alignment of the From header domain with the signing domains. Since message forwarding breaks SPF (as used by DMARC domain alignment) even if SRS is used, your only chance of using DMARC to protect your domain is if messages you send are only carefully forwarded so that DKIM signing isn't broken.

Bill

1 Apr 2017, 02:02 PM	#5
n5bb Intergalactic Postmaster Join Date: May 2004 Location: Irving, Texas Posts: 8,926	Forwarding with SPF, DKIM, and DMARC authentication Sorry, but this is a very long response with many details. The answers to your questions are not easy! There is no logical reason for Fastmail to by default not forward the message you posted, but if you change to using the rules system for forwarding it's quite possible to block forwarding if the From address is in your domain, or more complex blocking. If you want to try this let me know in this thread exactly what you want to block and not block and I can help you come up with appropriate complex forwarding rules. I agree that it's obvious that this message was forwarding using the Settings>Aliases screen, which means that the spam filter and other rules were not executed. There are two ways to set up forwarding: Alias redirection: All messages received at this alias are forwarded directly without your sieve script (which is where the spam filter and all rules are located) being executed. The only headers which are added by Fastmail are: Received: These are normal headers which show when the message was received by a Fastmail server. Authentication-Results: The Fastmail generated header is followed immediately by a server name at the messagingengine.com domain. This is a summary of the SPF, DKIM, and DMARC authentication results when the message was Received-SPF: This immediately follows the Authentication-Results header and is a detailed description of the SPF test results. Rules forwarding: The forwarding rules are located after the spam filter and discard rules in your sieve script, so forwarding only occurs if the message is not blocked by those sieve rules. The headers you see when a message is received at your account in the normal fashion are copied into the forwarded message, usually including: X-Cyrus-Session-Id, X-Sieve, X-Spam-known-sender, X-Spam-score, X-Spam-hits, X-Spam-charsets, X-Resolved-to, X-Delivered-to, X-Mail-from, additional Received headers, Authentication-Results at a messagingengine.com domain server, and Received-SPF. For more information, see: How to set up email forwarding When the message you posted was checked by Fastmail during the alias redirection forwarding, here is what was found: Code: Authentication-Results: mx2.messagingengine.com; dkim=none (no signatures found); dmarc=none (p=none) header.from=ourdomain.com.au; spf=none smtp.mailfrom=1billion@melakoster.com smtp.helo=p3plwbeout02-02.prod.phx3.secureserver.net Received-SPF: none (melakoster.com: No applicable sender policy available) receiver=mx2.messagingengine.com; identity=mailfrom; envelope-from="1billion@melakoster.com"; helo=p3plwbeout02-02.prod.phx3.secureserver.net; client-ip=72.167.218.32 The spammer server identified itself (helo) as in the secureserver.net domain, which is owned by GoDaddy. The server identified the envelope sender of the message as at the "melakoster.com" domain, which was registered through GoDaddy. That domain has no published SPF policy, and the message was not DKIM signed. What I believe is your munged domain ourdomain.com.au has no DMARC policy, according to these headers. The result of these tests are: dkim=none (no signatures found); The message was not DKIM signed, so you can't tell if it was modified during transit. Many old email systems and domains don't sign their outgoing messages, so you shouldn't block all messages which are missing DKIM. dmarc=none (p=none) header.from=ourdomain.com.au; Your domain does not specify a DMARC policy. So the receiving email system has no reason to reject messages sent by anyone (using any sending server), even if the From human-readable header is at your domain. For example, you might want to send using your domain in the From header using your ISP's email system, and you haven't declared a DMARC policy to prevent such use. spf=none ... ... The source sending server declared the message was sent from a domain which has no SPF policy. This means that they allow messages to be sent from any server. It's important to realize that the receiving email system can make decisions about the validity of a message by examining the DKIM and SPF results. But DKIM allows a message to be signed based on DNS records of any domain, and by itself it only indicates that the message was not altered in transit. SPF only indicates that the message was sent by a server authorized by the envelope sender domain, and the message is only rejected if the published policy is -all. Neither DKIM nor SPF are required in a message, and neither is tied to the From human-readable header. You must publish a DMARC policy for your domain if you want to declare what you wish to be done if SPF and DKIM both fail, and to force alignment of the From header domain with the signing domains. Since message forwarding breaks SPF (as used by DMARC domain alignment) even if SRS is used, your only chance of using DMARC to protect your domain is if messages you send are only carefully forwarded so that DKIM signing isn't broken. Bill

31 Mar 2017, 02:43 PM	#2
BritTim The "e" in e-mail Join Date: May 2003 Location: mostly in Thailand Posts: 3,090	I do not believe this is a spam detection issue. (The spam checks are by Google). The possible issue is abuse. It could be argued that FastMail ought to prevent your sending out emails without proving ownership of the sending address. Some other services do this, and it is a real pain. FastMail's approach seems to be that, if you are shown to be a spammer, spoofing email addresses you do not own without permission, then your account will just be terminated.

31 Mar 2017, 05:46 PM	#4
BritTim The "e" in e-mail Join Date: May 2003 Location: mostly in Thailand Posts: 3,090	How is the forwarding arranged? Usually, in an email received at FastMail and subsequently forwarded, I would expect to see the x-spam... headers. Is the forwarding achieved through a virtual domain? I guess, if so, the message would be forwarded without any spam checks.