1

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 user@example.com. However relay is denied, and attempts to send mail to somebody@gmail.com 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?

Community
  • 1
marfarma
  • 281
  • 1
  • 3
  • 11
  • 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
  • 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 07:18
  • I'm thinking it might be something more explicit -- in the log fragment posted in the question I linked to in my question we see 'helo=' Until I fixed my PTR record the error I got was essentially 'invalid helo value' -- if I'm sending a hostname as helo, while a PC client sends a token, that would explain it. Of course, if the poster doctored the log entry to obscure identifying detail, and the helo value was his PC's hostname -- I wouldn't expect that a PC would have a value PTR record -- so I'm back at the same point -- what's the difference? – marfarma Jun 23 '10 at 13:40
  • Sorry to sound snippy - you can think what you want, IP and connection login seuence are THE ONLY THINGS IT KNOWS. TLS information MY be there, but TLS authentication is uncommon / non standard. There simply is nothing more. Client opens TCP, starts talking. First sequence is the login sequence to the server - so that is all the server has available to work with. From that you can do IP blocks, PTR requests, but otherwise there simply is nothing more. ALTHOUGH - it COULD be set on POP before SMTP, so a POP3 login may be required first. – TomTom Aug 07 '10 at 13:41
  • Is the java application using the same user account as your email client? – mfinni Jun 22 '10 at 19:16
  • yes -- same account – marfarma Jun 22 '10 at 19:55

1 Answers1

2

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.

  • 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