How does mail server know what kind of client it's authenticating?

Question

My cloud-hosted java app successfully authenticates to our mail server on another host (a managed VPS) at mail.example.com. The server at mail.example.com accepts email to our users at [email protected]. However relay is denied, and attempts to send mail to [email protected] 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: How to correct Postfix' 'Relay Access Denied'?. I'll leave that up to the admins who manage mail.example.com -- probably they'll add the application host IP to the mynetworks setting in the main.cf 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?

Answer 1

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 example.com 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

  accept

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.