Smart Callhome HELO hostname vs fqdn

[roauvil]

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"

[Lawrence Searcy]

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.