EmailDiscussions.com - View Single Post - Successful delivery of emails with spoofed headers

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,924	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