Showing results for 
Search instead for 
Did you mean: 

Ask the Expert- SD-WAN

Ask the Expert: Best Practices for Configuring the Email Security Appliance


Read the bioWith Woody Hardison

Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn from Cisco expert Woody Hardison  about Cisco e-mail security appliance, configuration of the HAT, anti-spam, anti-virus and how to install and configure certificates.Woody Hardison is an Escalation Engineer at the Technical Assistance Center at Cisco's RTP campus in North Carolina. He has over 4 years experience configuring and troubleshooting the Cisco IronPort Email Security Appliance.  Woody is a Cisco IronPort Certified Security Professional.

Remember to use the rating system to let Woody  know if you have received an adequate response. 

Woody might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the Ironport sub-community discussion forum shortly after the event. This event lasts through March 9, 2012. Visit this forum often to view responses to your questions and the questions of other community members.

Hello everyone,

Feel free to fire away with questions you may have regarding the Cisco Email Security Appliance. I'm here to answer them to the best of my ability.


I just noticed that 7.6 is available as upgrade on my C370 Appliances... Is that safe to do go there or that is still in "early deployment" phase? I am currently running 7.5.1


The 7.6 build is currently in what can be considered a 'First Customer Ship' phase. It has not yet

been released for install by all appliances, but is considered a stable release. These builds

are released to specific customers who have aligned with Cisco to deploy the software before

General Availability. The build is considered stable, but these early adopters offer a chance

for any last minute issues to be addressed, should any be found.

If, while running the 'upgrade' command, you see 7.6 as an option, upgrade

at your leisure. For those who do not see this build available, take note that this is the final

step before General Availibilty, which means 7.6 will be available in the near future.

7.6 is an exciting release, as it will be the first official ESA build with IPV6 support. Cisco's website contains the 7.6 release notes outlining what is new and what defects have been addressed:

Are SMTP TLS-Encryption and Cisco Ironport Email-Encryption are different ways to encrypt Mails ?

For Ironport Email-Encryption i need a Feature Keys for TLS-Encryption not is this correct ?

How can i check in the Version 6.5.3 how long my certificate for TLS Encryption is valid ?


My Ironport is getting hammered with Directory Harvesting attacks.  Is there anything I can do or just let the Ironport deal with it?


     I've included my responses inline for easier reading:

1) Are SMTP TLS-Encryption and Cisco Ironport Email-Encryption are different ways to encrypt Mails ?

1A) Yes, they are different. SMTP TLS (Transport Layer Security )encryption is point-to-point encryption between to smtp servers when transmitting messages. This is to protect from others 'eavesdropping' on the connection and intercepting the communication in plain text. The communicating servers identify themselves using digital certificates. The client may contact the server that issued the certificate (the  trusted CA) and confirm the validity of the certificate before  proceeding.

Cisco IronPort Email Encryption is a system which encrypts the message itself, using ARC4 or AES encryption. (ARC4 is the most common choice, it provides encryption with minimal decryption delays for message recipients.)

The encrypted message can then be transmitted through a standard SMTP connection, or via TLS connection.

The basic workflow for opening encrypted messages is:

Step 1
When you configure an encryption profile, you specify the parameters for message  encryption. For an encrypted message, the Email Security appliance  creates and stores a message key on a local key server or on the hosted  key service (Cisco Registered Envelope Service).

Step 3

When a recipient opens an encrypted message in a browser, a password may be required to authenticate the recipient’s identity. The key server returns the encryption key associated with the message.

When opening an encrypted email message for the first time, the recipient is  required to register with the key service to open the secure envelope.  After registering, the recipient may be able to open encrypted messages  without authenticating, depending on settings configured in the  encryption profile. The encryption profile may specify that a password  isn’t required, but certain features will be unavailable.

2) For Ironport Email-Encryption i need a Feature Keys for TLS-Encryption not is this correct ?

2A) Correct. A feature key is required for Cisco IronPort Email encryption. TLS is a standard mail transmission

protocol and as such, is available for configuration within the appliance's settings.

3) How can i check in the Version 6.5.3 how long my certificate for TLS Encryption is valid ?

3A)  In version 6.5.3, the appliance uses one certificate for TLS and SSL ( browser security ), so the easiest way

