Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My cloud-hosted java app successfully authenticates to our mail server on another host (a managed VPS) at The server at accepts email to our users at However relay is denied, and attempts to send mail to are rejected.

However, my question is not "How do I fix this?" I'm pretty sure that it's much the same issue as this one: I'll leave that up to the admins who manage -- probably they'll add the application host IP to the mynetworks setting in the file.

My question is this: How did the mail server know that the java app was not my email client? I tested the java app email setup with the user id and password that I use everyday for my own email. I use a laptop and connect to email from all over -- coffee shops, home, hotels, etc.

What makes my java app any different from me on my laptop connecting from Starbucks?

share|improve this question
Is the java application using the same user account as your email client? – mfinni Jun 22 '10 at 19:16
The mail server (basically) only knows 2 things about it's clients: 1. The IP they connect from 2. The username/password they use to login. – Chris S Jun 22 '10 at 19:20
yes -- same account – marfarma Jun 22 '10 at 19:55
There has to be something more -- I couldn't authenticate until I had reverse DNS propagated for my host -- so somehow it knew the hostname to cross check against the IP address. – marfarma Jun 22 '10 at 19:58
Of course your relay host could check whether the PTR resource record for your Java app's IP address is valid and resolves to a sensible hostname. But usually these kind of checks are omitted for authenticated hosts, so it's basically a configuration issue on the relay host. It definitely only knows the client's IP address and after authentication happened the user credentials. Of course it can do anything with this information, like checking PTR records or checking WHOIS entries for the IP address. – joschi Jun 23 '10 at 7:18
up vote 2 down vote accepted

You sort of touched on this in your comment above; basically the first thing upon a connection is to issue a HELO (smtp) or EHLO (esmtp) command from the client to the server. The problem is, right now, you don't know what has in their mail configuration file.

What I would do to debug is set up your own MTA (exim, postfix, etc.) on a server somewhere and crank up the logging output to capture your normal client and your java app sending sessions and compare what each MUA is sending to the server, especially that HELO/EHLO field. Alternatively if setting up a quick mail server is too much for you, you could use tcpdump on the host and capture the raw packets outgoing and view them in Wireshark to read the payloads.

As an example, here's what the default, out of the box Exim config looks like in regards to this info:

  # Hosts are required to say HELO (or EHLO) before sending mail.
  # So don't allow them to use the MAIL command if they haven't
  # done so.

  deny condition = ${if eq{$sender_helo_name}{} {1}}
       message = Nice boys say HELO first

  # Use the lack of reverse DNS to trigger greylisting. Some people
  # even reject for it but that would be a little excessive.

  warn condition = ${if eq{$sender_host_name}{} {1}}
       set acl_m_greylistreasons = Host $sender_host_address lacks reverse DNS\n$acl_m_greylistreasons


You might also check if your Java app is using the same kind of authentication as your regular client - perhaps your mail server reacts differently if a PLAIN or LOGIN style is used instead of, say, CRAM-MD5. This is solely up to the MTA admin to have configured, so again you're at their mercy.

share|improve this answer
Thanks for posting this useful answer. I've been pulled away from this, but will have to return to dealing with this issue shortly. – marfarma Sep 20 '10 at 19:51

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.