This isnt in the TCP/IP protocol, and isnt in the message headers. This is a part of the connection handshake process between a SMTP Server (recipient) and SMTP client (sender).
The HELO is the first thing that your mail client sends when it connects to the receiving server. Its a verbose declaration of "who is calling", so to speak. It states the sending server's identity in a human-understandable way. The receiving mail server doesn't care what the HELO actually is. But modern anti-spam filters do! For instance, if my mail server were to talk to your mail server, after connecting and seing your mail servers SMTP banner - my server would send: HELO mail.espinola.net And you server would respond with an acknowledgment. More info on the connection process: Step 1.) IP Connection: When the sending server first establishes an IP connection with the receiving MTA. Step 2.) SMTP Session Initialization: An SMTP session is initiated when a SMTP client opens a connection to a SMTP server and the server responds with an opening (banner) message. Step 3.) Client Initiation (HELO/EHLO): Once the SMTP server has sent the opening message and the client has received it, the SMTP client sends the HELO/EHLO command to the server, indicating the client's identity. etc... HTH! On Wed, Aug 27, 2008 at 5:09 PM, <[EMAIL PROTECTED]> wrote: > At the risk of sounding like Peter Faulk, now, one more thing... > > Are the HELO messages in the TCP headers and not the email headers? > -------------------------------------- > Richard McClary, Systems Administrator > ASPCA Knowledge Management > 1717 S Philo Rd, Ste 36, Urbana, IL 61802 > 217-337-9761 > http://www.aspca.org > > > "Micheal Espinola Jr" <[EMAIL PROTECTED]> wrote on 08/27/2008 > 03:43:18 PM: > >> Jim Kennedy answered this Q for Exchange. Thats the right thing to do. >> >> I don't blog much (can you say lazy?), but this article I wrote might >> be of interest to you: >> >> http://www.espinola.net/blog/archives/5 >> >> Particular to your situation are my responses to the article comment. >> In a nut shell, you ideally want your HELO to match your outbound >> MTA's public PTR record in DNS. >> >> >> On Wed, Aug 27, 2008 at 4:14 PM, <[EMAIL PROTECTED]> wrote: >> > I fully understand. BUT, any idea how to fix a bad HELO (when it > results >> > in having the internal domain name and the message then picks up the >> > external domain name)? >> > >> > We got a bunch of folks here and in NY in a panic... >> > -------------------------------------- >> > Richard McClary, Systems Administrator >> > ASPCA Knowledge Management >> > 1717 S Philo Rd, Ste 36, Urbana, IL 61802 >> > 217-337-9761 >> > http://www.aspca.org >> > >> > >> > "Micheal Espinola Jr" <[EMAIL PROTECTED]> wrote on 08/27/2008 >> > 03:08:30 PM: >> > >> >> I've been rejecting bad HELO's for a couple of years now. I'm glad > to >> >> see others are finally catching on! Its a HUGE boost in not only >> >> blocking very obvious spam, but also stops the spam extremely early >> >> during the blocking process - taking less time, effort, resources, >> >> etc. >> >> >> >> On Wed, Aug 27, 2008 at 3:00 PM, <[EMAIL PROTECTED]> wrote: >> >> > Greetings, again... >> >> > >> >> > I just got a reply from AT&T. They said the problem probably lies > in >> > the >> >> > HELO statement in the header. (Unfortunately, I am not the Notes >> >> > administrator, but...) >> >> > >> >> > Our Notes server is in a private network (napcc.aspca.int), so that > is >> > the >> >> > domain presented in the HELO statement. Reverse lookups find the > IP >> >> > address, but it does not resolve to "napcc.aspca.int" but rather to >> >> > "mwro.aspca.org". >> >> > >> >> > Do messaging servers such as Notes or Exchange have a setting so > that >> > it >> >> > identifies itself other than with its local network name? I'm sure >> > the >> >> > "internal to external" situation I have is far from unique. >> >> > >> >> > Thanks! >> >> > -------------------------------------- >> >> > Richard McClary, Systems Administrator >> >> > ASPCA Knowledge Management >> >> > 1717 S Philo Rd, Ste 36, Urbana, IL 61802 >> >> > 217-337-9761 >> >> > http://www.aspca.org >> >> > >> >> > >> >> > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >> >> > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> >> > >> >> >> >> >> >> >> >> -- >> >> ME2 >> >> >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >> >> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> > >> > >> > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >> > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> > >> >> >> >> -- >> ME2 >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > -- ME2 ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