to check its expiration date is to connect to the Cisco IronPort's web interface, and use your browser to view the

certificate the site uses. For instance, in my version of Firefox, I can click on the domain name beside the url bar, choose 'More Information -> View Certificate' and the certificate details are shown. This includes the expiration date of the certificate. Directions for retrieving a certificate's information through other browsers should be readily available on the Internet.

You can also pull the certificate information from an openssl connection to your appliance and extract the expiration date. The following commands are generally available on a Linux/Unix box:

  1. Retrieve the certificate

    $ echo "" | openssl s_client -connect ironports_hostname:25 -starttls smtp > dump_certificate
  2. Retrieve then the expiration date of the certificate

    $ openssl x509 -in dump_certificate -noout -enddate

    It should give you an output similar to:

    notAfter=May  20 22:00:00 2019 GMT

( Substitute ironports_hostname for the hostname of your Cisco IronPort Email Security Appliance in the example.)

Hope that helps.


Hi Greg,

Directory Harvest Attacks, sometimes called 'dictionary attacks' are defined by the technique spammers use to try to determine valid email addresses on a mail domain.

Many spammers send emails to a high number  of invalid addresses, so blocking senders who send to invalid  recipients can also decrease spam.

Given that Directory Harvest Attack Prevention (DHAP) on the Cisco IronPort aborts the connection at the SMTP conversation phase, it is quite effective at preventing the attacker from reaching many valid usernames on your domain.

As a general rule, DHAP attacks are short-lived burts of attempts to reach valid users. Given the nature of these attacks, and their (usual) brevity, I would recommend allowing the Cisco IronPort to handle the rejections for you. DHAP was designed to exclusively handle these types of attacks.



Woody, I see the 7.6 release is available for my C670 appliances (production environment) but is not for my C650 appilances (test/pilot environment).  By policy I need to install in test/pilot before production.  I am really interested in this release and would liek to have some idea when it might be available at the C650 level.

Hi David,

   We'd be happy to help get your test boxes provisioned for the 7.6 release, if you'd like to test it out.

Since we'll need your appliance serial numbers, it would be best for you to open a standard support request to keep your information confidential.

Feel free to open a support request explaining that you'd like your test boxes be allowed to upgrade to 7.6.

Include the serial numbers of the appliances in the request. Once the engineer processes your request, your

appliances will automatically see the upgrade available via the 'upgrade' command in the CLI, or the upgrade

page in the web interface.

Since you mentioned these are test boxes, I will mention the requirement listed on Page 4 of the 7.6 release notes:

"Starting in AsyncOS 7.6, an Email Security appliance requires an anti-spam system feature key in order to use the SenderBase Reputation Service."

So, you'd want to keep that in mind that if your test boxes don't have current antispam keys, the SBRS system will not be available.

All that being said, as I mentioned in a previous post, the limited release is the last step before General Availability. We do not post time-frames for the GA release, in the event that any last minute issues need addressing. But, the release should be available in the very near future. Sorry for being so vague. 




Thank you for your quick response, I will submit a support case to get the C650's added to the FCS to 7.6 release.  Test is kind of a misnomer for these appliances they are fully functional with all the required feature keys as they support our fully functional pilot environment and mirror our production implemetation.



Is it better to block an email address with a policy or a filter  ? Which one takes less processing power ?

Hi Bob,

     Good question. I'm assuming you'd like to block inbound messages from a particular sender.

Message filters will use the least amount of resources to block an email. This is basically due to the fact that message filters affect the message very early in the process of evaluation. Policies and content filters occur later in the process, triggering more actions before they are reached, and therefore will use more resources.

That being said, if you find yourself wanting to block several senders and find you are adding more and more individual message filters, you'd be counter-acting their advantage. Also, this can become unwieldly, as it's harder to manage than a list of "bad senders" which can be managed centrally.

That's a situation where you would want to consider using a dictionary to store the list of sender addresses, where you can add and subtract them as needed in one central file.

Cisco's Knowledge Base contains an existing article describing how to  do just that, and I encourage you to read it to see if it meets your  needs:

For examples and syntax of message filters, you can access the Cisco IronPort's online help from the appliance's web interface through the link: 'Help and Support -> Online Help'

