HELO should be a FQDN error

floyd

Verified User
Joined
Mar 29, 2005
Messages
6,251
When trying to sending from my phone I get this error:

2010-04-22 19:15:05 H=49.sub-75-196-14.myvzw.com (Inbox) [75.196.14.49] F=<[email protected]> rejected RCPT <[email protected]>: HELO should be a FQDN or address literal (See RFC 2821 4.1.1.1)
 
We've gotten a lot more tighter on what we allow in the latest beta. You'll get this message if your phone isn't sending a fully qualified domain name or an ip address with it's helo (or ehlo).

I believe we've posted that by default with the new SpamBlocker RC file you must send mail using authenticated plain-text login on port 587.

You can search the file for RFC 2821 and delete the entire acl stanza.

I just noticed that though in these lines we allow an IP literal, we don't, further above in the file. So in the release version I'll change the comment.

Jeff
 
I believe we've posted that by default with the new SpamBlocker RC file you must send mail using authenticated plain-text login on port 587.

My phone does not allow me to specify the port. Even when I send authentication its still over port 25.

I ended up commenting out the 1st check

Code:
  # 1st deny checks if it's a hostname or IPV4 address with dots or IPV6 address
#    deny message = HELO should be a FQDN or address literal (See RFC 2821 4.1.1.1)
#         !authenticated = *
#         condition   = ${if match{$sender_helo_name}{\N^\[\N}{no}{yes}}
#         condition   = ${if match{$sender_helo_name}{\N\.\N}{no}{yes}}

I simply have to be able to send email from my phone. People have different priorities. I wish I knew what HELO the phone was sending.
 
I wish I knew what HELO the phone was sending.

I added "log_message = $sender_helo_name Not FQDN" and then checked the log. The Helo is simply Inbox. Why I don't know.

The fact is I cannot implement Spamblocker3 as it is because I do not know who else may have the same trouble as myself with their phones. I am using it on my mailserver but I cannot use it on any other production servers.
 
The solution would be to not apply the HELO rule to any authenticated user, no matter what port they're using.
 
@interfasys:

Figure out how I can do that :).

Do any/all phones use plaintext authentication? Or must we use them with POP before SMTP?

I always thought my code would work with POP before SMTP authentication; it's only been recently that I got complaints and realized it wasn't working that way.

Since the published code on authentication appears to work only with port 587, I'm at a standstill here, as I'm not willing to allow unathenticated relaying (and I don't think you'd want me to).

I can't check myself for at least one reason; all phones aren't the same, and my phone is a Google phone; I simply use gmail for outgoing email.

I agree that the system should work with cellphones to the greatest extent possible without allowing unauthenticated relay over port 25. I just don't know how to do it.

Do I go back to old code, and not check HELO at all? It blocks an awful lot of spam for me.

Jeff
 
Do I go back to old code, and not check HELO at all? It blocks an awful lot of spam for me.

It seems to block a lot of spam for me too.

If there is anything you would like me to test please let me know. I have a Treo 700wx which is Windows Mobile 5 and my wife has a Sam sung Saga Windows Mobile 6 (don't know exact model). Both on Verizon so I don't know if the two models will do anything different. I will try her phone tomorrow and see what it does.

On mine I tried with pop before SMTP and then with authentication. I will do some further testing tomorrow.
 
Last edited:
My wife's Sam sung Saga does the same thing running Windows Mobile 6. The HELO sent is simply Inbox.

If anybody else has phones they want to use to help us test let me know. I would like to know the phone brand and network.

I did not realize that Sam sung would be a prohibited word.
 
I guess I was not clear. I was asking for tests to be performed on my mailserver so I would know what HELO was sent. People testing their phones against their configuration does not help us. I don't know what configuration you have set up on your own mailservers.

But at minimum we need to know what HELO your phone sends to the mailserver.
 
This test won't work, as Blackberrys are doing it the proper way. The device is connecting to a server which will communicate with your server, so everything will be fine, because messages will come from a FQDN hostname.
It is an interesting problem though, because if email clients are badly designed (think Microsoft), or if telecom operators are not giving users a proper hostname, then, with the current exim.conf, you can only send emails from your servers using port 587 which only smartphones will let you do.
 
I'm giving this issue a lot of thought; I still think the tests are important enought to include, but perhaps with documentation on how to remove them and that if you do you'll see a larger spam load on your system.

Jeff
 
Back
Top