Configure Spoof protection with Exception lists

[Tom Foucha]

This video describes how to configure spoof protection and allow a list of external domains the ability to spoof the internal domain.

[Christopher Smith]

Nice !

If you get time can you please add a basic list/table of contents using time markers simiar to our existing videos? You can look at some of the existing videos to get an idea. Let me know if you have any questions! It is slightly blurry but I can make it out , if this is a major issue for others we can see about fixing it using the conversion process.

[Zachary Reneau]

It should be noted that the example allowspoof.com entered into the sendergroup would not be valid, as the sendergroup is a list of hostnames or IP addresses, not envelope domains. A valid entry would be something like smtp.allowspoof.com where smtp is the hostname of a sending device in the allowspoof.com root domain.

[Tom Foucha]

Valid entries in HAT

The following formats are allowed:

• IPv6 addresses such as 2001:420:80:1::5
• IPv6 subnets such as 2001:db8::/32
• IPv4 addresses such as 10.1.1.0
• IPv4 subnets such as 10.1.1.0/24 or 10.2.3.1
• IPv4 and IPv6 address ranges such as 10.1.1.10-20, 10.1.1-5 or 2001::2-2001::10.
• Hostnames such as example.com.
• Partial hostnames such as .example.com.

but agreed being more specific is best.

[Zachary Reneau]

That's true, but you'll virtually never encounter an MTA that uses the root domain as its hostname. I only point it out because we frequently see user admins entering lots of domains in sendergroups falsely thinking that it will match a given sender and then wondering why the IronPort malfunctioned.

[keithsauer507]

I'm not sure what part of this video broke it, but when following this, immediately all external mail was bounced back from our exchange server.  The following organization rejected your message: mail.ourdomain.com.

I immediately undid everything explained in this video and mail was fixed.  I am not sure how we can block spoofed email if it prevents us from emailing!

[Tom Foucha]

Attached PDF showing how to configure. Make sure that your RelayList is tied to a Relay policy and should be the first in your list and your internal mail servers should be hitting that HAT entry.

esa-anti-spoof_0.pdf

[keithsauer507]

Thank you for that document, that helps.  Although I am tempted to go ahead and try it again, I think I will wait until a slower time of day when any mishaps would go unnoticed.

I'm not sure what steps in that video broke outgoing mailflow, but the only thing that I did not follow was when I created the ALLOWSPOOF in the HAT overview, I did not change the order.  It just went to the bottom of the list, in my case # 7 in the list.  I can see on page 4 of this document ALLOWSPOOF is directly above WHITELIST in the HAT overview.

The only other difference we have is on page 4 your listener is called IncomingMail.  My listener is called AllMail (and the DMZ IP Address:25 of the IronPort).

[keithsauer507]

I think its because we have one public listener that is called AllMail?  Perhaps putting the block from our domain names would have to be done only on a public listener and then we would use another interface on a private listener that we would repoint exchange to?

[Tom Foucha]

My guide and video uses a single listener for all mail. What matters is what HAT policy you hit, when you send email you should be hitting the Relay MFP action tied to a policy. This policy should be first in the list and the Relay policy should not be checking the Sender Verification Exception list. You are not spoofing your own domain you are simply sending. When mail comes inbound it should never hit the Relay MFP hence it should hit one of the other HAT entries that do check the Sender Verification Exception list.

It is not listener specific but HAT/MFP specific.

[ardiii_890]

The solution is simple. In the Mail Flow Policy: RELAYED and Sender Group: RELAYLIST make sure:

1. Your exchange IP-s are there (relayed).

2. Use Sender Verification Exception is set to off, because you don't need to protect spoofing from your company's internal Exchange servers.

3. All  the other Mail flow policies should have Use Sender Verification Exception set to on.

[Tom Foucha]

Correct,

3. except for the SenderGroup you want to allow to spoof your domain. Thanks for assisting.