Use the Search box in the online help to search for 'message filters', then scroll down to the section 'Advanced Configuration Guide'. There are several sections dedicated to message filters.

Hope that helps,


We have been running the Ironport C370 for over 1 year now and would like to say they are the best product that I have used.  Very easy to maintain and very good at what they do.

With that being said, I want to see what I can do to increase the amount of Spam that I'm currently blocking.  On average, we are blocking about 91% of the Spam at our Gateways.  I would like to see about trying to increase this by at least 1 to 2%.  Currently we are setup as follows:

Blacklist - -10 to -2

Suspectlist - -2 to 0

Unknowlist - 0 to 7.5

Whitelist - 7.5 to 10

Any Positively-Identified Spam is dropped.  Any Suspected Spam is sent to Quarantine.  Our Spam Thresholds are:

Positively Identified Spam Score > 74

Suspected Spam Score > 36

What can I adjust to try to block the most Spam possible? 



Hi Woody, very interesting discussion!

I've got a question regarding the cipher use for TLS. We have currently configured our SSL for

AES256-SHA:AES128-SHA:RC4-SHA:RC4-MD5 ciphers. However it seems that there are a lot more available for Ironports. What do you recommend in  term of choice for the ciphers, and what are the consequences of this choice especially in term of performances (obviously I don't want to enter the whole list of available ciphers if there is a risk of increase the latency). Please note also that we can't add :ALL at the end of the cipher list for security policies reasons.



Hi Doug,

     Thanks for the kind words. We do what we can    I'm glad to see you're getting a good, high stoppage

percentage from the appliance. Drop percentages in the 90%+ range are typical in my experience.

The config items you've provided seem fairly reasonable. Myself, being paranoid, I would probably extend the Unkownlist to +10 SBRS mark, and leave the Whitelist with an empty SBRS range, as it comes by default.

Because everyone's mail flow is different ( my company will receive different targeted spam than yours, for instance ), obtaining the maximum potential can be as much an art as a science.

Since we often are asked what extra steps can be taken to get the maximum potential out of your IronPort,

we've published an external Knowledge Base article that lists *several* things you can do to stop as much spam as possible:

I cannot stress enough to use Step 11: Report mis-classified messages to IronPort.  Anytime you catch an email making it through our systems, we want to know. You cannot submit too many samples. (The same holds true for misclassifed HAM messages.)

I'd go through the checklist on the url above and put into place as many as you feel you can. These recommendations should help you get those extra percentage points you're looking for.

Hope that helps,



Thanks for the info.  I will review it and see what we can change.

Just a quick question on the submission of mis-classifed messages.  Is every message that is submitted review by someone or just when a "bunch" of the same message is received?  We use T-Bird and the MailSentry IronPort Spam Reporter add-on, which works very well.  We tell our users to report Spam that they are receiving using this add-on, but some are under the impression that "my reporting this one message won't matter".


Hi Philippe,


Your current TLS configuration actually looks good, using the ciphers you have listed is fine.  The IronPort does include quite a list of ciphers you can use, I counted 34

That being said, we do have some recommendations that we've published that will allow you to keep your cipher strengths in the medium/high strength category, and avoid using :ALL.

The following Knowledge Base article describes a short string you can use in 'sslconfig'

One thing we have to be concerned with when using TLS is that we include a cipher strength that the remote smtp server is going to be able to negotiate. As you know, picking just one cipher and ignoring all others would leave you in a position where plenty of TLS connections would fail due to non-negotiation.

Going with the highest ciphers is more cpu intensive on the IronPort, but going with the lowest ciphers might not allow you to connect to some institutions that do not allow less than 128bit, for instance.

The string shown in the KB article shows how we can: include medium and high cipher strengths, disable SSLv2 (which is becoming more commonplace due to some bugs found in SSL over the past years, but is certainly optional) and disallow anonymous ciphers.

     Inbound SMTP method: sslv3tlsv1

      Inbound SMTP ciphers: MEDIUM:HIGH:-SSLv2:-aNULL:@STRENGTH

      Outbound SMTP method: sslv3tlsv1

      Outbound SMTP ciphers: MEDIUM:HIGH:-SSLv2:-aNULL:@STRENGTH

To me, this represents a happy medium, where we can feel safe that we're using strong ciphers to protect our information, but not excluding too many ciphers that might cause us to run into negotiation issues with remote servers.

Hope that helps,



Absolutely, no problem.

I can't give away too much of our "secret sauce" , but rest assured every message is taken into account. As you can imagine, all this is more automated than human, but there are always engineers sampling and verifying submissions to enhance our antispam rulesets.

We appreciate all submissions we receive, and the fact that you are encouraging users to submit. Submissions make the system better, and that's what we're all striving for.

Let your users know that IronPort apppreciates the time it takes to submit false positives/negatives and that every one counts.



Thanks Woody for the answer on TLS.

Another question: do you have best practices to share on the update of rules/filters created on the appliances? We have started a while ago to deploy Ironports, and have several hundreds of these rules, with probably a vast amount being not applicable anymore (such as rules for people who have left the company, anti-spoofing or whitelisting on server who don't exist anymore, ...).

How do you propose to deal with this, as it takes probably a lot of horsepower?

Hi Philippe,

It's true that the more rules you deploy, the more processing time and power needed to evaluate them all.

What I would recommend in a situation such as yours would be the usage of dictionaries to combine similar filter expressions, along with a single content or message filter to evaluate it.

This is explained in a Knowledge Base article here:

Basically, if we took ex-employeees as an example, we could do the following.

1) Create a dictionary containing the email address of ex-employee ( one per line )

2) Create a single content filter to evaluate if the recipient of the message is contained in that dictionary, and process it accordingly ( bounce, drop, respond with a template stating the address is no longer valid)

