How to receive e-mail alerts from internal devices

JaredBusch

@tim_g said in How to receive e-mail alerts from internal devices:

@jaredbusch said in How to receive e-mail alerts from internal devices:

@tim_g said in How to receive e-mail alerts from internal devices:

For example, you cannot send an email to someone using my O365 email address (spoofing) because most mail services check for that.

This is totally not true. I can 100% send as you and it will go through almost everywhere. Very few places spam things on SPF rules.

@tim_g said in How to receive e-mail alerts from internal devices:

Also, in order to send as a legit O365 email address, you would of course need to authenticate through O365. (smtp authentication)

Also not true.

Send an email to my outlook.com email from my google.com email.

I'll PM you the addresses.

Will you?

I no longer have that system set up.

This was discussed in a thread about dnf-automatic and how it sends mail.

Obsolesce

@jaredbusch said in How to receive e-mail alerts from internal devices:

@tim_g said in How to receive e-mail alerts from internal devices:

@jaredbusch said in How to receive e-mail alerts from internal devices:

@tim_g said in How to receive e-mail alerts from internal devices:

For example, you cannot send an email to someone using my O365 email address (spoofing) because most mail services check for that.

This is totally not true. I can 100% send as you and it will go through almost everywhere. Very few places spam things on SPF rules.

@tim_g said in How to receive e-mail alerts from internal devices:

Also, in order to send as a legit O365 email address, you would of course need to authenticate through O365. (smtp authentication)

Also not true.

Send an email to my outlook.com email from my google.com email.

I'll PM you the addresses.

Will you?

I no longer have that system set up.

This was discussed in a thread about dnf-automatic and how it sends mail.

Yes I kinda remember it, but I must still not understand it.

At my company, we've tackled, in the past, email spoofing. So I do know it's possible to make it look like an email is coming from an email address that it's not actually coming from.

This no longer happens through O365. So, as a made up example, a CFO is no longer getting money transfer company email requests (via O365 email) from the CEO.

Obsolesce

So what I"m thinking, is that unless the outgoing email server is a trusted server, O365 won't allow it into it's system to be delivered to my email.

I can send an email from [email protected], to [email protected], because the email is coming from a trusted gmail server.

But if i set up some outgoing email server myself, and try to send an email from [email protected] to [email protected], I believe O365 will not let it through.

This is the point I was trying to make.

JaredBusch

@tim_g said in How to receive e-mail alerts from internal devices:

At my company, we've tackled, in the past, email spoofing. So I do know it's possible to make it look like an email is coming from an email address that it's not actually coming from.

Ah, I think that I see your confusion. You can easily generate an email that is not one email pretending to be from another address. It is simply "from" your address. The only technical thing that can be keyed on is the sending server not being your server. But this is not a restriction that email is designed to handle except with SPF.

@tim_g said in How to receive e-mail alerts from internal devices:

This no longer happens through O365. So, as a made up example, a CFO is no longer getting money transfer company email requests (via O365 email) from the CEO.

Correct, you can implement stricter controls, but they are not default, and most places to not have them. Generally SPF records are set to soft fail which increases the recipient systems chance to add it to SPAM, but only increases the chance.

Even if you set SPF to hard fail, many system never check it. So it would have no affect on the recipient.

In your case, with inbound email, you have restricted it beyond SPF by telling that system that, unless an email from one of your domains to one of your domains was authenticated, it will be killed.

JaredBusch

@tim_g said in How to receive e-mail alerts from internal devices:

So what I"m thinking, is that unless the outgoing email server is a trusted server, O365 won't allow it into it's system to be delivered to my email.

This is impossible, well not technically impossible, but would never be implemented. How are you defining trusted? SPF? See my above reply. Because what if I have no SPF record and I have internal Exchange at my Jared's Fucking Consulting Services? Are you saying that you will not receive my email?

But if i set up some outgoing email server myself, and try to send an email from [email protected] to [email protected], I believe O365 will not let it through.

I do not recall what services were tested other than Gmail, but yes, it will.

Your work domain will not because you have specifically told it to use SPF I assume.

This is a different issue than someone trying to send form a company email to a company email.

Obsolesce

@jaredbusch said in How to receive e-mail alerts from internal devices:

@tim_g said in How to receive e-mail alerts from internal devices:

So what I"m thinking, is that unless the outgoing email server is a trusted server, O365 won't allow it into it's system to be delivered to my email.

This is impossible, well not technically impossible, but would never be implemented. How are you defining trusted? SPF? See my above reply. Because what if I have no SPF record and I have internal Exchange at my Jared's Fucking Consulting Services? Are you saying that you will not receive my email?

