According to RFC 2821, paragraph 4.1.1.1, when sending an EHLO or HELO command, "The argument field contains the fully-qualified domain name of the SMTP client if one is available." Typically, the FQDN is the domain name of the sender or service provider. For example, sending localhost.localdomain in the EHLO/HELO command is a typical invalid hostname.
To fix this problem (UNIX):
1. Most MTAs allow you to configure this value somewhere in the configuration files. Check the configuration files and look for SSI-WEB-1. Possibly changing to SSI-WEB-1.schedulesource.com in the right place will fix this problem.
2. Many UNIX-based MTAs will simply lookup the hostname from the hosts file (/etc/hosts) and use the first hostname listed for this box. Changing the order of the entries on the lines could resolve this problem.
To fix this problem (EXCHANGE):
The following link is to a KB article that describes the steps to implement a proper FQDN.
http://support.microsoft.com
And with this link follows another link that explains a caveat that all servers internally need to understand the FQDN.
http://support.microsoft.com
[4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) These commands are used to identify the SMTP client to the SMTP server. The argument field contains the fully-qualified domain name of the SMTP client if one is available. In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help to identify the client system. The SMTP server identifies itself to the SMTP client in the connection greeting reply and in the response to this command.]
RFC 1035 defines the allowed characters in domain names. To summarize, each part of a domain (or label) must start with a alpha character, end with an alpha or numeric character, and include only alpha, numeric or "-" (hyphen) characters. This is explained in section 2.3.1 of RFC 1035.
RFC 2821 also includes the following paragraph in section 4.1.2:
"To promote interoperability and consistent with long-standing guidance about conservative use of the DNS in naming and applications (e.g., see section 2.3.1 of the base DNS document, RFC1035 [22]), characters outside the set of alphas, digits, and hyphen MUST NOT appear in domain name labels for SMTP clients or servers. In particular, the underscore character is not permitted. SMTP servers that receive a command in which invalid character codes have been employed, and for which there are no other reasons for rejection, MUST reject that command with a 501 response."
Due to the relatively high occurrence of underscores in hostnames for Microsoft Windows based systems, we have chosen to allow underscores in the first part of a domain name. We do not, however, allow underscores in other parts as this is rarely seen for valid hostnames and can be used as an indicator of spam software generating random hostnames.