Sender Verification and Spoofing

[pr3d4t0r_gr]

Hello,

With the default configuration on Cisco Ironport i 've noticed that a scammer can spoof a legitimate e-mail address to send a malicious e-mail.

For example, if someone is using an open relay or has an account on an ISP he can change the from to "someone@microsoft.com" send it my company and this will pass through without Ironport rejecting it.

Does the Sender Verification solve this ?

If yes on what policy should i enable it ?  

[Philip D'Ath]

You should enable both SPF checks and DKIM checking.

[pr3d4t0r_gr]

This means that for incoming email the other party has DKIM enabled and properly configured SPF.

Many companies don't so this will produce many alerts. Especially for DKIM.

Regarding SPF are there any best practices to handle mis-configured legitimate emails from companies and forged email ?

Thanks. 

[exMSW4319]

Where an organisation is large enough to have its own IT support I generally make an effort to contact them, even for a HARDFAIL if I'm aware of an ongoing trading relationship.

For the raft of smaller senders who don't form an attractive target for forgery I have an Inbound Mail Policy that omits any action I would normally take on SPF failure.

Depending on the profile of your organisation the best action for you may be different, and as a recent adopter of SPF I'm still really at a testing stage.

[pr3d4t0r_gr]

Should i enable SPF only on throttled policy or on all except blocked ?

[exMSW4319]

I run it on all of my mail flow policies except BLOCKED and the higher ones intended to deliberately exempt traffic. You may want to just start with THROTTLED when initially testing, though. The same principle applies when experimenting with Bounce and Envelope Sender verification. 

[Philip D'Ath]

The remote party doesn't have to have either enabled if they don't want to.  If it is not enabled you simply have nothing to check, and they are exposing themselves to increased risk (not you).

These days I simply do a hard fail for SPF.  If the remote party has got it wrong (and I don't run into very many cases these days) then it is their mis-configuration, not yours.  And everyone they send email to will have trouble receiving their email, not just you.

[exMSW4319]

SPF will only work in cases where the sender publishes a correct SPF record. It's optional to publish anything, and a surprising number of people either get it wrong or make a mistake in subsequent maintenance. Someone adds an include for their favourite mainsleaze engine or the near-ubiquitous outlook.com record and the next thing you know you're looking at a new PERMERROR because they've exceeded the maximum number of lookups.

Still, SPF is a factor that you can build into your defences. I can't comment on DKIM.

If scammers are forging one of your own domains, that's a separate question

[Philip D'Ath]

We don't have a single customer without an SPF record these days, it is that common.  We also have every customer set to do strict SPF processing, without issue.  It works really well.

[Tom Foucha]

You are correct we don't block that capability by default. We are discussing changing the default action however there are consequences to that behavior. We have published many different guides on how to prevent Spoofing and are looking at adding additional functionality to the product to make it easier to configure Spoof protection but keep in mind there are many legitimate reasons for spoofing email. More and more companies today do business with 3rd party vendors that send email to employees on behalf of the company, your HR, 401K, outsourced employee services etc. and blocking the ability to receive messages from your own domain (spoofed) would impact those employee services. IF you are confident that you understand you know and have identified those services then consider using the document I authored some years ago on HAT Exception Table method. You can find it attached or watch this video https://www.youtube.com/watch?v=mG86aih6Pko

Now some people including TAC will use Message Filters or Content Filters to help but those have varying success. HAT Rejection is at the time of SMTP conversation so doesn't actually depend on the friendly header FROM in the body of the message so make sure you understand the attach document before implementing as misconfiguration can and has caused rejection of your internal mail server.

I also agree with the suggestions below about implementing SPF and DKIM/DMARC but they will not prevent spoofing as they are not specifically designed to prevent spoofing but to authenticate that the message was created and signed by the sending organization. I've witnessed spoofed messages and spammers lately signing their messages with DKIM so there is no silver bullet for this issue as if you read the RFC it was constructed to allow this type of behavior again for reasons mentioned above.

[pr3d4t0r_gr]

Hi Tommy,

I am not interested for internal domain spoofing as this has been discussed many times.

I m mostly concern for email forgery, where someone can send a phishing email impersonating a legitimate email address e.g microsoft etc. 

Do you have any recommendations to solve this ?

Thanks.

[Tom Foucha]

As suggested by others SPF checks for this type of forgery.

[exMSW4319]

Very true, if the sender doesn't make a shambles of things:

https://dmarcian.com/spf-survey/mssupport.microsoft.com

[Tom Foucha]

<facepalm> Can't fix them all :)