But if i set up some outgoing email server myself, and try to send an email from [email protected] to [email protected], I believe O365 will not let it through.

I do not recall what services were tested other than Gmail, but yes, it will.

Your work domain will not because you have specifically told it to use SPF I assume.

This is a different issue than someone trying to send form a company email to a company email.

Okay I think I understand now.

It's different for me because I am specifically taking steps to block emails whose "from address" is not from a verified server... meaning if someone sends an email from [email protected], it will be blocked unless it actually came from a gmail.com email server?

JaredBusch

@tim_g said in How to receive e-mail alerts from internal devices:

@jaredbusch said in How to receive e-mail alerts from internal devices:

@tim_g said in How to receive e-mail alerts from internal devices:

So what I"m thinking, is that unless the outgoing email server is a trusted server, O365 won't allow it into it's system to be delivered to my email.

This is impossible, well not technically impossible, but would never be implemented. How are you defining trusted? SPF? See my above reply. Because what if I have no SPF record and I have internal Exchange at my Jared's Fucking Consulting Services? Are you saying that you will not receive my email?

But if i set up some outgoing email server myself, and try to send an email from [email protected] to [email protected], I believe O365 will not let it through.

I do not recall what services were tested other than Gmail, but yes, it will.

Your work domain will not because you have specifically told it to use SPF I assume.

This is a different issue than someone trying to send form a company email to a company email.

Okay I think I understand now.

It's different for me because I am specifically taking steps to block emails whose "from address" is not from a verified server... meaning if someone sends an email from [email protected], it will be blocked unless it actually came from a gmail.com email server?

Assuming that gmail.com is actually companydomain.com, yes you are correct.

zachary715

Yes we have our SPF record setup that if I try to send these alerts via [email protected], it will get blocked. I don't require it to be from my domain though at this time. I'm perfectly satisfied with it being from internaldomain.local just as long as I get the reports I need.

Obsolesce

@zachary715 said in How to receive e-mail alerts from internal devices:

Yes we have our SPF record setup that if I try to send these alerts via [email protected], it will get blocked. I don't require it to be from my domain though at this time. I'm perfectly satisfied with it being from internaldomain.local just as long as I get the reports I need.

Yeah then you won't need any authentication.

JaredBusch

@Tim_G I just changed my laptop's dnf-automatic setting as follows.

0_1521731675450_421f29a8-23e2-4a45-84bb-02d4f742d614-image.png

The server there is in my colo and is in the SPF for my company domain bundystl.com but obviously, I cannot change Gmail's SPF.

0_1521731785434_6861af55-e029-4f05-991b-f3769686b0ee-image.png

Now Google did soft check it.
But it still hit my inbox.
0_1521731839292_b78664c3-6bff-489d-8d59-e20f9d6b6220-image.png

0_1521731872094_1e8423e3-29dd-4264-a9a1-a84dc079f193-image.png

Here is the full header (redacted).

Delivered-To: [email protected]
Received: by 10.103.62.65 with SMTP id l62csp1114442vsa;
        Thu, 22 Mar 2018 08:08:41 -0700 (PDT)
X-Google-Smtp-Source: AG47ELs+6VQ7n+SHAtV9m4uOLgmv8vpQF4hFx6jJTiF0/7+D9fL9bUtFWE0UcMw1/FJjmE/+6IvQ
X-Received: by 2002:a24:bcc4:: with SMTP id n187-v6mr9355606ite.26.1521731321402;
        Thu, 22 Mar 2018 08:08:41 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1521731321; cv=none;
        d=google.com; s=arc-20160816;
        b=URXPlYi9YdJzlBGcevx/J53Ip1Ht0MP05i0n2WK1dXHbCYaXtmqG416NR0wlVWAe8Q
         mPTRB99J1AY6vo74dlJvDDQ9Fuj2AIndnq6zYztk0IMYa5Qfr0ZZvkXM67OBqrvsczdh
         3jScUQfbkfqoTktrNnwgtNz8Q20eYuTKbtbC5lSjRCBjzeIMg1NY4tTcw1xqgs3KvLKe
         SmT4s9pjux6vr5/7QOmCQyff0rTSgEhqF/l9tdrQI3BN3uwkSIAvqAKeW8MiX/p/wTKS
         C+HhTNgqQpFswivTfoXjaFUpOsfpGsvPj5DYnKeXD6pXfw7eObwGopdUKb2AV/ix+3Hw
         PzfQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=message-id:to:subject:from:date:content-transfer-encoding
         :mime-version:arc-authentication-results;
        bh=q5rj1FQFBZzNVe2kH8xvcqgQOwTh8q2EHL6ugR/7+BY=;
        b=Up+IsW9uxbxk3HQiojNEPiWZ6Vv88Y91fA07To2N+5jVZkuJATk0rPYu20hvG7Mr6O
         J/nEVoKT98hFhmwXasHupRvqIIJWr/u5zHrA77hADKCXGN6xbSvotp2TBH9wrtIsWKbx
         EwREMYwi05cSNFpeEe67UeskvWvOK2ex1OcTTtyg1FEoN33OHajOe5x4BEy5a4WjR2b6
         ru2WKdQniQO7mzOUUw5zykTY9EuokThOMBxpLOgPlMiXdppt91x4bmlapxnfa9RgKCsC
         xPhp++C81ziNMps+82mhYds8VJgoOXmpuadtVu8tjPRC/WNOdAVNWgU43dG+jl5Pa8XS
         jxrQ==
