SnapManager not following RFC 821/5321?

jont — Thu, 05 Jun 2025 07:23:20 GMT

I've got a customer who writes:

---start

Hey Toasters,

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 ?

---end

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 [2],
   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?

Thanks,

--Jon

Re: SnapManager not following RFC 821/5321?

watan — Fri, 11 Dec 2009 00:28:01 GMT

I was able to confirm this with the engineering team and we do not provide the FQDN. This would require a RFE for future release.

Re: SnapManager not following RFC 821/5321?

jont — Fri, 11 Dec 2009 09:40:13 GMT

Thanks. I'll open an RFE to get SnapManager compliant with the standards.

topic Re: SnapManager not following RFC 821/5321? in Data Protection

SnapManager not following RFC 821/5321?

Re: SnapManager not following RFC 821/5321?

Re: SnapManager not following RFC 821/5321?