Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 892
  • Last Modified:

HELO Command RFC 821

Hello,
   I use a custom winsock based dll for sending emails out of our application. As per RFC 821 Section 3.5
HELO Command: RFC-821 Section 3.5

   The sender-SMTP MUST ensure that the  parameter in a HELO command is a valid principal host domain name for the  client host.  As a result, the receiver-SMTP will not have to perform MX resolution on this name in order to validate the HELO parameter.

   The HELO receiver MAY verify that the HELO parameter really corresponds to the IP address of the sender.  However, the receiver MUST NOT refuse to accept a message, even if the sender's HELO command fails verification.

   DISCUSSION: Verifying the HELO parameter requires a domain name lookup and may therefore take considerable time.  An alternative tool for tracking bogus mail sources is suggested below (see "DATA Command").

      Note also that the HELO argument is still required to have valid  syntax, since it will appear in a Received: line; otherwise, a 501 error is to be sent


Question:
However sometimes on few email servers I get
Failed: 501 missing fully qualified domain name

I always pass( atleast try to ) "domain.com" as the parameter where domain.com is extracted from the reply to address.
So am I interpreting this wrong, what are the possible reasons for this error.
0
danths
Asked:
danths
  • 2
1 Solution
 
PsiCopCommented:
You're relying on another data source, the "reply-to" address, which may not contain valid data.

RFC 821 is old, and since it was written, many E-Mail systems have taken to resolving the claimed origination point via DNS, and rejecting those that do not resolve properly. Yes, this technically breaks the RFC, but the RFC predates spamming and DOS attacks on mailservers. I daresay that if RFC 821 were written today, it would be considered perfectly acceptable for a receiver to refuse to accept a message that fails verification during the initial HELO conversation.

You're very unclear on how your program gets its information. "Reply to" is very much an optional parameter, and not all mail systems/clients add it, and not all ones that do put the right information in it. Any reason you don't use "From:" ?
0
 
danthsAuthor Commented:
My app needs the reply-to address and I do validate it for proper email format and so if the reply-to address was someone@somewhere.com, I parse out somewhere.com to be used with HELO. In fact my app defaults the reply-to to "From" however users could change it. I have no ambiguity on the function and the parsing. I was wondering if some email servers need the HELO parameter to be
<localhostname>.<localdomainname>.<com/net/org...> in that format rather than "somedomain.com". Secondly per my interpretation no Host should reject accepting connection ( reverse lookup)  solely based on parameter passed in HELO. Is that wrong?
0
 
PsiCopCommented:
But HOW does you app get the initial information? That is, from EXACTLY WHERE does the information come from which the "Reply To" is extracted?

No, your interpretation is not wrong, but it ignores the realities of the modern day E-Mail environment. Like I said, RFC 821 is old. Its replacement, RFC 2821, is still in draft, and a quick check notes that it retains the language you cite.

Your app validates for proper format. Does it validate the Domain?

IF the Domain's DNS records were properly set up, the somewhere.com portion should be fine. Trouble is there are a lot of people out there setting up Domains who don't have a clue about DNS, and so there's a lot of improper DNS information.
0

Featured Post

[Webinar] Database Backup and Recovery

Does your company store data on premises, off site, in the cloud, or a combination of these? If you answered “yes”, you need a data backup recovery plan that fits each and every platform. Watch now as as Percona teaches us how to build agile data backup recovery plan.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now