From: J Jonelis []
Sent: Monday, December 18, 2006 5:05 PM
To: Jason Jonelis
Subject: Fwd: Update [Incident ID: 1425832] - Update [Incident ID: 1411852] - Unblock request

---------- Forwarded message ----------
From: < >
Date: 18 Dec 2006 15:30:20 -0700
Subject: Update [Incident ID: 1425832] - Update [Incident ID: 1411852] - Unblock request

Our support staff has responded to your request, details of which are described below:

Discussion Notes
Support Staff Response
Dear Sir/Madam,

Thank you for contacting online support. The IP address you have submitted ( ) is not currently eligible for unblocking because the mailserver has returned a 'bogus helo'. This indicates that the server the email originated from either has a virus or has not been setup correctly. Please refer to the following information regarding this issue:


The SMTP HELO command is used by the outgoing mail server to greet the destination servers that they are connecting to. It is usually the first command issued when mail is being sent. It means "Hello, I am ..." Many viruses and bulk emailers send false or nonstandard HELO messages. We are starting to filter these messages and block traffic from email servers that utilize non-standard HELO settings.

Here are the types of error messages related to helo issues that you may experience:

1. bogus helo

This means that the sending email server connected to our mail server and said "HELO [their IP]". RFC 1132 says that the HELO ("hello") message should contain "a valid principal host domain name for the client host". This means a name like "", or "". An IP address is not a valid listing for the name of the server.

In order to resolve this situation, the sending server's administrators will need to configure the server properly, which will cause it to identify itself by name rather than IP address. The administrators of this server may also want to check it for viruses, as many viruses use the HELO command with an IP rather than the name.

2. bogus helo (IP address listed here)

This means that the sending server connected to our mail server and said "HELO (receiving email server's IP)". What this means is that the sending server tried to say Hello, I'm you!" This action is generally caused by a virus.

In order to resolve this situation, the sending server's administrators will need to check it for viruses.

3. bogus helo matches rcpt

This means that the sending system connected to our mail server and said "HELO (receiving email server's domain name)". This is another version of "Hello, I'm you!" but using the server's domain name rather than the server's IP address. This is normally caused by a virus or a bulk emailer.

If this process is not done intentionally, it is generally created by a virus. The server's administrators will need to check the machine for problems.

We hope that this information is useful in diagnosing and resolving the issue that you are experiencing.

Please let us know if we can help you in any other way.


Derek S.
Online Support Team
Customer Inquiry
To Whom It May Concern:

Currently the system is blocking IP from sending mail to
certain sites under your control. I'll assume for a moment here that the
site's owners are using your built-in spam filtering without fully realizing
the implications of said filters. While your tools are showing a "bogus
helo", a failed "rDNS", and bogus "rcpt to" command for our mail server, I
must point out that the error is in fact on your end.

To begin, I must point to a very old, yet very simple, tool commonly found
on all major computers today: the telnet tool. If you are to type in
"telnet 25" you will get this: "220
mail.mnjtech.comMicrosoft ESMTP MAIL Service, Version:
6.0.3790.1830 ready at ". Next type a "helo" command
and you will be greeted with "250 Hello [YOUR IP HERE]".
That's about as simple as I can make it, but it's as clear as day that IP on port 25 (THE standard SMTP port) is in fact responding as

If you were to actually look at the emails being sent from our system
through IP you will see a fully functional reverse DNS
(rDNS) for this IP. The IP corresponds with and can be found using a variety of tools, my favorite
being the "host " command found on every flavor of linux.

Now, with regards to the "rcpt to" being off, I'd like to point out the
standard headers from an email coming from IP show ALL of
the proper information in accordance with normal internet emailing
procedures. Here is a brief summary, edited for our use:

*Return-Path: *

*X-Original-To: USER@DOMAIN*

*Delivered-To: USER@DOMAIN*

*Received: from ( [])*

* by INCOMING EMAIL SERVER (Postfix) with ESMTP id A2B4D139BFE*

* for ; Fri, 15 Dec 2006 13:48:50 -0800 (PST)*

*Content-class: urn:content-classes:message*

*MIME-Version: 1.0*

*Content-Type: multipart/related;*

* type="multipart/alternative";*

* boundary="----_=_NextPart_001_01C72092.CC2CFA91"*

*Subject: SUBJECT*

*X-MimeOLE: Produced By Microsoft Exchange V6.5*

*Date: Fri, 15 Dec 2006 15:48:43 -0600*

*Message-ID: <>

*X-MS-Has-Attach: yes*

*X-MS-TNEF-Correlator: *

*Thread-Topic: SUBJECT*

*Thread-Index: AccgksonPErZVAaDRtGFKM5Ko+AVMQ==*

If you need further assistance with this matter, please reply to this email or contact customer service at 480-624-2500 and reference [Incident ID: 1425832].

Customer Service
2006. All rights reserved.