Dictionaries make it exceptionally easy to aggregate multiple filters into one filter which is basically scanning a text file for information on what to search for.

Now, along the lines of singular filters, which wouldn't benefit from using a dictionary, I can only recommend standard maintenance. The IronPort's gui is quite effective as removing/disabling Content Filters which are no longer needed. Unfortunately ( or not, depends on how you look at it ) , Message Filter administration is still a CLI-only process.

That being said, you would generally always have more Content Filters than Message Filters. Given their nature, Message Filters are more suited for broad actions; eg: drop any message coming from my external listener with my domain name as the sender.  Content Filters are more fine-grained, allowing for splintering of recipients, which allow singular recipients to be acted upon in a multi-recipient message.

Hope that helps,


Another question: what are the best practices to manage configuration files within clusters? I've read the KB articles regarding this, and it is quite limited! However we frequently have to do massive changes to our clusters, and modifying programmatically the XML is sometimes easier than to do big changes manually.

Thanks in advance for any tip!


Unfortunately the KBs are limited as there is currently no support for loading/reloading configuration files from/to clustered appliances. As you've problably seen, the configurations get quite complex as each new machine is added to the cluster.

That doesn't mean it cannot always be done, as you've found.  If I were to attempt large changes on a cluster, I would probably take the route you already use, and do it programmatically.



Hi Woody,

I have the following two questions:

What is an intermediate SSL certificate, and why would I need one?

How can I verify that an SSL certificate has been signed with the correct key?

Let me know the answers when you can.



Hi John,

Good questions!


An intermediate certificate is a "subordinate" certificate issued by the trusted root Certificate Authority (CA) specifically to issue end-entity server certificates. The Certificate Authority can be thought of as a central repository that can be checked against to verify identity.

When you purchase an SSL cert, what you are really paying for is a certificate chain that begins at the trusted root CA, through the intermediate and ending with the SSL certificate issued to you. Such certificates are called chained root certificates.

Intermediate certs are important because creating certificates directly from the CA root certificate increases the risk of root certificate compromise. If the CA root certificate is compromised, the entire trust infrastructure built by the SSL provider will fail. The usage of intermediate certificates for issuing SSL certificates to end entities provides an added level of security.

Keep in mind that using intermediate certificates does not cause installation, performance, or compatibility issues.


To verify that your cert is signed with the correct key is fairly straightforward. All you need is an openssl binary for your workstation's operating system. Generally, this is included in Linux/Unix, but is available for download for Windows at

Once you have SSL installed on your workstation, you can run the following two commands to check the certificate against the key. Basically, we are looking for the ouput to be *exactly* the same. If it is, you can

be confident that you have the correct cert/key pair.

