2009-10-05 12:32 PM - edited 2015-12-18 01:38 AM
I've got a customer who writes:
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
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
Is SnapManager itself creating these malformed messages or is there a configuration issue that would resolve this problem?
Solved! SEE THE SOLUTION