cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2051
Views
0
Helpful
4
Replies

Send e-mails via Ironport directly

Reinis Tropins
Level 1
Level 1

Hello.

I've ran into an issue, where Ironport is able to relay mail to internal Exchange server to any existing e-mail address, with any possible sender one could think of. 

Basically telneting to Ironport external address on port 25, HELO and you're able to send mail to CEO@company.com using CEO2@company.com. 

Is there a way to prevent this kind of behaviour and disallow direct connections to ironport?

 

4 Replies 4

Tom Foucha
Cisco Employee
Cisco Employee

It sounds like you want to prevent spoofing of internal addresses from external sources, there are multiple methods of configuration for accomplishing that including a document I wrote on that very topic that should be posted on this forum. 

 

Any address not listed/configured in the Host Access Table (HAT) under a Relay policy will be treated as incoming mail and subject to policies, filters applied. Addresses listed in the Relay policy will be treated as outgoing and policies applied as such.

There are content filters, messages filters that can be constructed to deny the @company.com to @company.com but I caution to test any filter or policy heavily before implementing to ensure you don't have any adverse affects on mail flow.

 

Attached is the doc I referenced and you can look for a video on this portal as well

Hello.

 

Thanks for the quick reply. You are correct, I'd like to add anti-spoofing measures. Since we don't use any of the mentioned exceptions in your pdf file, I just created the reject filter for my own domain.
However this did not help in any way, I still was able to telnet to Ironport directly, and send a message to my internal test mailbox using a spoofed address from my domain. Ironport still reported : Message 1302159 to testmail@domain.com received remote SMTP response 'Message accepted for delivery'.

 

Am I missing something?

Filters aren't going to stop the SMTP conversation. The message would still be accepted for delivery but then the filter should drop the message. If you want to stop the conversation you would need to implement the paper I posted. Your reject filter isn't applied until the message has been accepted for processing where my method checks during the conversation whether or not the sender is listed as an exception and rejects same domain attempts. 

Hello Reinis,

Can you please send the full message tracking PDF so we can provide some more details as well.

Generally for spoofing filters, we need to ensure the conditions are being met so it drops the emails (after SMTP conversation as Tommy has described).

 

Regards,

Matthew

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: