cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Welcome to the Smart Call Home Community!

Our online forum for Smart Call Home customers to share, learn, and collaborate on Smart Call Home related topics. We encourage you to ask questions of Cisco experts, start a discussion, or share ideas and insight.

Smart Call Home enabled devices perform proactive diagnostics on their own components to provide real-time alerts and remediation advice when an issue is detected. An embedded support feature available on a broad range of Cisco products, it is provided at no additional cost with an active Smart Net Total Care Service, SP Base, Unified Computing Support Service, or Mission Critical Support Service contract for the designated products.

This Community will provide you with an overview about Cisco Smart Call Home features and how these features are embedded in a wide range of Cisco products to help your network. Smart Call Home provides higher network availability and support service quality.

3844
Views
0
Helpful
1
Replies
Highlighted
Beginner

Smart Callhome HELO hostname vs fqdn

Is there some way within callhome, globally, or in the VRF context to  enable/disable how the Smart Callhome client devices choose to initate  the "HELO"

I have two different clients. Both are having callhome setup issues around "whitelisting" the Callhome equipment on the SMTP server.

We have setup the whitelist corretly and I can initate a telnet client from the respective devices (nexus 5k and C3560's) with success.

During this testing I have discovered that the C3560's send HELO messages as the FQND and the Nexus 5k's and UCS FI's send the HELO messages as hostname.

Typical SMTP dialog

#1 client connects to mail server

#2 mail server sends back a 220-

#3 client sends hello message with it's domain name or FQDN.

   I have discovered that the IOS based systems differ from the NXOS systems

            C3560 systems sends "HELO hostname.domain.name"

            Nexus systems sends "HELO hostname"

#4 dialog continues with MAIL FROM:me@hostname.... (what ever you put in transport email from field)

#5 dialog continues on with RCPT TO:you@yourdomain.com (whae ever you put in the destination-profile email-addr"

Issue is this one client Whitelist is instistant on using FQDN during hello. the other is insittant on using Hostname only. What I end up with is the lack of completing relay on 50% of the equipment in each scenario.

A nice feature might be inside of the callhome transport section to have a command like this

   "transport email helo-string fqdn|hostname" or "transport email helo-string WORD"

1 REPLY 1
Cisco Employee

Smart Callhome HELO hostname vs fqdn

This looks to be an implementation difference between NX-OS and IOS.  Let me see if I can hit all of the questions:

1. There is no "transport email helo fqdn" command

     Why?

RFC 5321, Sections 2.3.5, 4.1.1.1, 4.1.3 require clients to use the Fully Qualified Domain Name (FQDN)  as the HELO string during the SMTP conversation because a "good" sender will HELO as "HELO mail.cisco.com", a typical bot will HELO as "HELO local-host".

RFC 2821 states that a sender *MUST* start an SMTP transaction with a HELO/EHLO command. It also states that the domain *MUST* be either a FQDN or a bracketed IP address, and explicitly forbids the use of any other format.

2. What's the next step? Open a TAC case and point it out as an issue in NX-OS and UCS. I can write the bug and mark it internally found but customer found issues attached to TAC SRs have higher priority and can be seen by other customers in the bug toolkit.

3. is there any workaround? Yes, you can use the FQDN for the hostname in NX-OS but since there is no independent prompt command to change the CLI prompt in NX-OS, the prompt will have the FQDN in it.

CreatePlease to create content
Content for Community-Ad
July's Community Spotlight Awards
This widget could not be displayed.