We were having a problem with godaddy blocking our emails. They claimed we were
returning a bogus helo, but it wasn't really about an invalid helo between our
Exim and their MTA - so I thought I would post it hear because godaddy's
message is completely misleading - this might save someone else some time.
Some of our mail would be sent from a MTA that did not have a MX record (This
MTA would only respond to our public MTA and LAN computers). I suspect they did
a reverse call-back based on IP address instead of MX record. The fix was
routing all mail through our MTA with an MX record. In short godaddy appears to
block all mail coming from IPs that don't have port 25 open.
,.,.
While not based on any RFQ, I can see that trying to authenticate the sending
MTA is the future trend. Sadly, the need to authenticate the sender now
outweighs other issues and I hope new revisions of the RFQ provide a standard
method of MTA to MTA authentication that becomes required after a transition
period.
What I see as a future standard: Instead of using RBL we would have RWL
(Reverse While List) that returns a key for public key authentication. We
would have the choice of using whatever list we want with various definitions
of SPAM. The number of legitimate MTAs is much lower than the number of IPs
that are spamming so it may be quite feasible to cache the majority of honest
MTAs IPs and associated keys. (One could put such a key in a DNS TXT field in a
similar way as RBL are used today). ISPs would want to filter outgoing email
to protect the reputation of their white listed IPs. ISPs could even filter-out
port 25 traffic that came from any IP that wasn't white listed.
,.,.,
Below is the message from godaddy - I include to show how misleading it is
(they never saw a helo - so how could it be bogus) and you might also get a
grin out of the RFC they quoted.
> The IP address you have
> submitted (123.45.67.89) 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".
[RFC 1132 = A Standard for the Transmission of 802.2 Packets over IPX Networks
.. Don't understand why they sited this??]
> This means a name like "smtp.exampledomain.com", or
> "mail.exampledomain.com". 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.
>
> Sincerely,
>
----------------------------------------------------------------
Karl Schmidt EMail Karl@???
Transtronics, Inc. WEB http://xtronics.com
3209 West 9th Street Ph (785) 841-3089
Lawrence, KS 66049 FAX (785) 841-0434
We can't sue and tax each other into prosperity. -kps
----------------------------------------------------------------