ARC-Authentication-Results: i=1; mx.google.com;
       spf=softfail (google.com: domain of transitioning [email protected] does not designate 207.XXX.XXX.XXX as permitted sender) [email protected];
       dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
Return-Path: <[email protected]>
Received: from postfix.ad.domain.com (remote.domain.com. [207.XXX.XXX.XXX])
        by mx.google.com with ESMTPS id u71-v6si5370770ita.89.2018.03.22.08.08.41
        for <[email protected]>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 22 Mar 2018 08:08:41 -0700 (PDT)
Received-SPF: softfail (google.com: domain of transitioning [email protected] does not designate 207.XXX.XXX.XXX as permitted sender) client-ip=207.XXX.XXX.XXX;
Authentication-Results: mx.google.com;
       spf=softfail (google.com: domain of transitioning [email protected] does not designate 207.XXX.XXX.XXX as permitted sender) [email protected];
       dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
Received: from lt-jared.jaredbusch.com (unknown [10.254.103.22]) by postfix.ad.domain.com (Postfix) with ESMTP id EB72BC0C7991 for <[email protected]>; Thu, 22 Mar 2018 10:08:39 -0500 (CDT)
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
Date: Thu, 22 Mar 2018 15:08:39 -0000
From: [email protected]
Subject: Updates applied on 'lt-jared.jaredbusch.com'.
To: [email protected]
Message-ID: <[email protected]>

JaredBusch

I should have turned off the actual apply of the updates. then I could have reran it with various email settings.

Obsolesce

@jaredbusch

Yes, this is exactly what I was talking about:
0_1521732498256_846c027a-04dd-41ef-a72a-98ac4ca7732e-image.png

Which can be seen here:
0_1521732532850_c9bd686c-54be-4c92-80e1-7c33d0ebc5da-image.png

I wasn't aware Google/MS allow that kind of thing through, but at least it's warning you.

This is why I use the O365 relay, to make the emails "official or legit".

JaredBusch

@tim_g said in How to receive e-mail alerts from internal devices:

@jaredbusch

Yes, this is exactly what I was talking about:

Which can be seen here:

I wasn't aware Google/MS allow that kind of thing through, but at least it's warning you.

This is why I use the O365 relay, to make the emails "official or legit".

Right, normally, I had my laptop sending from bundystl.com to bundystl.com and it is in the SPF. So always legit. Still not authenticated, but I do have the IP in as a connector in O365.

Obsolesce

@jaredbusch said in How to receive e-mail alerts from internal devices:

but I do have the IP in as a connector in O365

Right, this is what I meant earlier as needing to happen to "allow it".

zachary715

Do you guys go beyond the SPF records and also implement DKIM or DMARC? I've looked into these briefly but not much. DKIM looks fairly straightforward with Office 365.

Obsolesce

@zachary715 said in How to receive e-mail alerts from internal devices:

Do you guys go beyond the SPF records and also implement DKIM or DMARC? I've looked into these briefly but not much. DKIM looks fairly straightforward with Office 365.

Looked into DKIM a little, but not implemented it (yet).

JaredBusch

@zachary715 said in How to receive e-mail alerts from internal devices:

Do you guys go beyond the SPF records and also implement DKIM or DMARC? I've looked into these briefly but not much. DKIM looks fairly straightforward with Office 365.

I've checked them both. I will not implement DKIM anytime soon. It adds little on top of SPF.

DMARC is a layer on top of SPF and/or DKIM you cannot use DMARC without one of the other in place.

All DMARC does is tell the recipient system what to do with a message that fails the SPF/DKIM check. Instead of letting the recipient system decide what to do about it.