We're experiencing problems in our Snapmanager environment:
Since our eMail team changed the mailrelay hosts, we are not able to send emails with Snapmanager applications anymore.
We tracked the problem down to the root cause and found that Snapmanger doesn't use the FQDN in the SMTP Helo cmd to connect to the email relay.
According to RFC 821 (SMTP Protocol) the FQDN has to be submitted otherwise the mail relay "normally" does not accept the message (some mail relays do, some don't and ours doesn't accept it).
Did anybody run into the same issue before?
Is there any known solution or workaround for this problem, without installing any additional apps on windows ?
The applications in question are current versions of SnapManager for Exchange, SQLserver and SharePoint.
RFC 821 has been obsoleted by RFC 5321. Checking there I find:
The domain name, as described in this document and in RFC 1035 , is the entire, fully-qualified name (often referred to as an "FQDN"). A domain name that is not in FQDN form is no more than a local alias. Local aliases MUST NOT appear in any SMTP transaction.
Only resolvable, fully-qualified domain names (FQDNs) are permitted when domain names are used in SMTP. In other words, names that can be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed in Section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or address RRs. Local nicknames or unqualified names MUST NOT be used. There are two exceptions to the rule requiring FQDNs:
o The domain name given in the EHLO command MUST be either a primary host name (a domain name that resolves to an address RR) or, if the host has no name, an address literal, as described in Section 4.1.3 and discussed further in the EHLO discussion of Section 4.1.4.
and in section 4.1.4 of the same document:
The SMTP client MUST, if possible, ensure that the domain parameter to the EHLO command is a primary host name as specified for this command in Section 2.3.5. If this is not possible (e.g., when the client's address is dynamically assigned and the client does not have an obvious name), an address literal SHOULD be substituted for the domain name.
Is SnapManager itself creating these malformed messages or is there a configuration issue that would resolve this problem?