If it is not, then you should consider redownloading the certificate from your issuer, and ensuring you are using the correct key ( check the file's timestamp, etc.... )

Run the following command for the cert:

openssl x509 -noout -modulus -in server.crt | openssl md5

Run the following command for the private key:

openssl rsa -noout -modulus -in myserver.key

*The modulus results for the cert and key should be the same.*


OpenSSL> rsa -noout -modulus -in xyz.key








OpenSSL> x509 -noout -modulus -in xyz.crt |md5








Hope that helps


Thank you for the response. In regards to TLS:

How can I verify that the recipient's server is accepting my TLS connections?

Can you explain the difference between TLS Preferred and TLS Verify?


- John

Hi John,

Excellent questions! Let's take them one by one.


To determine if the recipient's server is accepting my TLS connections:

Our first step is to determine a host we want to verify TLS against.

This may be as simple as searching your message tracking for connections to

a particular domain, or you may have to use a tool such as `dig` or `nslookup`

to determine the mx record for the domain you wish to check.

I'll use as an example.> dig mx

; <<>> DiG 9.4.3-P2 <<>> MX

;; global options:  printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18084

;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0


;                     IN      MX

;; ANSWER SECTION:              86400   IN      MX      10              86400   IN      MX      15              86400   IN      MX      15              86400   IN      MX      15


In my scenario, I'd like to verify that I can negotiate a TLS connection to

In the current versions of AsyncOS, there is a built-in command called

`tlsverify` which will automate this for us.

Once we have the domain and mail exchanger for that domain, we can plug

them into `tlsverify` and the IronPort will do all the work for us

---> tlsverify

Enter the TLS domain to verify against:


Enter the destination host to connect to.  Append the port ( if you are not connecting on port 25:


Connecting to on port 25.

Connected to from interface

Checking TLS connection.

TLS connection established: protocol TLSv1, cipher RC4-SHA.

Verifying peer certificate.

Verifying certificate common name

TLS certificate match

TLS certificate verified.

TLS connection to succeeded.

TLS successfully connected to

TLS verification completed.


Success! We can now be confident that if we do set TLS to preferred or required,

that our connections to this mail host will be successful. As a precautionary measure,

we shoiuld check all 4 MX records to ensure we receive the same successful results.


If we should happen to check a domain that does not negotiate TLS with our IronPort,

`tlsverify` will show us the error so we know why our connection failed.


Would you like to verify another domain? [Y]>

Enter the TLS domain to verify against:


Enter the destination host to connect to.  Append the port ( if you are not connecting on port 25:


Connecting to on port 25.

Connected to from interface

Checking TLS connection.

STARTTLS command not supported at

TLS was required but could not be successfully negotiated.

Failed to connect to

TLS verification completed.


From the output above, we see that the STARTTLS command is not supported on the

remote host. This tells us they are not advertising TLS, and it is not possible

to negotiate a TLS connection with that host.


When configuring your listeners, you can choose from three states for TLS:

1.  Off  - No TLS connections are attempted

2.  Preferred: TLS can negotiate from the remote MTA to the Cisco IronPort appliance. However, if the remote MTA does not negotiate (prior to receiving a 220 response), the SMTP transaction will continue "in the clear" (not encrypted). No attempt is made to verify if the certificate originates from a trusted certificate authority. If an error occurs after the 220 response is received the SMTP transaction does not fall back to clear text.

3. Required: TLS must be negotiated from the remote MTA to the Cisco IronPort appliance. No attempt is made to verify the domain's certificate. If the negotiation fails, no email is sent through the connection. If the negotiation succeeds, the mail is delivered via an encrypted session.

Hope that helps,


This document was generated from the following discussion: Ask the Expert: Best Practices for Configuring the Email Security Appliance


Hi all i'm getting below meaassage please help inorder to fix the issue:

The following message to <> was undeliverable.

The reason for the problem:

5.3.0 - Other mail system problem 554-'5.4.6 Hop count exceeded - possible mail loop'

The IP address of the MTA to which the message could not be sent:

---------- A copy of the message begins below this line ----------

---------- A copy of the message begins below this line ----------

X-IronPort-AV: E=Sophos;i="4.84,665,1355094000";


Received: from (HELO ([])

by with ESMTP/TLS/AES128-SHA; 14 Feb 2013 17:45:11 +0100

Received: from ( by ( with Microsoft SMTP Server (TLS)

id; Thu, 14 Feb 2013 17:44:38 +0100

X-IronPort-AV: E=Sophos;i="4.84,665,1355094000";


Received: from (HELO

([]) by with ESMTP/TLS/AES128-SHA; 14 Feb

2013 17:44:38 +0100

Received: from ( by ( with Microsoft SMTP Server (TLS)

id; Thu, 14 Feb 2013 17:29:35 +0100


Dear Ganesh,

For mail loop issue, please double check your 'SMTP routes' settings on IronPort ESA whether it contains the destination mail hosts for all domains (including subdomains). If not, ESA will resolve the MX host (if not existing, use A record) of the domain part of the recipient address.



Hi Woody,

Hope you would assist me in my problem.

We have enabled Internal relay for our servers, now,we have done security and vulnerabilty tests, we found that we can telnet on port 25 to the Ironport and send emails internally on behalf of it.


Did any one faced this issue before, or it could be a bug in the IOS 7.1.5-017



Hi Anas,

You should only put IP addresses of 'trusted' internal mail servers in RELAYLIST or private listener. This can minimize the chance of botnet/malware infected end user machines to send spams/virus messages through your mail gateways/IronPort ESA and you get blacklisted.

If you need to allow end users' machines to send through IronPort ESA, you should enable SMTP authentication. You can choose to create another sender group and corresponding mail flow policy for those end user IP ranges.

I suggest you to enable outgoing antispam and antivirus scanning.

Besides, in AsyncOS 7.6, there is a new feature called rate limit by envelope sender, you can limit the number of emails sent by external/internal sender.

I wish it helps.



Thanks tommy for reply, Actually the problem is not from inside, it is from outside "from the Internet", if any one will telnet to our box he can simply send emails to our users on behalf of the box because of the internal relay.

They have requested to disable the relay but it is a business requirements



Dear Anas,

By default, ESA will not allow external host/sender to 'relay' emails, and it will check the recipient address based on Recipient Access Table. You can turn on LDAP Accept on listener (or SMTP Call-Ahead Recipient Validation) to validate if the recipient address is found on your AD/LDAP or mail server (in your example, check if info@ exists).

You can enable Directory Harvest Attack Prevention DHAP (maximum invalid recipient per hour setting under mail flow policy).

You can also configure SMTP Address Parsing oprion n(e.g. allow partial domain like foo, foo@, foo@bar, etc.) under listener settings.



Hi tommy,

Do you know about SPF, would it fix the issue

Cisco Employee

Hi Anas,

From what i understand, external users are allowed to send messages to your users by telnetting to your mail server. I would make all incoming mail arrive at the ESA and  make all other mail servers not accessible externally. Please review the ESA configuration guide:

Also, Please review your Relaylist and ensure only internal IPs are allowed to relay. (see below).

How do I relay outbound traffic?

Knowledge Base Answer ID: 1233



Hi Stephan,

External users are telnetting to te ironport itself not to the mail server, mail servers are not accessible from the internet.

The issue is from the ironport side only


Dear Anas,

I would like to understand in more details of your current issue. Are you referring to spoofing emails from Internet with envelope sender address or header From address using your company address (

If so, you can easily add an incoming mail policy with "" and click sender radio button, you can add a content filter with your choices of actions (e.g. prepend subject with [POSSIBLE SPOOFING], add X-IronPort-Quarantine header to redirect to spam quarantine, notify administrator, etc.)

By the way, you can also open a TAC case so that our support team can assist you.



Hello Dear,


we have an inhouse Mdaemon mail server which is used to route emails of 5 of our domains.

we have configured cisco CES to secure our emails. All incoming emails from outside first hit ESA which scans and deliver to Mdaemon which is routing emails to its destination internally.


we have another domain which dont have an inhouse mail server. its hosted on cloud and emails are processing through cloud (like gmail etc).

is it possible we can pass incoming and outgoing emails for that domain through ESA?


we can add that domain in RAT, we can add HAT entry and configure SMTP route?

please help.






Can anyone tell me the best practices or cisco recommendation to deploy email security apppliance, as in one our customer facing the problem of lots of spam emails.


if there is such documents related to this please provide,



Hariom Sharma