Scott Townsend
asked on
Blocking SPAM that comes from yourself? SFP is setup, but getting through.
System/Setup:
The From: Header has my email address in it, so it looks like it came from me, though the sender used the Following Headers, which I think caused the SoftFail on the SPF and managed to get the email through.
I've just started to look into DKIM/DMARC though still learning what it is all about. I'm not sure if this would prevent the email from reaching us. Would it? Is there something else I can do?
Here is a copy of one of the emails with Most all of the Headers. My IPs/Names/Emails have been edited. I've removed all of the X-Microsoft-Exchange-Diagn ostics: Headers.
Exchange 2010 Hybrid with Office 365 Tenant.
Multiple Domains. Some Go Directly to Office 365 Tenant, some go to the On-Premise First, then either Stay on the On-Prem, or get Transferred to the Office 365 Tenant.
I'm trying to Block some SPAM that the user is forging our Email Addresses. I Have SPF Records setup and have tested them and they seem to be functioning fine. Though we are still getting emails from us to us though they are not coming from us. Multiple Domains. Some Go Directly to Office 365 Tenant, some go to the On-Premise First, then either Stay on the On-Prem, or get Transferred to the Office 365 Tenant.
The From: Header has my email address in it, so it looks like it came from me, though the sender used the Following Headers, which I think caused the SoftFail on the SPF and managed to get the email through.
X-Sender: jarch@chol.com
X-Complaints-To: <abuse@mailer.chol.com>
Errors-To: noreply@chol.com
Return-Path: jarch@chol.com
X-Complaints-To: <abuse@mailer.chol.com>
Errors-To: noreply@chol.com
Return-Path: jarch@chol.com
I've just started to look into DKIM/DMARC though still learning what it is all about. I'm not sure if this would prevent the email from reaching us. Would it? Is there something else I can do?
Here is a copy of one of the emails with Most all of the Headers. My IPs/Names/Emails have been edited. I've removed all of the X-Microsoft-Exchange-Diagn
Received: from BYAPR15MB2310.namprd15.prod.outlook. com (2603:10b6:a02:bc::33)
by BYAPR15MB2312.namprd15.prod.outlook. com with HTTPS via
BYAPR07CA0020.NAMPRD07.PROD.OUTLOOK. COM; Tue, 5 Feb 2019 20:33:15 +0000
Received: from CY4PR15CA0015.namprd15.prod.outlook. com (2603:10b6:910:14::25)
by BYAPR15MB2310.namprd15.prod.outlook. com (2603:10b6:a02:8b::15) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GC M_SHA384) id 15.20.1580.22; Tue, 5 Feb
2019 20:33:14 +0000
Received: from BN3NAM04FT057.eop-NAM04.prod.protect ion.outloo k.com
(2a01:111:f400:7e4e::205) by CY4PR15CA0015.outlook.office365.com
(2603:10b6:910:14::25) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GC M_SHA384) id 15.20.1580.22 via Frontend
Transport; Tue, 5 Feb 2019 20:33:13 +0000
Authentication-Results: spf=softfail (sender IP is <MailServerIP>)
smtp.mailfrom=chol.com; <tenantDomain>.mail.onmicrosoft.com; dkim=none (message
not signed) header.d=none;<tenantDomain>.mail.on microsoft. com; dmarc=none
action=none header.from=<MyDomain>;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning
chol.com discourages use of <MailServerIPExternal> as permitted sender)
Received: from <MailServer> (<MailServerIPExternal>) by
BN3NAM04FT057.mail.protection.outloo k.com (10.152.93.80) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CB C_SHA384) id
15.20.1580.10 via Frontend Transport; Tue, 5 Feb 2019 20:33:13 +0000
Received: from mailsnd3.chol.com (203.252.1.124) by
<MailServer> (<MailServerIPInternal>) with Microsoft SMTP Server id
14.3.382.0; Tue, 5 Feb 2019 12:33:11 -0800
Received: (qmail 22976 invoked from network); Wed, 6 Feb 2019 05:33:03 +0900
(KST)
Received: from [203.252.1.171] (203.252.1.171) by mailsnd3.chol.com with
ESMTP; Wed, 6 Feb 2019 05:33:03 +0900 (KST)
Received: from [92.241.66.138] ([92.241.66.138]) by
watcher1.chol.com ([203.252.1.171]) with ESMTP id
1549398779.780360.2907691920.watcher 1 for
<MyEamil@myDomain.com>; Wed, 06 Feb 2019 05:32:50 +0900 (KST)
X-Sender: jarch@chol.com
X-Complaints-To: <abuse@mailer.chol.com>
Errors-To: noreply@chol.com
To: <MyEamil@myDomain.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907
Thunderbird/15.0.1
Message-ID: <xfdqmzdt-ygq4-2a0h-8ho7-m8fwl45l5ue f>
From: <MyEamil@myDomain.com>
X-Priority: 5 (Lowest)
Date: Tue, 5 Feb 2019 21:33:02 +0100
List-Unsubscribe: <mailto:unsubscribe@chol.com?subject =unsubscri be:gaz4jas yo908c7q9e 1n9ad3mwy0 ooqhs87t3m tptcj5nath abgv>
List-Subscribe: <https://chol.com/lists/?p=subscribe>
Abuse-Reports-To: <abuse@mailer.chol.com>
Subject: <My Name>
X-TERRACE-DUMMYSUBJECT: Terrace Spam system *
X-TERRACE-SPAMMARK: NO (SR:8.63)
(by Terrace)
MIME-Version: 1.0
Return-Path: jarch@chol.com
X-TM-AS-Product-Ver: SMEX-12.0.0.1220-8.200.1013-23806.00 1
X-TM-AS-Result: No--7.095400-0.000000-31
X-TM-AS-MatchedID: 144052-186105-701236-702020-708325-7 02445-7106 87-700476- 7
00618-704156-705754-704301-701035-10 6240-70035 4-705802-7 01618-7014 46-701390
-186107-705140-701461-703385-139504- 705753-704 597-188019 -700023-70 3835-1059
20-700752-300989-703712-700445-30965 8-708496-7 11432-7001 07-701588- 702112-70
4930-700706-700345-712024-148004-148 042-148046 -148133-14 8152-10010 -23109-42
000-42003-63
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
X-OrganizationHeadersPreserved: <MyMailServer>
X-MS-Exchange-Organization-Expiratio nStartTime : 05 Feb 2019 20:33:13.3923
(UTC)
X-MS-Exchange-Organization-Expiratio nStartTime Reason: OriginalSubmit
X-MS-Exchange-Organization-Expiratio nInterval: 2:00:00:00.0000000
X-MS-Exchange-Organization-Expiratio nIntervalR eason: OriginalSubmit
X-MS-Exchange-Organization-Network-M essage-Id:
684faf54-c8c4-4f00-284a-08d68ba926aa
X-EOPAttributedMessage: 0
X-MS-Exchange-Organization-MessageDi rectionali ty: Originating
X-MS-Exchange-Organization-SCL: 5
X-CrossPremisesHeadersPromoted:
BN3NAM04FT057.eop-NAM04.prod.protect ion.outloo k.com
X-CrossPremisesHeadersFiltered:
BN3NAM04FT057.eop-NAM04.prod.protect ion.outloo k.com
X-Forefront-Antispam-Report:
CIP:204.145.245.173;IPV:CAL;CTRY:US; EFV:NLI;SF V:SPM;SFS: (298030000 2)(199004) (189003)(5 820100001) (348070000 5)(8676002 )(65826007 )(55666002 )(8936002) (1096003)( 47776003)( 81686011)( 33896004)( 76786011)( 305945005) (65956001) (7596002)( 7636002)(2 46002)(901 46011)(658 06001)(551 76004)(236 76004)(581 26008)(287 6002)(6916 009)(62001 00001)(670 6004)(9036 002)(63326 003)(45954 011)(66574 012)(96860 03)(336012 )(50466002 )(486006)( 306002)(26 826003)(10 6466001)(9 56004)(861 52003)(476 003)(14600 2)(156004) (42882007) (95636005) (26005)(61 793004)(23 51001)(575 854001)(19 627235002) (356004)(1 05596002)( 126002)(66 66004)(641 26003)(436 003)(14444 005)(76806 002)(17322 4004)(1143 23001)(988 24002)(878 26002)(170 46004);DIR :INB;SFP:; SCL:5;SRVR :BYAPR15MB 2310;H:<My MailServer >;FPR:;SPF :SoftFail; LANG:en;PT R:<MyMailS erver>;A:1 ;MX:1;CAT: SPM;
X-Microsoft-Exchange-Diagnostics:
1;BN3NAM04FT057;1:9B1/C0nMcye5dT/GGZ AlrLGeXz0f SgXfmBmmjA KqlcH31BZH DEUg9sYsbb EODe0YZN9A mo0IId6RkA 1qzHmEkoWJ ZqKal4el/k y4YVc4CuJe J/ZhHqek6w NaQofO3GAy yPXu8bTsre SmooLOYzCw xg==
X-MS-Exchange-Organization-AuthSourc e: <MyMailServer>
X-MS-Exchange-Organization-AuthAs: Anonymous
X-OriginatorOrg: <MailServerDomain>
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation -Id: 684faf54-c8c4-4f00-284a-08 d68ba926aa
X-Microsoft-Antispam:
BCL:0;PCL:0;RULEID:(2390118)(7020095 )(4652040) (8989299)( 4534185)(4 627221)(20 1703031133 081)(85590 20)(899020 0)(5600110 )(711020)( 4605077)(2 0170526033 28)(715306 0);SRVR:BY APR15MB231 0;
X-MS-TrafficTypeDiagnostic: BYAPR15MB2310:
X-MS-Exchange-CrossTenant-OriginalAr rivalTime: 05 Feb 2019 20:33:13.0580 (UTC)
X-MS-Exchange-CrossTenant-Network-Me ssage-Id: 684faf54-c8c4-4f00-284a-08 d68ba926aa
X-MS-Exchange-CrossTenant-Id: 29b9a438-bcbd-487a-8b52-8e 53a14d70a5
X-MS-Exchange-CrossTenant-OriginalAt tributedTe nantConnec tingIp: TenantId=29b9a438-bcbd-487 a-8b52-8e5 3a14d70a5; Ip=[<MyMai lServerIP> ];Helo=[<M yMailServe r>]
X-MS-Exchange-CrossTenant-FromEntity Header: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantH eadersStam ped: BYAPR15MB2310
X-MS-Exchange-Transport-EndToEndLate ncy: 00:00:02.5237506
X-MS-Exchange-Processed-By-BccFolder ing: 15.20.1580.012
X-Microsoft-Antispam-Mailbox-Deliver y:
ucf:0;jmr:0;ex:1;auth:0;dest:J;OFR:E xclusiveSe ttings;ENG :(20160513 016)(75011 9)(5200110 16)(520003 179)(70817 2)(9445063 03)(944626 516);RF:Ju nkEmail;
X-Microsoft-Antispam-Message-Info:
=?us-ascii?Q?1u6LAlNlYYhNt46L3ArOc+x Zq0uxVoZaC m6eoIOkHl2 jWhSl+EK6+ f2VenSb?=
=?us-ascii?Q?f7VHdm+R6c6tiTsyPFeu/j5 VtnpuO21Ov oQ6ze5Y7rD QeoGS2v97A 6WHmCZA?=
=?us-ascii?Q?tY4viTNDn4JenOIaUUlfEd3 FAxdkcbwyi RnO0qnMLLJ a0oerf0Zs4 NRV6ady?=
=?us-ascii?Q?08eySZqZYaFaSt5oVCEi7nb /xrwNXJKIz FbGhba46K+ zDACHXEPs6 6cbkKIv?=
=?us-ascii?Q?JyRZGJnBNrXMJOdMmH0eElJ qUjbiQMcnL qZ/oLdfpnl l7muJmvIcT 7kGc3aC?=
=?us-ascii?Q?8AZLRuG5SSgJucAfWIr+3DR ttsvrYeJ2c 4JDC51/h6a LQxMqGM9dr M7yzdtj?=
=?us-ascii?Q?tHZYX3tNobIdCsB4IDM2V1c w6KbftqJDF xrra2JMH8J rjLj3ZvZZ5 cJeVDbo?=
=?us-ascii?Q?pc3FoTBXW71XqeeEaoYPEU0 Bmk8s3eyjD 7t0l0rC9vY LXDQ371+bs 9n8CoLo?=
=?us-ascii?Q?WH47CX6qwX0e8QghU7ZQK/G Wd8lPUPk/J oZW+iG1rlc hP0EVr5mHC fAQACkj?=
=?us-ascii?Q?f0P0jdt/Wlpzm0Q+wcarY8h tLnD5BwXVF SE5tADRouu /mWKESqe1x 4feoukQ?=
=?us-ascii?Q?xIoVpvpADDTXi8FhcAiUoPR 3ZztBNSr8P 1hMahMbIP+ GJO7oYkmW0 MpFF13y?=
=?us-ascii?Q?uIUyKzjXvFKUPcmlEpOyaG0 HDrZth+Xyz fBhHGIaOJ5 j3JeevvY8G 4MaOvFR?=
=?us-ascii?Q?cE4BECECTYjFD5Nctu2pIq2 u0QfNBk/Jc mrQgh1Q9Mj v5hZSlEdd4 SqxNk/C?=
=?us-ascii?Q?qsZoVyIKnMf4Tf4/KZQg8wR iN2+B4ahQY tASLTmslvC RlYUi+1eln dUF8RkO?=
=?us-ascii?Q?7gsr/cYQCPwqthCaFvkBH2R FCYFgtcU9e KJQMw4pA8E 9S9N8JD2SP p2xQhSr?=
=?us-ascii?Q?AsG5yB70MUNU3XkT7XVHWT7 Tx5SzSjKcR AmkkW94gCM DYRDTmuKHd BeWExhs?=
=?us-ascii?Q?vFN298UwnfEDJN3GVXwb1sA pr+dkBWWGj loNzmUQPoI esfJNMi4MZ s1iJfAb?=
=?us-ascii?Q?0Nyb6JQ71yM+z5umeA2pGiU jO8pPabPW4 op5oSV9NUm RRi8QJrpj5 l4Nv89F?=
=?us-ascii?Q?S6c2ZqKVrKia+WbfwZ7jB3l ehIDdIl2kN s8ChfpSBU4 lDd7B/fIzp Dlv37d2?=
=?us-ascii?Q?P2bIfL+4c/FCYaxplrBSji6 BCGHaKNgDk NfpBpEQQKc QCBzaJLgmc nHZXe+R?=
=?us-ascii?Q?t733d20MLrcAo8wusFfaCFT tiwjrV+378 lquhkyP/VM ELTggrj/8m 5EIPjOa?=
=?us-ascii?Q?eKGOI83ADETFgElXl55F?=
Content-type: text/plain;
charset="UTF-8"
Content-transfer-encoding:quoted-printable
Hi, your account was recently hacked! It will be good idea to change your p=
swd immediately!
You might not heard about me and you obviously are definitely wanting to kn=
ow why you're reading this electronic message, proper?
I'mhacker who burstyour email boxand devices and gadgetsseveral months ago.
You should not try to msg me or find me, in fact it's not possible, since I=
directed you an email from YOUR hacked account.
I started malware soft to the adult videos (porn) site and guess you watche=
d this website to have a good time (you realize what I mean).
During you have been keeping an eye on vids, your browser started out to ac=
t like a RDP (Remote Control) having a keylogger that granted me permission =
to access your display and camera.
Consequently, my softobtainedall information.
You have entered passwords on the web services you visited, I intercepted a=
ll of them.
Surely, you can modify them, or have already changed them.
But it really doesn't matter, my spyware renews it regularly.
What did I do?
I compiled a backup of your system. Of all the files and personal contacts.
I have managed to create dual-screen videofile. The first section demonstra=
tes the clip that you were observing (you've the perfect taste, huh...), and=
the second part reveals the video from your camera.
What must you do?
Clearly, in my view, 500 USD will be a fair amount of money for our little =
riddle. You'll make your deposit by bitcoins (if you don't recognize this, g=
o searching =E2=80=9Chow to purchase bitcoin=E2=80=9D in Google).
My bitcoin wallet address:
13v2bbgDUDqojx2CxcsaCwMgM3WLRWgK3s
(It is cAsE sensitive, so copy and paste it).
Attention:
You have only 2 days to perform the payment. (I have an exclusive pixel to =
this letter, and at the moment I understand that you've read this email).
To monitorthe reading of a letterand the activityin it, I utilizea Facebook=
pixel. Thanks to them. (The stuff thatis usedfor the authorities may helpus=
.)
In case I fail to get bitcoins, I shall immediately offer your videofile to=
each of your contacts, along with family members, co-workers, ?etcetera?.
Since this is essentially email TO you (on premise)
From: <MyEamil@myDomain.com>
To: jarch@chol.com
It's already "legit" email that shouldn't trigger SPF at all. Please note it was never (From: jarch@chol.com, To: jarch@chol.com, which WOULD trip SPF)
After that, it's being forwarded to Office365, which shouldn't trip SPF once again (otherwise the Office365 subs would be there for nothing, always empty mailbox).
Therefore, it's not an SPF issue, it's a spam issue (on premise should've filtered it, so it wouldn't be forwarded to Office365)
From: <MyEamil@myDomain.com>
To: jarch@chol.com
It's already "legit" email that shouldn't trigger SPF at all. Please note it was never (From: jarch@chol.com, To: jarch@chol.com, which WOULD trip SPF)
After that, it's being forwarded to Office365, which shouldn't trip SPF once again (otherwise the Office365 subs would be there for nothing, always empty mailbox).
Therefore, it's not an SPF issue, it's a spam issue (on premise should've filtered it, so it wouldn't be forwarded to Office365)
Ideally you should have antispam gateway on exchange or at least should enable antispam transport agent on exchange server
Further you should enable sender ID on exchange server and have combination of Spf + DMARC OR SPF + DKIM + DMARC which will enforce sender domain to authenticate either SPF or DKIM originating from his own domain
Though he can spoof your org email addresses (he can do that from internet) but either SPF OR DKIM validation will fail and you could easily reject / declare that message as spam
Further you should enable sender ID on exchange server and have combination of Spf + DMARC OR SPF + DKIM + DMARC which will enforce sender domain to authenticate either SPF or DKIM originating from his own domain
Though he can spoof your org email addresses (he can do that from internet) but either SPF OR DKIM validation will fail and you could easily reject / declare that message as spam
when spammer try to send email from your smtp domain, exchange will check received message for either SPF or DKIM resolution with your own smtp domain because of DMARC policy, since spammer email origin IP (SPF) or DKIM signature will not match, it will identify it as spoofed email and according to DMARC policy exchange will act on it.
@my previous post, I think I misunderstood who is who. So, SPF indeed didn't trigger because it was indeed from jarch@chol.com, sending from the correct IP stated in the SPF record.
The FROM header came later, during the email data conversation (passed the SPF checking point already, can't reject it based on SPF anymore).
How would you've caught this one though? Easy, also enable other DNS blacklists, since this IP has been blacklisted already:
LISTED DNS Realtime Blackhole List 203.252.1.171 was listed 300 31 Ignore
LISTED ivmSIP 203.252.1.171 was listed 2100 0 Ignore
LISTED PSBL 203.252.1.171 was listed 2100 0 Ignore
LISTED SERVICESNET 203.252.1.171 was listed 2100 47 Ignore
LISTED UCEPROTECTL1 203.252.1.171 was listed 2100 0 Ignore
ALso, it was one of those standard phishing mails that's been going around for months already, any simple spam filter would've caught it.
M$ probably let it through intentionally, wanted you to cough up some extra dough for the extra protection subscription they're offering.
The FROM header came later, during the email data conversation (passed the SPF checking point already, can't reject it based on SPF anymore).
How would you've caught this one though? Easy, also enable other DNS blacklists, since this IP has been blacklisted already:
LISTED DNS Realtime Blackhole List 203.252.1.171 was listed 300 31 Ignore
LISTED ivmSIP 203.252.1.171 was listed 2100 0 Ignore
LISTED PSBL 203.252.1.171 was listed 2100 0 Ignore
LISTED SERVICESNET 203.252.1.171 was listed 2100 47 Ignore
LISTED UCEPROTECTL1 203.252.1.171 was listed 2100 0 Ignore
ALso, it was one of those standard phishing mails that's been going around for months already, any simple spam filter would've caught it.
M$ probably let it through intentionally, wanted you to cough up some extra dough for the extra protection subscription they're offering.
92.241.66.138 is the originating IP.. Which is in Georgia, RU.. you could block that range of IP's
"Softfail", means that the SPF record probably ends with ~all
A "softfail" is not the same as a "fail". It means that SPF is still being configured and tested, so results should not be taken too seriously.
Change the end bit to -all , and this spam will likely be blocked.
A "softfail" is not the same as a "fail". It means that SPF is still being configured and tested, so results should not be taken too seriously.
Change the end bit to -all , and this spam will likely be blocked.
Checking your SPF record confirms that it does indeed end with a softfail qualifier. Needs to be changed.
"v=spf1 ip4:203.252.1.0/24 ip4:203.252.3.0/24 ip4:164.124.191.0/24 ip4:210.120.128.25 ~all"
Be aware however, that if you don't have all IPs that your domain may send mail from listed in the SPF record, making this change will probably result in some of your outgoing email being spam binned.
"v=spf1 ip4:203.252.1.0/24 ip4:203.252.3.0/24 ip4:164.124.191.0/24 ip4:210.120.128.25 ~all"
Be aware however, that if you don't have all IPs that your domain may send mail from listed in the SPF record, making this change will probably result in some of your outgoing email being spam binned.
ASKER
@Alan - We cant do that as we do have other legitimate mail providers sending mail as us to us. I’m sure I could then come up with rules to allow only them to bypass.
@kimputer I do have some RTBL setup, I’ll have to look to see why its not picking it up.
@David Johnson The origin IP address changes, so keeping on top of the different subjects they are using is tough.
@Mal Osborne - My SPF Récord is:
v=spf1 mx a:webex.com include:spf.protection.out look.com ip4:10.0.0.0/8 include:e2ma.net ip6:fe80::c530:2fc8:c944:b be include:_spf.mailspamprote ction.com -all
So I do have the -all at the end.
@Mahesh - I’m still looking into DKIM and DMARC, it looks like its the way to go.
Thank you all for your replies
@kimputer I do have some RTBL setup, I’ll have to look to see why its not picking it up.
@David Johnson The origin IP address changes, so keeping on top of the different subjects they are using is tough.
@Mal Osborne - My SPF Récord is:
v=spf1 mx a:webex.com include:spf.protection.out
So I do have the -all at the end.
@Mahesh - I’m still looking into DKIM and DMARC, it looks like its the way to go.
Thank you all for your replies
OK, so your domain is NOT chol.com?
SPF specifies that interpreting a record to a set of IP addresses cannot involve more than 10 DNS queries, including the includes. Your record is too complex, and will almost certainly hit that limit, breaking SPF.
MX Will be at least 2 DNS lookups, but probably 3 or more: an MX, and an A for each mail server.
a:webex.com Will be another DNS lookup.
Includes x3 Will generate another 3 lookups.
So, that means at least 6 DNS queries, even before resolving whatever is in the includes.
That should result in a PERMERROR.
This site can help check for excess DNS lookups:
https://www.kitterman.com/spf/validate.html
SPF specifies that interpreting a record to a set of IP addresses cannot involve more than 10 DNS queries, including the includes. Your record is too complex, and will almost certainly hit that limit, breaking SPF.
MX Will be at least 2 DNS lookups, but probably 3 or more: an MX, and an A for each mail server.
a:webex.com Will be another DNS lookup.
Includes x3 Will generate another 3 lookups.
So, that means at least 6 DNS queries, even before resolving whatever is in the includes.
That should result in a PERMERROR.
This site can help check for excess DNS lookups:
https://www.kitterman.com/spf/validate.html
Hi Scott,
I don't understand what you mean by:
Are you saying that you have a large number of external parties sending you email using your domain name?
Bear in mind, this is NOT your users who are outside the LAN (using their SmartPhone etc) - this is external parties sending email 'pretending' to be you?
If so, then you have a very unusual situation.
If not, then there should be no issue - you are only blocking incoming emails that are purporting to be FROM your domain.
This solution is simple, free, pretty much bullet-proof, and you can do it in ten minutes.
Alan.
I don't understand what you mean by:
We cant do that as we do have other legitimate mail providers sending mail as us to us. I’m sure I could then come up with rules to allow only them to bypass.
Are you saying that you have a large number of external parties sending you email using your domain name?
Bear in mind, this is NOT your users who are outside the LAN (using their SmartPhone etc) - this is external parties sending email 'pretending' to be you?
If so, then you have a very unusual situation.
If not, then there should be no issue - you are only blocking incoming emails that are purporting to be FROM your domain.
This solution is simple, free, pretty much bullet-proof, and you can do it in ten minutes.
Alan.
ASKER
@mal Osborne - No, chol.com Is not My Domain, that is from the Spammer. I know my SPF récord resolves to 11 and not 10. I dont know how to consolidate as I need the ones from Microsoft, WebEx and our Email Marketing Provider,
@Alan - We have email marketing campaign providers that send out our marketing emails. The from address they use is one from our domain. Our employees as well as customers receive the marketing emails. So I could I guess create a rule that blocks our domains unless it is coming from the marketing company. Though the SPF usually does this with the from address only, since there is the X-Sender the SPF didn’t kick it out.
@Alan - We have email marketing campaign providers that send out our marketing emails. The from address they use is one from our domain. Our employees as well as customers receive the marketing emails. So I could I guess create a rule that blocks our domains unless it is coming from the marketing company. Though the SPF usually does this with the from address only, since there is the X-Sender the SPF didn’t kick it out.
@scott, as I said before, it's not about the FROM and X-Sender, SPF has always been acting "correctly" to check X-Sender (the first part of the SMTP conversation), the FROM is from the second part of the SMTP conversation, PASSED the SPF stage.
You incorrectly assume it's because of this, that the email got through.
This one got through (despite what I told you DNS blacklist and normal decent spam filter would've caught it), is because it's one of those rare spam messages from a higher level hack.
The lowest spam types that are easily caught are from mindless bots, running on compromised PC's connected to home PC's, running on ISP's customer dynamic IP range.
This is a "higher" type of spam, because it originated from a more "established" host, where all the things were in place (static public IP nrs, DNS records etc). And these higher types of spam, obviously pass SPF (because it was a chol.com user, sending from a chol.com server). So you should help other people on the internet by stopping this users from abusing chol.com valid services (that probably serves thousands of legitimate law abiding users), by finishing the abuse trajectory (sending headers to abuse dept. it's clearly stated in the headers, abuse@mailer.chol.com).
Probably a really tiny fish out of the water, but a fish nonetheless (the jarch@chol.com user will probably be banned or warned that his PC is compromised)
You incorrectly assume it's because of this, that the email got through.
This one got through (despite what I told you DNS blacklist and normal decent spam filter would've caught it), is because it's one of those rare spam messages from a higher level hack.
The lowest spam types that are easily caught are from mindless bots, running on compromised PC's connected to home PC's, running on ISP's customer dynamic IP range.
This is a "higher" type of spam, because it originated from a more "established" host, where all the things were in place (static public IP nrs, DNS records etc). And these higher types of spam, obviously pass SPF (because it was a chol.com user, sending from a chol.com server). So you should help other people on the internet by stopping this users from abusing chol.com valid services (that probably serves thousands of legitimate law abiding users), by finishing the abuse trajectory (sending headers to abuse dept. it's clearly stated in the headers, abuse@mailer.chol.com).
Probably a really tiny fish out of the water, but a fish nonetheless (the jarch@chol.com user will probably be banned or warned that his PC is compromised)
Hi Scott,
Yes - Most companies only have a few such providers, so trivial to create exceptions for them.
Your call, but I add such a rule at all my clients by default, and never had any issues in all the years (probably since Transport Rules came out - hard to recall, but maybe Exchange 2010, so about ten years or so).
Even if the client also has other anti-spam setup, this just sits there as an additional backstop for one of the most dangerous types of spam emails - those that look like they are from someone within your organisation.
Given the negligible time it takes to setup, there's really no reason not to try it, and if you want to be conservative, you could initially have all such emails go into a separate mailbox to be reviewed hourly, daily, weekly, monthly - whatever suits your business requirements.
Alan.
We have email marketing campaign providers that send out our marketing emails. The from address they use is one from our domain. Our employees as well as customers receive the marketing emails. So I could I guess create a rule that blocks our domains unless it is coming from the marketing company
Yes - Most companies only have a few such providers, so trivial to create exceptions for them.
Your call, but I add such a rule at all my clients by default, and never had any issues in all the years (probably since Transport Rules came out - hard to recall, but maybe Exchange 2010, so about ten years or so).
Even if the client also has other anti-spam setup, this just sits there as an additional backstop for one of the most dangerous types of spam emails - those that look like they are from someone within your organisation.
Given the negligible time it takes to setup, there's really no reason not to try it, and if you want to be conservative, you could initially have all such emails go into a separate mailbox to be reviewed hourly, daily, weekly, monthly - whatever suits your business requirements.
Alan.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
@Kimputer I have the Following RBL setup
Interestingly enough it made it past PSBL. So It must of been whitelisted before that. I'll Keep looking there.
@Alan, I'll Look into creating the Rule.
@Mahesh I have DKIM on one domain and will work on DMARC next. See how it goes and then add it to the Primary Domain.
I still need to learn more about this. Is there any issues with losing mail if something is not setup right or would it just not run the test or?
I also have the Issue where some domains are Pointed to protection.outlook.com and some are pointed to the on-Premise server, so I have a Mix. We have about 30 Different domains. I'll be testing with the ones that are not as critical.
Thanks All.
Spamhaus ZEN
HostKarma (JMF)
Weighted Private Block List
Passive Spam Block Lost
Mailspike Combined List
SpamCop Blocking List
Barracuda Reputation Blocking List
HostKarma (JMF)
Weighted Private Block List
Passive Spam Block Lost
Mailspike Combined List
SpamCop Blocking List
Barracuda Reputation Blocking List
Interestingly enough it made it past PSBL. So It must of been whitelisted before that. I'll Keep looking there.
@Alan, I'll Look into creating the Rule.
@Mahesh I have DKIM on one domain and will work on DMARC next. See how it goes and then add it to the Primary Domain.
I still need to learn more about this. Is there any issues with losing mail if something is not setup right or would it just not run the test or?
I also have the Issue where some domains are Pointed to protection.outlook.com and some are pointed to the on-Premise server, so I have a Mix. We have about 30 Different domains. I'll be testing with the ones that are not as critical.
Thanks All.
ASKER
@Alan - When I went to create the Rule I didn't see a way to do it to allow good mail vs not good. Since we are a Hybrid and most of the users are in the Cloud, I cant see a way to create a Rule to Allow from a Specific Sending Host(s) vs people's email. So if I block all @MyDomain.com except if from marketing@mydomain.com I would then block the clouduser@mydomain.com too.
THanks!
THanks!
Hi Scott,
When your clouduser@mydomain.com sends an email to another user (an internal email), does it come in via smtp somehow?
If not, then it should not get blocked, as you are only applying this rule to incoming, external emails. The rule would be constructed something like this:
To test, you could block yourself only (or one user that you can talk to who is setup that way), and see if you / they get blocked when you send an email to each other. To do that, this line would be something like:
when the from address matches scott@yourdomain.com
If they are coming in via smtp, then this approach might be too hard to implement :-(
Thanks,
Alan.
When your clouduser@mydomain.com sends an email to another user (an internal email), does it come in via smtp somehow?
If not, then it should not get blocked, as you are only applying this rule to incoming, external emails. The rule would be constructed something like this:
- from users that are outside the organisation
- when the from address matches yourdomain.com
- redirect the message to testmailbox
- except when (whatever criteria you want to use)
To test, you could block yourself only (or one user that you can talk to who is setup that way), and see if you / they get blocked when you send an email to each other. To do that, this line would be something like:
when the from address matches scott@yourdomain.com
If they are coming in via smtp, then this approach might be too hard to implement :-(
Thanks,
Alan.
ASKER
the way that a Hybrid On-Premis/O365 system is setup, they use SMTP to transfer from on to off and off to on premise via SMTP. So when I went to look at my SMTP Log to fund senders from my domain, it is listing the Cloud users sending to On-Premise.
Darn - Probably not a good option then.
Sorry!
Alan.
Sorry!
Alan.
ASKER
I have SPF and DKIM implemented. Still Looking into doing DMARC Correctly.
Thank You!
Thank You!
I normally add a Transport Rule that blocks any incoming external email purporting to be from an internal domain.
If required, I add exceptions (such as an external newsletter provider for example).
Should be pretty much rock-solid.
Alan.